Self-Hosting Rails with Kamal: Part 1 - Why self hosting

Part 1 of the series: Self-Hosting Rails with Kamal

In this article, we compare deployment platforms and make the case for self-hosting your Rails API. In Part 2, we’ll walk through exactly how to deploy with Kamal.

You’ve built something. A Rails application humming along with a frontend on top. It works on localhost, your tests are green, and you’re itching to put it in front of real users. Then comes the part nobody warns you about: deployment.

Most tutorials make this look easy. “Connect your GitHub repo, click deploy, done.” And for the first month, it genuinely is that easy. But the deployment decision you make today isn’t just about getting something live — it’s about the relationship you’ll have with your infrastructure for as long as the project runs. Get it wrong, and you’ll either be migrating everything six months later or quietly paying for constraints you didn’t know you were accepting.

This article is about making that decision well. By the end, you’ll understand what managed platforms are actually good for, what they quietly take from you, and why the self-hosting calculus has changed in a way that’s worth understanding.

Managed Platforms Solved a Real Problem

Let’s be honest about why Heroku, Render, and similar platforms became so popular — they earned it.

Before them, deploying a web application meant hand-configuring servers, wrangling reverse proxies, managing SSL certificates manually, and debugging environment drift between your machine and production. It was tedious enough that most developers avoided it entirely. Heroku basically invented the modern “git push to deploy” experience, and Render carries that torch well today.

What you get with a managed platform:

A fast, satisfying deployment loop. Push code, watch it build, see it deployed.
Sensible defaults for things you don’t want to think about yet — networking, TLS, process management.
No servers to maintain. Patching, scaling, infrastructure — handled.
Excellent documentation and usually good support.

If you’re learning Rails or shipping your very first deploy, these platforms are a genuinely good on-ramp. The convenience is real, not just marketing.

But there’s a side of this worth understanding before you’re three months in and dependent on the setup.

What Managed Platforms Don’t Tell You

The convenience of managed platforms comes with a specific shape. You get easy access to the things they’ve decided to offer, in the way they’ve decided to offer them. That’s fine — until your needs don’t fit that shape.

A few things that quietly matter:

Opacity. Your app runs on infrastructure you can’t inspect, SSH into, or change. When something behaves unexpectedly, your debugging options are limited to logs and dashboards. You’re trusting the platform’s abstractions completely, which is comfortable until it isn’t.

Lock-in. The more you lean on platform-specific configuration — environment variable conventions, managed add-ons, proprietary integrations — the harder it is to leave. This isn’t malicious; it’s just how these products work. Switching costs grow silently over time.

Pricing that scales in steps. Free tiers have real limits: cold starts on inactive apps, row caps on managed databases, background workers that cost extra. Moving off the free tier isn’t a gentle slope — it’s a series of jumps. Add a worker process, upgrade the database, bring in a second service, and the bill looks very different from what you started with.

Someone else’s decisions affecting you. Platforms deprecate features, change pricing, sunset services. If your deployment depends on a platform-specific thing, that thing is theirs to change. This has happened enough times that it shouldn’t surprise anyone, but it still does.

None of this is a reason to avoid managed platforms entirely. For the right situation, the tradeoffs are worth it. But it’s worth knowing what you’re trading for the convenience before you’re deep into it.

The Case for Running Your Own Server

Here’s what you actually get when you move to a VPS:

You own what you deploy. The server is yours (or rented from a commodity provider). You can SSH in, poke around, install software, change configuration. When something goes wrong, you can investigate rather than wait for a support ticket.

Portability. An app deployed with Kamal can move to a different provider in the time it takes to provision a new server and update a config file. You’re not tied to anyone’s abstractions or pricing decisions.

Full-stack understanding. This one gets undersold. When you run your own server, you learn how your app actually behaves in production — how processes start, how traffic flows, what happens when memory fills up. That understanding transfers to every job you’ll work on, every system you’ll debug. It’s not overhead; it’s leverage.

Predictable behavior. Dedicated resources mean your app runs the same way at 3am as at 3pm. No cold starts, no noisy neighbors, no surprise throttling.

Cost is real too, but it’s not the main point. A VM from Hetzner or DigitalOcean costs a few dollars a month for a machine that runs your app, your database, and your background workers simultaneously. The savings are genuine — but more importantly, the pricing is flat. You know exactly what you’re paying and what you’re getting, forever.

Why Self-Hosting Used to Be Painful

If all of this is true, why did everyone migrate to Heroku and Render in the first place?

Because the alternative was genuinely painful:

Capistrano deploys that worked until they mysteriously didn’t.
Docker orchestration that felt like overkill for one small app but was hard to avoid.
Hand-configuring nginx as a reverse proxy, getting the config exactly right.
SSL certificates — wrangling Let’s Encrypt and renewal cron jobs by hand.
Environment drift, zero-downtime headaches, general server babysitting.

The convenience premium on managed platforms was worth paying because self-hosting required a second skillset that had nothing to do with your application. That was a legitimate tradeoff.

But it isn’t 2015 anymore.

What Kamal Changes

Kamal is a deployment tool from the team behind Rails — it ships as the default deployment story for new Rails apps. It exists to answer one specific question: what if deploying to your own server felt like deploying to a PaaS?

What it does:

Deploys Docker containers to any server you can SSH into.
Zero-downtime deploys are built in — Kamal boots the new version, health-checks it, and swaps traffic without dropping requests.
Handles TLS via Let’s Encrypt automatically. Add ssl: true to your config and that’s the end of it.
Runs its own lightweight reverse proxy — no hand-written nginx configuration.
Everything lives in a single YAML file checked into your repo.

The thing that made self-hosting painful was the operational friction — the configuration, the cert management, the deployment coordination. Kamal is specifically designed to remove that friction. You’re left with the control and ownership, without the traditional ops burden.

This is what changes the calculus. It was never that a VPS was a bad idea — it was that the tooling to use one well was too cumbersome. That’s no longer true.

What You’re Still Signing Up For

It would be dishonest to pretend self-hosting is free of tradeoffs.

You’re responsible for the server. Security patches, OS updates, disk space — that’s on you. In practice, this isn’t much work, but it’s work that exists. You should know that going in.

Debugging is on you. When something breaks, you’re investigating a real system, not reading platform logs. This is also the reason you learn more — but the first few incidents will take longer than they would on a managed platform.

Initial setup takes time. Not a lot with Kamal, but some. Provisioning a VM, configuring a domain, writing a deploy config. A few hours, realistically. That’s front-loaded effort that managed platforms skip.

If you’re prototyping fast and want zero infrastructure overhead while you validate an idea, a managed platform is a perfectly reasonable call. There’s no shame in it.

How to Decide

Use a managed platform if:

You’re in early exploration and want to validate an idea without any infrastructure overhead.
You need to move very fast and the setup time is a real cost right now.
You’re on a team that hasn’t adopted this workflow and you’d be the only one maintaining it.

Self-host if:

You’re running something with any expectation of longevity — you want the infrastructure to outlast the initial momentum.
You care about owning your stack and understanding how it runs.
You want predictable costs without surprises as you add components.
You’re willing to spend a few hours on setup to avoid years of constraints and opacity.

Most projects that are past the “is this idea viable” stage belong in the second column.

What’s Next

In the next article, we’ll stop talking strategy and get our hands dirty:

▎ How to Deploy a Rails Application Using Kamal — provisioning a VM, writing your Kamal config, wiring up DB, getting SSL working, and shipping your first zero-downtime deploy.

Bring a small Rails app and some time. That’s all you’ll need.

This article is Part 1 of the series “Self-Hosting Rails with Kamal.” The next article covers the step-by-step Kamal deployment process.