Kamal ships your containers. KamalCloud runs the machines underneath — provisioned, hardened, patched, backed up and watched, inside your own Hetzner, DigitalOcean or AWS account.
Your servers, in your account
kamal deploy
Six things, done well, then finished. None of the list beside it was ever Kamal's job.
Everything before and after it
KamalCloud does that second list.
One app on one server? Just use Kamal.
Doing it by hand for now?Take the checklist
KamalCloud is a client of your infrastructure, not the owner of it. Everything it writes is something you could have written yourself.
What happens if you cancelconfig/deploy.production.yml
Written next to your repository's checkout on the runner, in Kamal's own format. Your deploy.yml is left as it is.
Firewall, SSH, brute-force protection and updates are read back off the server every time you open the page. Not a checklist KamalCloud promises it ran once.
How it worksufw, fail2ban and unattended upgrades, each applied by its own button
Anything drifting shows up as a row you can fix in one click
A fix asked for through the API or CLI waits for an admin to approve it
KamalCloud's API, CLI and MCP server offer exactly the actions your own role allows — and anything that costs money, can't be undone or takes something offline has to show you what it would do before it does it.
Turn on human-approval mode and a token can only propose: every change waits in a queue until an admin approves it in the browser, recorded against the token that asked and the person who decided. Admins working in the browser act directly. Hand the CLI to a script, or to an agent, without handing over the keys.
How agents connectAn MCP server at POST /mcp: one tool per action a person could take, built from the caller's own role
Anything that costs money, can't be undone or takes something offline previews first and waits to be confirmed
Agents sign in through the browser with OAuth. Tokens are minted by people, never by agents
Deploys, tasks, backups, restores and browser shell sessions all record who ran them, or the push that started them, with the full output kept alongside. Your infrastructure bill sits on the same page, at the rate your provider charges you.
What it costs
Full logs kept per deploy, not left in a terminal you closed
Server spend shown per machine, billed to you by your provider
KamalCloud never resells infrastructure
Configuration history — who changed a secret or a role — is not recorded yet.
Push to deploy
Deploy on a push to a branch, or on any new tag. Path filters ignore pushes that don't touch the app, and [skip ci] is honoured. Off until you turn it on.
DeploymentsRollback and maintenance
Roll back to any version Kamal has already built. Maintenance mode has kamal-proxy answer with a 503 and your message.
DeploymentsBackup before deletion
Deleting an app, environment or server backs up its databases and volumes first. If a backup can't be taken, nothing is deleted.
BackupsAlerts
Failed deploys, tasks and backups, no successful backup in 36 hours, expiring certificates, traffic near the allowance, a rejected provider token. By email, Slack, Discord or webhook.
NotificationsThe kamal-cloud CLI reads your servers and apps directly. Anything that would change something becomes a request, and kamal-cloud wait blocks until an admin approves or rejects it in the browser. The same binary bridges MCP over stdio, so an AI client gets the same actions the script does.
The CLIterminal
A shell in the browser, scheduled tasks, rolling deploys across a role, several apps on one server, volumes and ports are in the docs.All of it
Nothing to rebuild to try it.
Databases and accessories
Postgres, MySQL, Redis and Valkey, booted as Kamal accessories. Backups go to S3-compatible storage you control, to several buckets at once, standing the container down first where a live copy would catch a database mid-write.
Domains, TLS and reachability
Certificates issued and renewed, then read back hourly from outside, so one about to lapse is noticed before a visitor finds it. DNS is checked against what is actually resolving.
Apps you already deploy
Import an app already running on one of your servers. KamalCloud reads it off the Docker containers and touches nothing on the machine.
And now on the second server, the second environment, or the second engineer. Nothing about your deploy changes.
Many apps across many clouds, each with its own servers, its own people and its own roles.
$29/ month
Everything KamalCloud does, for every server and everyone on your team.
Seven days free, billed monthly after that. A card is collected at signup, by Stripe, before anything is provisioned, and nothing is charged until the trial ends. Cancel any time.
Start your free weekServer costs are billed by your provider, to you, at their price. KamalCloud never resells infrastructure.
A question about billing? Ask us
If the catch is not here, there is no catch.
We are a small team running our own Rails applications on Hetzner with Kamal. We got tired of the half-finished hardening checklist, the backup nobody had restored, and the SSH key three people shared. It exists because we wanted it.
Ask us anythingYes. Your repository's deploy.yml is left as it is. For each environment KamalCloud writes a standard Kamal destination file and a secrets file on its runner, next to the checkout. With those files and your own SSH access, Kamal runs from your laptop the same way. Nothing about the Kamal workflow is replaced or intercepted.
Your servers are in your cloud account and stay there. Your applications keep running. Your repository's deploy.yml, and the destination and secrets files KamalCloud wrote on the runner, still work with plain Kamal. KamalCloud stops managing them; nothing tears anything down.
Your applications keep serving traffic, because KamalCloud is not in the request path. You would lose the browser controls for the duration, not the sites.
On the runner, the one box Kamal runs from: git, curl, Docker, a deploy key, an SSH config and the pinned official Kamal image. On the servers your app runs on, nothing of KamalCloud's — Kamal puts Docker there, the same as it would from your laptop. The hardening fixes change the machine's own configuration: ufw, fail2ban, unattended upgrades, sshd. Each one is a separate button, and the security page reads the result back off the machine rather than trusting that it ran.
Yes, that is how it does the work. KamalCloud holds a control key and a deploy key, both encrypted at rest. Deploys, tasks, backups, restores and browser shell sessions record who started them. The connections KamalCloud makes for its own checks and syncs are not attributed to anyone, and a change approved through the API runs as the person who approved it. Your own keys and your own access are untouched.
Encrypted in KamalCloud's database, and in a secrets file on your own runner that Kamal reads at deploy time. They are never written into your repository and never committed anywhere. If you remove KamalCloud, that file is on your machine, under your control.
It acts as you, with your role, and never past it. Anything that costs money, cannot be undone or takes something offline comes back as a preview it has to confirm before it proceeds. Tokens are minted and revoked by a person in the browser, so an agent cannot widen its own access. Turn on human-approval mode and it can only propose: every change waits for an admin.
The deploy carries on. Kamal runs detached on the runner, so it is not holding your browser tab or a KamalCloud process open for the duration. If the worker watching the run goes away, another picks it back up and settles the record on what actually happened on the machine, rather than on what KamalCloud last saw. We deploy KamalCloud with KamalCloud, which is the only reason we know this works.
For actions, yes: every deployment, task, backup, restore and browser shell session is attributed to the person who ran it, or the push that started it, with its full output. Configuration history, who changed a secret or a role, is not recorded yet.
Yes. Register any Linux machine you can reach over SSH. It is managed the same way as a provisioned one, minus everything that needs a provider API: resizing, snapshots and rebuilds, power control, hardware metrics, and a cost figure. KamalCloud reaches it over SSH and manages what runs on it, without pretending it built it.
All of it. A card is collected by Stripe at signup, before anything is provisioned, and the first week is free. There is no reduced tier during the trial and nothing is held back. If a payment fails later you are not locked out of your own servers straight away: the account keeps working for about a fortnight while Stripe retries, and the alert fires at critical severity so it is not a surprise.
No. There are no KamalCloud-managed servers to rent. You pay Hetzner, DigitalOcean or AWS directly, the machines are in your account, and KamalCloud is a client of your infrastructure rather than the owner of it.
Register a machine you already have, or provision a new one. Nothing is touched that you have not chosen.
Sign-ups are paused while the app is in maintenance.