Three deploy stories keep cycling through every solo Rails founder I talk to. Kamal on a $20 VPS. Fly.io with its global edge. Render with its “git push and forget” promise. Each one is correct for somebody, and each one is a tax on somebody else. The friction I keep hitting is that the comparison usually gets written by people who are paid to recommend one of them. Or by people running serious engineering teams, where the operational math is nothing like the math for a one-person shop.
This post is the rubric I’d hand a founder who has a Rails app, a database, a background worker, and no platform engineer. Not “which is best” — “which is least likely to hurt you, given the work you actually do in a week.”
What we’re actually comparing
Three things, despite the marketing copy, are not the same shape.
Kamal is a deploy tool. You bring servers — Hetzner, DigitalOcean, an old NUC in a closet — and Kamal SSHs in and runs your app as Docker containers. There is no platform under it. You own the Linux box, the firewall, the backups, the TLS cert rotation, the kernel updates. The bill is whatever your VPS provider charges, which for a single $5–$20 box is the cheapest option on the table.
Fly.io is a platform that runs Firecracker VMs (“machines”) in regions you pick, with a managed Postgres offering, persistent volumes, and a CLI that feels like Heroku-meets-Docker. You don’t touch the host. You do touch fly.toml a lot.
Render is the closest thing left to “old Heroku” for Rails: connect a repo, declare services, get a *.onrender.com URL. Managed Postgres, managed Redis, a free background-worker tier on paid plans. You don’t see machines at all.
The three are not really competitors. They’re three different answers to “how much infra do you want to own?”
The rubric I use
I score these for a solo founder along five axes. Nothing about feature breadth. Just the things that wake you up at 2am.
| Axis | Kamal | Fly.io | Render |
|---|---|---|---|
| Time to first deploy | Slow (host setup) | Fast | Fastest |
| Monthly floor for a real app | Lowest | Middle | Middle-high |
| Ops surface you own | All of it | Some | Almost none |
| Failure modes you’ll debug | Linux, Docker, networking | fly.toml, Machines, regions | Render dashboard, build cache |
| Lock-in if you leave | None | Moderate | Moderate-high |
The honest read: Kamal is cheapest and most portable, and it bills you in attention. Render is the inverse. Fly sits in the middle on almost everything, which is a strength and also a tell — it’s nobody’s clear winner unless you specifically want multi-region or persistent volumes the way Fly does them.
A few things I have stopped including in this rubric because they don’t move the needle for solo founders: raw benchmark numbers (your bottleneck is Postgres, not the runtime), “developer experience” as a subjective score (all three are fine), and Kubernetes integration (if you’re reading this post you don’t want Kubernetes).
One thing I have started including: how the platform behaves on a Sunday when something is wrong and you are the only person who can fix it. Kamal hands you ssh and a stack you can fully reason about. Fly gives you fly ssh console and a layer of abstraction. Render gives you a dashboard and a support form. Pick the rescue path that matches how you problem-solve under stress.
The pitfalls
The most common Kamal mistake is treating it like a managed platform. It is not. Kamal does not back up your database. It does not patch your kernel. It does not rotate logs. If you adopt Kamal, you adopt a small Linux operations practice along with it. That’s a fair trade for a lot of founders. It’s a terrible trade if you genuinely don’t want to learn that stack.
The most common Fly.io mistake is over-regioning. People see the global edge story and deploy to four regions on day one. Now they have four times the surface area, four times the cold starts on the smallest plans, and a Postgres replication topology they don’t understand. For an early app with users in one country, a single Fly region is correct.
The most common Render mistake is not running the math on the free Postgres tier. The free Postgres on Render expires. You will get the email. You will be busy that week. Plan from day one to use a paid database — or to host the database elsewhere — if you want to sleep.
A pitfall shared by all three: deploying without a job runner story. Rails apps grow background workers fast. Whatever you pick has to host Sidekiq or Solid Queue without you re-platforming six months later. I wrote about that decision in Sidekiq vs Solid Queue in 2026; the deploy choice and the queue choice interact more than they should.
How the pattern actually looks
Imagine a typical first-paying-customer Rails SaaS. Postgres, Redis, a web process, a worker process, some inbound webhooks, ActionMailer hitting a transactional provider. Maybe one storage bucket for user uploads. This is the load envelope where the three options diverge most clearly.
On Kamal: one Hetzner box, ~$10–$20/month depending on RAM. Postgres and Redis run as Docker containers on the same machine. Daily pg_dump to S3-compatible object storage. Caddy or Traefik fronts TLS. Kamal handles zero-downtime deploys via container rotation. The whole bill is a single VPS line item plus a few dollars of object storage. The cost in time is one weekend setting it up, then ongoing patching.
On Fly: a small web Machine, a small worker Machine, managed Postgres on the smallest plan, Upstash Redis or Fly Redis. The bill lands in the small-double-digits monthly range for early traffic. Deploys are fly deploy. You spend almost no time on the host. You spend some time learning Fly’s primitives — release commands, secrets, volumes.
On Render: a web service, a background worker service, a managed Postgres instance, a managed Redis instance. Each is a line item. The bill is higher than the other two for equivalent resources, but the time you spend on infra is closest to zero. Deploys are automatic on push.
For a founder who values a $30 difference less than a Saturday: pick Render. For a founder who values the Saturday less than the $30 difference, and who can already write a systemd unit without Googling: pick Kamal. Fly is the right pick when you have a real reason to want machines closer to users, or when persistent volumes per region are part of the product. If you can’t articulate that reason, Fly is a less obvious win.
The cheapest deploy stack is the one whose failure modes you already know how to fix.
What “done” looks like
A deploy setup is done — for a solo founder — when four boxes are checked, not when the dashboard turns green.
You can deploy a change in under five minutes from git push to “the customer sees it” without thinking. You have a tested database backup, meaning a backup you have actually restored to a fresh environment at least once. You have logs you can search going back at least seven days. And you have a documented runbook of “what to do if production is down for thirty minutes,” even if that runbook is just three bullet points in a Notion page.
If any of those four is missing, the deploy isn’t done; it’s deferred work disguised as a working app.
The platform choice barely matters at this checklist. Kamal can hit all four with a weekend of work and a $10 box. Render hits the first three out of the box and leaves the runbook to you. Fly hits the first three with a paid plan and leaves the runbook to you. The discipline is what’s load-bearing — not the brand.
When none of this applies
If you have multiple engineers, an existing Kubernetes practice, or compliance requirements that mandate specific cloud regions, this whole rubric collapses. Multi-engineer teams should optimize for shared mental model, not infra cost. Compliance-bound apps should ask the auditor first and the deploy tool second. And if you’re already running on AWS or GCP for a non-trivial reason, the answer is probably ECS or Cloud Run, not any of these three.
This also doesn’t apply if your app is not really a Rails app. A Sidekiq-heavy data pipeline with no HTTP surface scores differently. A static marketing site has its own story — see Astro on Cloudflare Workers vs Next.js for that.
A small, falsifiable claim
Here’s the bet I’ll make: for a Rails founder shipping their first paying-customer app in 2026, the deploy choice will not be the thing that kills the company. Scope will. Pricing will. Auth will. The deploy tool you pick on day one is replaceable in a weekend if you’ve kept your Dockerfile honest and your environment variables sane. Pick the option whose failure modes you’d rather debug on a Sunday, ship the app, and revisit the question only if something is actually breaking. Everything else is procrastination dressed as research.