Kamal ships as the default deployment tool in Rails 8, 37signals runs their whole product line on it, and the pitch is genuinely attractive: buy a couple of dedicated boxes, run kamal deploy, and stop paying a platform to babysit your containers. For a certain shape of team, that's the right call. This post is for the other shapes — when you find yourself Googling alternatives at 11pm because a disk filled up on the box that also runs your database.
What Kamal actually is, and what it's good at
Kamal (formerly MRSK) is an open-source deploy tool from 37signals. You point it at servers you control over SSH; it installs Docker, builds your image, pushes it to a registry, and rolls new versions out with zero-downtime cutover through kamal-proxy. Configuration lives in a single config/deploy.yml. Kamal 2 (late 2024) fixed the two loudest v1 complaints by adding automatic Let's Encrypt certificates and support for multiple apps on one server.
The good parts are real:
- Cost. A dedicated box from Hetzner or OVH gives you an enormous amount of compute per dollar compared to any PaaS. If your workload is steady and predictable, the math favors owned hardware.
- No lock-in. It's Docker plus SSH. Your servers can be anywhere — a cloud VM, bare metal, a machine under your desk. Moving off Kamal means... keeping your Dockerfile.
- A mental model you can hold in your head. One YAML file, one command, and you can read the entire tool's source in an afternoon.
Where the model starts to cost you
Kamal deploys applications. It does not operate servers, and that distinction is where the hidden invoice lives. OS patching, kernel updates, disk-full alerts, SSH key rotation when someone leaves, log retention, host monitoring — all yours.
The sharpest edge is databases. Kamal's "accessories" run Postgres, MySQL, or Redis as plain containers on your hosts. That works, but backups, point-in-time recovery, restore drills, and version upgrades are entirely your problem, and a database in an unreplicated container on a single box is a decision you should make deliberately, not by default.
Two more structural gaps: there's no autoscaling — capacity is whatever you bought — and there's no team access model beyond "who has SSH keys and registry credentials."
None of this is a flaw. It's the deal Kamal offers, stated plainly on the tin. The question is whether you want that deal. If not, here's the field.
The alternatives
1. Coolify — keep your servers, add a control plane
[Coolify](https://coolify.io/docs) is the closest philosophical neighbor to Kamal: open source, runs on hardware you own, no per-app platform fees. The difference is that Coolify is a full self-hosted PaaS — a web UI, git-push deploys, one-click databases and services, team members with roles — rather than a CLI deploy tool.
What it does well: it removes the "everything is a YAML file and an SSH session" friction while preserving the own-your-servers economics. The honest caveat: the control plane is itself software you now run and upgrade, and the underlying server-operations burden (patching, disks, backups verification) doesn't go away — it just gets a nicer dashboard. There's a paid cloud option where they host the control plane for you.
Best for: teams who like Kamal's economics but want a UI, a team model, and one-click databases on top.
2. Render — the closest thing to classic Heroku
[Render](https://render.com/docs) is a managed PaaS in the original sense: web services, background workers, cron jobs, managed Postgres, preview environments, all from a git push. Their docs are consistently good, and the platform behaves predictably — which is worth more than any single feature.
What it does well: the boring, load-bearing stuff. Managed Postgres with real backups, zero-downtime deploys, infrastructure-as-code via a render.yaml. Caveats: it has a free tier, but free services spin down after inactivity, and as you add services, environments, and databases the line items accumulate — pricing is on [their site](https://render.com/pricing).
Best for: teams who want the Heroku workflow with a modern platform underneath and don't want to think about infrastructure at all.
3. Fly.io — when regions and latency matter
[Fly.io](https://fly.io/docs) runs your containers as lightweight VMs (Machines) in dozens of regions, routed over anycast so users hit the nearest one. If your product is latency-sensitive or your users are genuinely global, this is Fly's home turf and nobody else on this list plays there as well.
What it does well: fast-booting machines, a strong CLI, real multi-region primitives (volumes, regional placement, private networking). Caveats: it's the most ops-flavored option here — you will read documentation about Machines, volumes are tied to specific hosts, and their Postgres story has historically been "automated but you operate it," with a managed offering rolling out more recently; check their current docs before assuming.
Best for: globally distributed apps and teams comfortable trading some convenience for placement control.
4. Railway — the best-feeling developer experience
[Railway](https://docs.railway.com) is the slickest onboarding in the category: connect a repo, and the canvas UI shows your services, databases, and their connections as a live diagram. Templates make spinning up an app-plus-Postgres-plus-Redis stack nearly instant.
What it does well: developer experience, variable references between services, per-second usage-based billing so idle dev environments cost little. Caveat: usage-based pricing means the bill is an output, not an input — fine for many teams, harder if you need a fixed number for budgeting.
Best for: solo developers and small teams who value speed-of-start and a great UI over everything else.
5. PandaStack — git push, database included
PandaStack is ours, so calibrate accordingly — but here's the factual shape. You connect a Git repo; the platform auto-detects the framework (or uses your Dockerfile), builds the image with rootless BuildKit in ephemeral Kubernetes job pods, and deploys it with live build logs streaming in the dashboard. Managed PostgreSQL, MySQL, MongoDB, and Redis are first-class: attach a database to an app and DATABASE_URL is injected automatically — no copying credentials between tabs.
Pricing is flat rather than usage-based at the plan level: Free at $0/mo (5 web services, 5 static sites, 1 database, 100 GB bandwidth), Pro at $15/mo, Premium at $25/mo, with per-hour compute tiers on top for bigger workloads. Free-tier apps scale to zero when idle — good for hobby projects, but it means cold starts, and they run on preemptible nodes. We're also the newest platform on this list; the ecosystem around us is smaller than Render's or Fly's, and it would be dishonest to pretend otherwise.
Best for: teams who want the app and its database managed together with flat, predictable pricing.
Quick picks
| You want | Choose |
|---|---|
| Own servers, CLI-first, minimal tooling | Stay on Kamal |
| Own servers, but with a UI and team model | Coolify |
| Heroku-style managed everything | Render |
| Multi-region, latency-sensitive apps | Fly.io |
| Fastest zero-to-deployed experience | Railway |
| App + database wired together, flat pricing | PandaStack |
References
- Kamal documentation: [kamal-deploy.org](https://kamal-deploy.org)
- Coolify docs: [coolify.io/docs](https://coolify.io/docs)
- Render docs: [render.com/docs](https://render.com/docs)
- Fly.io docs: [fly.io/docs](https://fly.io/docs)
- Railway docs: [docs.railway.com](https://docs.railway.com)
If the "app plus managed database from one git push" shape fits what you're building, it takes a few minutes to see for yourself at [pandastack.io](https://pandastack.io).