Self-Hosting Rails with Kamal: A Practical Guide: Why VPS Hosting Beats PaaS

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

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. The problem is that “easy” and “sustainable for a hobby project” are not the same thing — and the gap between them is where a lot of indie developers quietly abandon their side projects or get surprised by a bill.

This article isn’t about how to deploy yet. It’s about making a good decision before you deploy, so you don’t have to migrate everything six months later when your platform’s pricing or limitations start working against you. By the end, you’ll know which pieces of your stack belong where, and why.

Let’s get into it.

Why the Deployment Decision Actually Matters?

For a side project, infrastructure isn’t just a technical choice — it’s a financial and motivational one.

A hobby app usually has three constraints that production apps at companies don’t:

The budget is your own money. Every dollar a month matters when there’s no revenue (yet).
Your time is scarce. You’re building this in evenings and weekends. You can’t babysit servers.
Traffic is unpredictable and usually low. You might get ten users or a Hacker News spike. You’re not optimizing for scale you don’t have.

Here’s the trap: the platforms that optimize hardest for “easy” tend to optimize against “affordable” and “flexible.” That’s not a knock on them — it’s just their business model. The convenience you love on day one is the same convenience you pay a premium for on day ninety.

So the real question isn’t “What’s the fastest way to deploy?” It’s “What setup keeps this project alive and affordable for years, even if it never makes a cent?”

Why We All Start With Render or Heroku?

Let’s be fair to the managed platforms, because they earned their reputation.

Heroku basically invented the modern “git push to deploy” experience, and Render carries that torch beautifully today. When you’re starting out, platforms like these give you a lot:

Genuinely easy setup. Connect a repo, set a few environment variables, and you’re live.
A fast, satisfying deployment loop. Push code, watch it build, see it deployed.
Beginner-friendly defaults. You don’t need to know what a reverse proxy is.
Excellent documentation. Their guides are some of the best in the business.
Managed infrastructure. Patching, networking, load balancing — handled for you.

If you’re learning Rails or shipping your very first deploy, these platforms are a fantastic on-ramp. I recommend them all the time for exactly that.

But there’s a “but,” and you’ve probably felt it coming.

Where PaaS Hosting Starts to Pinch?

None of these are deal-breakers on their own. Taken together, though, they’re the reason a lot of hobby developers eventually start looking elsewhere. Briefly:

Free tiers sleep. Your app spins down when idle, so the first visitor waits through a slow cold start — not great for a portfolio piece or a demo link you’re sharing.
Databases have limits. Free database tiers often cap rows or expire after a set period, and persistence can be a real concern.
Background jobs cost extra. Workers for Sidekiq or similar usually mean another paid process.
Pricing grows in steps. Moving off the free tier, adding a worker, and upgrading the database can stack up faster than you’d expect.
You feel locked in. The more you lean on platform-specific config, the harder it is to leave.

To be clear: these are still good products, and for some people the convenience is absolutely worth the money. But for a hobby project where you control the budget and you’re comfortable learning a little infrastructure, the math often stops making sense.

Why a VPS/VM Starts to Look Really Attractive?

Here’s the alternative that’s quietly become the sweet spot for indie hackers: rent a small virtual machine and host your backend on it.

Providers like Hetzner and DigitalOcean offer VMs (Hetzner calls them Cloud Servers; DigitalOcean calls them Droplets) at prices that make managed PaaS look expensive. We’re talking a real server — persistent disk, dedicated CPU and RAM — for a few dollars a month. Hetzner in particular is famous in the indie community for how much machine you get per euro.

What you gain by moving your Rails backend to a VM:

Predictable pricing. You pay a flat monthly rate. No metered surprises, no “oops, the worker scaled” bills.
Dedicated resources. The CPU and memory are yours, not shared in ways that throttle you.
Persistent storage. Your database and files live on disk and stay there.
Full control. Install what you want, configure it how you like.
Better performance per dollar. It’s not close, honestly.
Room to grow. Need more power? Resize the VM. Need to host a second project? Put it on the same box.
A real learning opportunity. You’ll actually understand how your app runs in production — a skill that pays off everywhere.

The catch — and it’s the reason people avoided this for years — is that running your own server used to be a genuine pain.

Why Self-Hosting Used to Be Painful?

If you tried to self-host a Rails app five or ten years ago, you remember the friction:

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 just right.
SSL certificates — wrangling Let’s Encrypt and renewal cron jobs by hand.
General server babysitting — environment drift, “works on my machine,” zero-downtime headaches.

This is exactly the complexity that drove everyone to Heroku and Render in the first place. The convenience premium was worth paying because the alternative was so tedious. That tradeoff was real.

But it isn’t 2015 anymore.

How Kamal changed things?

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 question: what if deploying to your own server was as easy as deploying to a PaaS?

Here’s what makes it a genuine shift for Rails developers:

It deploys Docker containers to any server you can SSH into — your VM, multiple VMs, whatever you’ve got.
Zero-downtime deployments are built in. Kamal boots the new version, health-checks it, and swaps traffic over without dropping requests.
It handles the annoying parts for you — the reverse proxy and SSL via Let’s Encrypt are managed automatically, so no more hand-written nginx configs or manual cert renewals.
Configuration lives in one readable file. Your whole deploy setup is a single YAML file checked into your repo.
It’s made for inexpensive VMs. This is the whole point — Kamal turns an affordable (~€4) Hetzner or DigitalOcean dropplet into a real deployment target without the traditional ops burden.

The short version: the thing that made self-hosting hard is the thing Kamal solves. You get PaaS-like ergonomics on infrastructure you fully control, at a fraction of the cost. We’ll walk through setting this up end-to-end in the next article.

The Recommended Architecture

Here’s the setup this series is building toward:

      ┌─────────────────────┐
      │      Your Users     │
      └──────────┬──────────┘
                 │
      ┌──────────▼──────────┐
      │      Frontend       │
      └──────────┬──────────┘
                 │  API calls (HTTPS)
                 │
┌───────────-────▼───────────────────┐
│ VM (Hetzner / DigitalOcean / Other)│
│      deployed with Kamal           │
│                                    │
│    ┌─────────────────────────┐     │
│    │   Rails API (Docker)    │     │
│    └───────────┬─────────────┘     │
│                │                   │
│    ┌───────────▼─────────────┐     │
│    │   PostgreSQL            │     │  ← same VM to start;
│    └─────────────────────────┘     │     managed DB later if needed
│                                    │
│    ┌─────────────────────────┐     │
│    │   Redis (optional)      │     │  ← for caching / Sidekiq jobs
│    └─────────────────────────┘     │
└────────────────────────────────────┘

The pieces:

Frontend → Next.js / React : We can use Netlify or Vercel which have decent free tier.
Rails API → a Hetzner or DigitalOcean Dropplet, deployed with Kamal. Predictable cost, full control.
PostgreSQL → on the same VM to start. It’s perfectly fine to run Postgres right alongside your app for a hobby project. You can graduate to a managed database later if and when you actually need it — not before.
Redis → optional. Add it on the same box when you want caching or background jobs.

Why this is a great fit:

Cost-effective. A small VM plus free frontend hosting can run a real app for the price of a coffee or two a month.
Production-capable. This isn’t a toy setup — zero-downtime deploys, SSL, a real database. It scales with you.
Low-maintenance. Kamal remove the operational pain from their side of the stack.

You’re not choosing between “easy” and “affordable” anymore. With this split, you get most of both.

Final Thoughts

The big takeaway: you no longer need expensive infrastructure to run a hobby app well.

For years, the calculus genuinely favored managed PaaS platforms — self-hosting was tedious enough that paying the convenience premium made sense. That’s changed. Modern tooling, Kamal in particular, has collapsed most of the operational complexity that made running your own server painful. You get predictable pricing, real control, and a setup that grows with your project, without signing up for a second job as a sysadmin.

Managed platforms are still great products, and there’s no shame in using them — especially while you’re learning. But once you’re ready to keep a project alive for the long haul on a hobby budget, this is the setup I’d reach for.

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 ▎ PostgreSQL, getting SSL working, and shipping your first zero-downtime deploy.

Bring a small Rails app and a few dollars a month. That’s all you’ll need.

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