Kamal vs Heroku vs Render vs Fly.io: Where to Deploy Your Rails SaaS in 2026

You have built your Rails SaaS. Now you need to deploy it somewhere. The options in 2026 range from fully managed PaaS to bare-metal VPS with Kamal. Here is an honest breakdown of what each option actually costs, what you give up, and what you keep.

This is not a "Heroku is bad" article. Heroku is great for certain situations. But if you are building a SaaS you want to grow, sell, or run profitably for years, where you deploy matters more than most founders realize. It affects your margins, your exit multiple, and whether an AI agent can ship a feature to production at 2am without you.

The options at a glance

Let us start with what you are actually choosing between in 2026:

• Heroku: The original PaaS. Still works, still expensive. Dynos, add-ons, and the comfort of not thinking about servers.
• Render: The modern Heroku alternative. Better pricing, good developer experience, but still a managed platform you do not own.
• Fly.io: Edge deployment across 35+ regions. Powerful but operationally complex. Think Kubernetes-lite with better marketing.
• Railway: The simple option. Quick deploys, clean UI, but limited once you grow.
• Hetzner + Kamal: A VPS you own, deployed with Rails' built-in tool. Full control, lowest cost, zero lock-in.

The real cost comparison

Every platform advertises a starter price. None of them tell you what a production Rails SaaS actually costs to run. Here is what you will pay for a typical setup: web process, background worker, PostgreSQL database, Redis for caching, and SSL.

How these numbers work: Heroku Standard includes two Standard-1X dynos ($50 each), Postgres Standard 0 ($25/mo), and Redis Premium 0 ($9/mo). Render includes a Pro web service ($25/mo), a Pro worker ($25/mo), PostgreSQL ($7/mo), and Redis ($14/mo). Fly.io includes two shared-cpu-1x VMs ($10.70 each), a Postgres cluster ($21/mo), and Redis via Upstash ($10/mo). Railway is usage-based, estimated for a low-traffic SaaS. Hetzner is a single CX22 VPS (4GB RAM, 2 vCPU) at 4.50 EUR/mo running everything: app, worker, Postgres, Redis.

The gap only widens as you scale. Add a staging environment, a second worker, or more database storage, and the PaaS costs compound. On a VPS, you just use the capacity you already have.

Heroku: the safe choice that costs you

Heroku deserves credit. It invented the modern PaaS. git push heroku main changed how a generation of developers thought about deployment. In 2026, it still works exactly like that, which is both its strength and its problem.

What Heroku does well: Dead simple deploys. Managed Postgres that just works. An ecosystem of add-ons for everything. If you need to ship something this weekend and never think about servers, Heroku is still a valid choice.

Where Heroku hurts: The pricing tiers are aggressive. Eco dynos ($7/mo) sleep after 30 minutes of inactivity. Basic dynos ($25/mo) do not sleep but have no horizontal scaling. Standard dynos ($50/mo each) are where it gets real, and you need at least two for a production SaaS (web + worker). Add managed Postgres ($9-50+/mo depending on plan) and Redis ($9-15+/mo), and you are spending $134/mo before your first customer pays you.

The deeper issue is lock-in. Heroku's buildpacks, Procfile conventions, and add-on ecosystem create coupling that makes migration painful. You can leave, but you will spend a week doing it. And because you never learned how your production environment actually works, that week will be stressful.

Render: better Heroku, same trade-off

Render is what Heroku would look like if it was built today. Better UI, more transparent pricing, a free tier that is genuinely useful for side projects, and infrastructure-as-code via render.yaml.

What Render does well: Free tier for experimentation. Auto-deploys from GitHub. Managed databases without the Heroku markup. The developer experience is clean and modern. For a developer going from localhost to production for the first time, Render is excellent.

Where Render falls short: The free tier is limited (services spin down after 15 minutes, 750 hours/mo cap). Production plans ($25/mo per service) add up with the same math as Heroku, just at a lower starting point. You still do not own your infrastructure. You are still renting someone else's abstractions. And when Render changes pricing, deprecates a feature, or has an outage, you have no recourse.

Fly.io: powerful but complex

Fly.io is the most technically impressive option on this list. Your app runs as Firecracker micro-VMs deployed to 35+ regions worldwide. For a globally distributed user base, the latency benefits are real.

What Fly.io does well: Edge deployment that actually works. Postgres clusters with automatic failover. A generous free tier. If you are building a real-time collaboration tool with users across four continents, Fly.io solves problems that other platforms cannot.

Where Fly.io struggles: The operational complexity is significant. You are managing VMs, volumes, and networking through a CLI that feels like Kubernetes with a friendlier name. Pricing is usage-based and hard to predict. Community forums are full of developers debugging networking issues, volume mounts, and unexpected bills. If your SaaS serves one region (and most early-stage SaaS products do), the edge deployment is overhead you do not need.

Railway: simple but limited

Railway is the new kid that gets deployment right for small projects. Push your code, get a URL. The simplicity is genuine.

What Railway does well: Fastest path from repo to running app. Clean dashboard. Usage-based pricing that starts low (~$5/mo for hobby use). Good for prototypes and MVPs.

Where Railway falls short: Limited scaling options. No built-in background worker primitives. The platform is still maturing, with features arriving and changing frequently. For a production SaaS with paying customers, you will outgrow Railway before you outgrow any other option on this list.

Hetzner + Kamal: own everything for less

Here is the option that most deployment guides bury at the bottom or skip entirely: rent a VPS, deploy with Kamal, and own your entire stack.

Kamal is not a third-party tool. It ships with Rails 8. It was built by the Rails team at 37signals, the same people who run Basecamp, HEY, and a portfolio of products serving millions of users. When DHH says "we use this in production," he means it literally.

How it works: Kamal uses Docker and SSH to deploy your app to any server. No proprietary runtime. No buildpacks. No platform-specific configuration files. You write a deploy.yml that describes your services, and kamal deploy handles zero-downtime container swaps, health checks, and rollbacks.

A Hetzner CX22 VPS gives you 4GB RAM, 2 vCPUs, and 40GB storage for 4.50 EUR/mo (~$5). That is enough to run your Rails app, a background worker, PostgreSQL, and Redis on a single machine. No add-on marketplace. No metered pricing. No surprise bills.

The lock-in question: can you leave?

This matters more than most founders think. When you want to sell your SaaS, the acquirer's technical team will ask: "How hard is it to move this to our infrastructure?" If the answer is "change one IP address and run kamal deploy," your due diligence just got easier and your multiple just got higher.

AI agent compatibility: can your tools deploy for you?

Here is a question nobody was asking two years ago that matters a lot in 2026: can an AI coding agent deploy your app?

With Cursor, Claude Code, or Codex integrated into your workflow, the ideal deploy path is a single command that the agent can run. No web dashboards. No clicking through a UI. No proprietary CLI with OAuth flows.

• Heroku: Requires heroku CLI with authenticated session. Agents can run it, but the auth flow is manual and the CLI is a proprietary dependency.
• Render: Primarily dashboard-driven. Auto-deploys from Git work, but manual deploys require the web UI or API tokens.
• Fly.io: flyctl CLI works from terminal, but the deployment model is complex enough that agents often generate incorrect configs.
• Railway: Has a CLI, but limited. Most workflows go through the dashboard.
• Kamal: One command: kamal deploy. Standard SSH. No proprietary CLI. Any agent that can run a shell command can deploy your app.

Kamal's simplicity is a structural advantage for AI-assisted workflows. The deploy configuration is a single YAML file that agents can read, understand, and modify. There is no proprietary abstraction layer between your agent and your server.

Exit readiness and due diligence

If you are building a SaaS with any intention of selling it — or even raising money — your deployment story matters during due diligence. Acquirers and investors ask:

• Can we move this to our infrastructure?
• What are the ongoing platform dependencies?
• What is the monthly infrastructure cost, and how does it scale?
• Is the deployment process documented and repeatable?

A Heroku app with 8 add-ons and a $200/mo bill raises questions. A self-hosted app on a $5/mo VPS with a one-file deployment config answers them.

This is not theoretical. SaaS businesses trade at 3-5x ARR on average. If your infrastructure costs eat into your margins, your effective ARR drops, and so does your exit price. Saving $1,500/yr on hosting directly improves your multiple.

When each option makes sense

Choose Heroku if: You are prototyping something this weekend, your team has deep Heroku experience, or you genuinely never want to think about servers. Accept that you are paying a premium for that convenience.

Choose Render if: You want a modern PaaS experience at a lower price point than Heroku. Good for teams migrating off Heroku who are not ready to manage their own infrastructure.

Choose Fly.io if: Your users are genuinely global and latency matters. You are building a real-time application where edge deployment provides measurable user experience improvements. You are comfortable with operational complexity.

Choose Railway if: You are building a side project or MVP and want the fastest path to a running URL. Graduate to something else before you have paying customers.

Choose Hetzner + Kamal if: You are building a real SaaS business. You want the lowest costs, full ownership, zero lock-in, AI agent compatibility, and a deployment tool built and maintained by the Rails team. You want to own your infrastructure the way you own your code.

The Omaship approach: deployment is solved from day one

Most Rails boilerplates hand you a codebase and say "figure out deployment yourself." Omaship takes a different approach.

When you create an Omaship project, deployment is already configured. Kamal is set up. CI/CD is wired. Your staging and production environments are defined. The first deploy happens in minutes, not days.

This is not about vendor lock-in in the other direction. Kamal is open source. Your VPS is a commodity. Your deploy.yml is a readable YAML file. If you decide Omaship is not for you, you keep everything. There is nothing to migrate away from because there is no proprietary platform underneath you.

The best deployment is the one you do not have to think about. Not because someone else is thinking about it for you, but because it is a solved problem in your codebase from the first commit.

The bottom line

Every platform on this list will get your Rails app to production. The question is what you trade for that convenience:

• Heroku and Render trade money for simplicity. You pay more, and you give up ownership.
• Fly.io trades complexity for global reach. You get edge deployment, but you take on operational burden.
• Railway trades capability for speed. You deploy fast, but you outgrow it fast.
• Kamal + VPS trades nothing. You spend 30 minutes learning deploy.yml, and you get the lowest cost, full ownership, and a deployment tool that will be maintained as long as Rails exists.

For founders building a SaaS they want to grow, sell, or run profitably for the long term, self-hosted deployment with Kamal is not the hard option. It is the smart one.