PaaS vs. Self-Hosting: Why Developers Are Taking Back Control

There was a time when Heroku felt like magic—push your code, and your app was live. No servers to manage, no deployment headaches, and a free tier that gave developers a playground to experiment, build, and launch without worrying about infrastructure. But that era is over.

With the free tier gone and prices rising, what was once effortless now feels restrictive. And with modern DevOps tools, it’s worth asking: does Heroku even make sense anymore?

But this shift isn’t just about Heroku. Self-hosting is evolving. Tools like Kamal are making deployment as simple as Heroku—but without the costs, restrictions, or lock-in.

---

The Leased Car Problem: Convenience Always Has a Cost

Heroku is like leasing a car. At first, the convenience feels worth it. No maintenance, no upfront costs—just get in and drive. Now, this car isn't necessarily new, nor is it particularly fast. That's okay — we're just looking for something simple.

But over time, the downsides stack up:
- You're locked into their pricing.
- Customizations? Limited.
- Want to switch? Good luck migrating your entire workflow.

And just like a lease, you never actually own anything. Meanwhile, tools like Kamal make running your own infrastructure feel as effortless as a PaaS—without the hidden costs and lock-in.

---

Enter Kamal: PaaS-Level Simplicity, Zero Lock-In

Kamal is a zero-downtime deployment tool from the creator of Rails, but it’s not Rails-specific. Whether you’re deploying a Rails app, a Go app, or something entirely different, Kamal makes it effortless.

DHH even shared a demo of deploying a Go app in just a few commands—no Kubernetes, no complexity, and no PaaS lock-in.

With Kamal, you can:

✅ Deploy with Docker and SSH—no Kubernetes overhead.
✅ Scale apps across bare metal or cloud providers.
✅ Get zero-downtime deploys without deep DevOps knowledge.
✅ Avoid vendor lock-in and own your entire stack.

Heroku’s biggest selling point was ease of use. Kamal gives you that—no matter what you’re building.

---

The PaaS Illusion: Paying More for Less Control

PaaS promised effortless deployment, auto-scaling, and managed services. But here’s what you really get:

❌ You're locked in. Moving off a PaaS—whether it’s Heroku, Fly.io, or Render—can be painful.
❌ Costs scale faster than value. At first, the pricing looks reasonable. Then your app grows—and so does the bill.
❌ You’re still on the hook for downtime. When things break, you’re stuck waiting for a provider to fix it.

At some point, you have to ask: is paying for convenience really worth losing control?

---

“Developer-Friendly” Hosting? More Like “Vendor-Friendly”

Some newer PaaS options, like Fly.io, market themselves as more cost-effective. They even offer "cost forgiveness"—a safety net for accidental overspending.

Sounds generous, right?

🚨 It’s like a casino comping your first bad bet.
"Oops, you spent too much? Don’t worry, we’ll waive it—just this once."

The system isn’t built for predictability—it’s built for reactive spending. Instead of giving you control, it keeps you guessing:
- Am I over budget?
- How much will this cost next month?
- What happens if I need to scale?

Compare that to self-hosting with Kamal—where your costs are fixed, your infrastructure is yours, and you’re not at the mercy of a pricing algorithm.

---

Goodbye PaaS, Hello Ownership

PaaS made sense when self-hosting was hard and DevOps was a full-time job. But today, tools like Kamal let you own your deployment pipeline—without the hidden costs, vendor lock-in, or scaling surprises.

So the real question isn’t just “What’s the easiest way to deploy?”—it’s who do you want in control?

With PaaS, you trade control for convenience. But that convenience is shrinking, and the costs keep rising. Meanwhile, Kamal gives you the simplicity of Heroku—without the leash.

Or as DHH put it at Rails World:

It's more fun to be competent.

And with Kamal, that competence has never been easier—no matter what you’re building.

---

Want to Go Deeper?

If you’re interested in how Rails itself is embracing this shift, check out A Rails Renaissance—where I break down the resurgence of Rails.