Automatic daily backups and restores for GitHub, GitLab, Azure DevOps, and Linear. Git backups capture repositories, metadata, and LFS; Linear backups capture the whole workspace - issues, projects, cycles, documents, and more. Store them in Cloudback Managed Storage or customer-managed storage (Amazon S3, Azure Blob, Google Cloud, Wasabi, and more). AES-256 encryption with customer-managed keys (RSA Lockbox). SOC 2 Type II compliant. 1.7k+ customers, 14k+ repositories, 4M+ backups.
This is the 3rd launch from Cloudback. View more
Cloudback MCP Server
Launching today
Cloudback now ships an official MCP server. Connect Claude Code, Claude Desktop, Cursor, VS Code, or any MCP client and manage your backup definitions, schedules, storages, and retention policies through plain-language chat - across GitHub, GitLab, Azure DevOps, and Linear. One prompt can reschedule and re-retain 300 backup definitions at once - no dashboard clicks, no throwaway scripts. Runs as a Docker image (myrtlelabs/cloudback-mcp).
Free Options
Launch Team / Built With
Cloudback
The MCP angle is interesting here because backup tools sit right on the boundary between helpful automation and dangerous side effects.
The details I would want to see as a user are: read-only inspection tools separated from mutating restore/delete actions, a dry-run mode for any restore operation, clear repository/account scope, and an audit trail that shows exactly which backup was touched and why.
If those boundaries are visible to Claude/Cursor/VS Code before a tool call runs, this becomes much easier to trust. Backups are one of those domains where the assistant should be useful, but never casually powerful.
Cloudback
@tang_weigang This is exactly the right framing, and most of that list is how it's already built. Read-only inspection and mutating tools are separate, every call is scoped to one account with bulk edits limited to explicit definition IDs (no wildcard), and your client shows each write - account, IDs, and new values - for approval before it runs. Every change lands in the audit log with what was touched and when. On restore and delete specifically: those aren't exposed through MCP at all. The server only manages configuration - it can't restore, run, or delete backup data. The irreversible actions stay in the dashboard behind a human, which is the "useful but never casually powerful" line you're drawing.
Nice launch. Backup MCP is one of those places where natural language is useful, but dangerous if the write boundary is fuzzy.
For bulk retention or schedule changes, do you make the assistant show a planned diff and receipt per account before it applies the change?
Cloudback
@blah_mad Good question, and the right risk to poke at. Bulk changes aren't a wildcard. The assistant has to pull the exact definitions first, so you see the current settings and which IDs will change, and update only touches those IDs. Each call is scoped to one account, and the apply is a normal MCP tool call your client surfaces for approval - with the account, IDs, and new values - before it runs. And every change lands in Cloudback's audit log, so there's a full record of what was applied, when, and by whom. A one-step before/after diff across all definitions isn't there yet - today that view comes from the List call before the write.
That is a solid boundary. I like that the write call stays account-scoped and the client owns approval.
The missing piece I’d want as an operator is the diff receipt: these 17 definitions changed from X to Y, these 2 failed, here is the audit link. Is that something Cloudback plans to expose from the write response?
Cloudback
@blah_mad The success/fail receipt comes straight from the write response. The before/after values aren't bundled into that response, but the assistant can still show them if you ask - it reads each definition's current settings to get the IDs first (that's your "before"), applies the change, and can re-read to confirm the "after." So "repo X: Daily to Weekly, retention 30 to 180 days, succeeded" works today. The one piece that lives outside the response is a direct audit link - that's in the dashboard audit log.
Cloudback
@harshchandgotia Two good questions.
Guardrails: the main one is that the MCP server only manages configuration - it never runs backups, restores, or touches backup data. On top of that, every call is scoped to one account (one API key each), bulk edits have no wildcard (the assistant lists the exact definition IDs first, and unknown IDs are rejected), schedule, storage, and retention are set by name not raw ID, and every write is a tool call your client approves before it runs. All changes land in the audit log.
What we left out on purpose: restore, on-demand backup runs, and deleting backup definitions - the irreversible ones stay in the dashboard behind a human. Same for creating storage, which means handling credentials, and creating or deleting retention policies - the assistant can apply existing named policies, not invent or remove them. Read freely, edit config safely, and keep restore and anything that touches backup data out of chat.
LoadFast Snippet Expander
This is one of the more practical MCP launches today. Backup configs are exactly the kind of repetitive operational surface where chat beats clicking through a dashboard, especially for bulk schedule and retention changes. Curious whether teams are using it mostly for inspection, like “what isn’t backed up?”, or actually letting it propose config changes.
Cloudback
@vidur_saini Thanks - that's exactly the surface we built it for. It's early, so we won't pretend we have usage stats yet, but by design it leans inspection-first: you have to list the definitions before you change them, so people naturally start with "what's not backed up?" or "which repos have no retention policy?" The bulk config changes are the payoff once they spot the gap.
MCP server for backup management is a natural fit, being able to reschedule retention policies through a plain-language prompt instead of clicking through a dashboard is exactly the kind of workflow improvement that compounds over time. Curious if you plan to support Bitbucket as well?
Cloudback
@romeo_ciobanu Appreciate it - the "compounds over time" point is exactly the bet. On Bitbucket: it's not in Cloudback today, so it's not in the MCP surface yet either (the server covers what Cloudback backs up - GitHub, GitLab, Azure DevOps, and Linear). The upside is the MCP server rides on top of that platform support, so the day Bitbucket lands it shows up here automatically. Noted the ask - real demand like this is what we weigh when picking the next platform.