The KamalCloud app is down for maintenance. Sign-ups and sign-ins are paused.App down for maintenance. Sign-ups paused. Details
Questions
If the catch is not here, there is no catch. Where an answer depends on something you would have to verify, it says so.
Yes. 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.
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 anythingThe card collected at signup is charged $29 a month, and nothing about your servers changes. There is one plan, with every feature, unlimited servers and unlimited people, so there is nothing to pick. Cancel any time.
You keep your account. Locking a team out of its own servers over a failed renewal is the worse answer, so a past-due account is admitted for about a fortnight while Stripe retries, and the payment alert fires at critical severity so nobody finds out late.
No. The plan has no server cap and no seat count, so there is nothing to outgrow: $29 a month covers every server and everyone you invite. What grows is your provider's bill for the machines, which is theirs, not ours.
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.
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.
The docs go deeper, and a person reads the contact form.
Sign-ups are paused while the app is in maintenance.