Cloudback MCP Server

Exposing backup operations through MCP is clever. Claude and Cursor already have context to know when a restore makes sense, so meeting devs inside the IDE is the right call. We've been thinking about which operations are safe to put behind MCP in our own agent workflows. How do you handle the auth model? Is confirmation required per action, or scoped at the connection level?

Can you manage what the MCP server is allowed to touch, like only one repo or one workspace?

One prompt rescheduling 300 backup definitions sounds powerful but also a bit risky if the model misreads intent. Does the MCP server have a confirmation or dry-run step before applying changes, or is it fire-and-execute straight to the API?

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?

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.

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.

What guardrails did you have to add before feeling comfortable letting AI make changes to backup configurations?
And Were there any backup operations you intentionally decided not to expose through MCP?

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?

Hi PH 👋 I'm Evgeniy, co-founder of Cloudback. Today I'm bringing our MCP server to Product Hunt.

🛠️ Why we built it: Cloudback already has a dashboard, a Terraform provider, and a REST Operations API. They work well for scheduled automation and IaC. But when a platform engineer wants to answer "which of my 300 repos doesn't have a backup?" or "move every nightly job to 02:00 UTC and extend retention to 180 days" - that's a throwaway script or multiple dashboard clicks. It's not only for changes - you can also just ask for the read-only picture: "how many repos backed up last night?", "which backups failed this week?" - and get the status, stats, and an overview across every account in seconds.

⚡ What the MCP server does:

- List and filter backup definitions across your accounts (GitHub, GitLab, Azure DevOps, Linear - one config file, case-insensitive).
- Bulk-update schedules, storages, and retention policies in one prompt. The assistant reads your retention policy names directly and reuses them - no hardcoded day counts.
- Read and adjust account-level defaults: timezone, default schedule, default storage, default retention.
- Works with Claude Code, Claude Desktop, Cursor, VS Code, and any stdio MCP-compatible client.

🐳 Setup is three steps: create an Operations API key per account, drop them into a single appsettings.json (one entry per account: platform + account name + API key), and register the server in your MCP config. Docker pulls myrtlelabs/cloudback-mcp automatically on first run.

👥 Who it's for:

- Platform engineers managing repos across multiple platforms who want config changes without a script.
- DevOps teams already on Cloudback who want a faster path to bulk changes.
- Operators who want natural-language access to backup state for audits or incident response.

Cloudback protects 1.7k+ customers, 14k+ repositories, and 4M+ backups. Every plan starts with a free trial.

💬 Happy to answer questions