In the wake of 2010s, PaaS felt like magic. You focused on the code, and the platform did the rest. You could ship a production app without knowing anything about networking or, heck, even what a load balancer is. Heroku in particular made deployment a lost thought, especially for early-stage companies.

That era is somewhat over, not because platforms got worse overnight, but because the assumptions underneath them quietly stopped being true. Infra is now cheaper and more hackable, and the pricing model of the past that seemed fair now feels like an additional and increasing tax on a convenience that has often failed to adapt to modern needs.

The Cost-Control Illusion

The billing model is where PaaS starts to become less and less appealing. You're not really paying for what you use; you're actually paying for the next tier up from what you need. On top of that, you often need add-ons (that are priced separately) for everything: from databases to additional backups. All this can bloat your invoice rather quickly.

Bandwidth also comes as a bit of surprise. The moment your app grows past a tier limit (say, you need 2 GB of RAM instead of 1), you’re forced to upgrade to a package that’s too big for your actual needs and is impossible to fully utilize. And there it is: you essentially end up overpaying for unused capacity, often close to double of your previous bill simply because there is no in-between.

A Hetzner CX23 runs at around €3.99/month, and you can scale it vertically in five minutes. With Heroku, that same RAM upgrade might cost you $80/month or more before you've added a single add-on. The invoice is predictable, yes, but it's predictably high.

The usual counterargument is that you're not just paying for raw compute; you’re also paying for managed infrastructure. And that's fair, up to a point. But when the management layer stops offering anything you couldn’t realistically automate yourself in an afternoon, the pricing also stops making sense.

The Loss of Control

The other side of abstraction is transparency. PaaS platforms are designed so that you don't have to think about the underlying infra, but the same design also means you lose visibility when something goes wrong.

This meme is a classic for a reason. And it’s not necessarily specific to Heroku, it can also refer to other platforms where you can't really control the underlying deployment mechanisms. There are plenty of reasons why your platform might be throttling your dyno, and it’s not always obvious from the logs. You end up debugging a black box with incomplete error messages, and support simply tells you to ✨ upgrade to a beefier plan ✨.

Vendor lock-in adds another layer on top of all this. Each platform comes with its own shenanigans: specific Heroku buildpacks, Railway's deployment model, Render's service configuration, Vercel’s Next.js stuff… The problem is, none of these transfer. If you ever need to move, you have to migrate the infra AND relearn an entire deployment mental model.

Finally, regional availability is another constraint that’s often overlooked. If you need a specific EU region for compliance reasons, your options become limited depending on the platform you're on, or sometimes even the tier you're paying for. It’s quite different with a raw VPS. You pick a data center location (Germany, Switzerland, or any other country), and off you go.

Complexity Hiding as Convenience

There’s also a long-term cost here that's harder to put a number on. PaaS platforms are built around the idea that you shouldn't have to care about infrastructure and DevOps in general. And to be fair, I’m sold on that, too. But that also means engineers stop caring about networking, memory leaks, or what a container restart actually does to their process state. We learn to redeploy as a debugging strategy rather than understand why something is not working.

This is fine when everything’s going well. The problem arises when it’s not, and you're now dealing with an incident that nobody can grasp below the application layer. You don't know whether it’s your code or the platform's underlying Pandora box of infrastructure. All those things look the same from inside the platform's dashboard.

The "you don't need to care" sales point produces engineers who really can't care, even when they need to. This is a direct result of the platform's design, as it forces you to upgrade to a bigger plan or bolt on additional add-ons instead of fine-tuning and understanding your stack.

Shift in the Market

Heroku's history says a lot about where it is today. After Salesforce acquired it, meaningful product development stalled.

In February of 2026, Heroku posted on its blog that:

Heroku is transitioning to a sustaining engineering model focused on stability, security, reliability, and support… with an emphasis on maintaining quality and operational excellence rather than introducing new features…

Enterprise Account contracts will no longer be offered to new customers…

I came across Jon Sully’s Dear Heroku, which is a nice bite-sized piece on Heroku in 2026 and worth a read if you want a full picture.

With Salesforce, a sales-heavy approach was introduced (which shouldn’t come as a surprise, judging by its name). Now, if there’s one thing you need to learn about developers, it’s that they don't respond well to corporate sales. Just give them the tools that help them with day-to-day workflow, not tons of corporate mid-steps.

If we go back a bit, we’ll see that the free tier disappeared in 2022. Prices have stayed high, and cheaper, more capable alternatives have emerged. Fly.io, Railway, and Render filled the gap with better developer experience, more modern infrastructure, and sometimes even better pricing at the low end. But they still come with many of the same tradeoffs, and you’re still debugging through platform-level abstractions.

Meanwhile, the "raw infrastructure plus tooling" path has got easier. For example, Hetzner runs a dedicated server for the price of a Heroku Standard dyno.

Unsurprisingly, the developer narrative has shifted from outsourcing everything to owning your stack and automating the boring parts. And the second option is now genuinely more achievable.

The New Stack: Control Without Pain

Self-hosting didn't necessarily become easier in theory, but the tooling around it has improved enough that it can now cover what PaaS used to offer. Enter the tools that let you pilot your deployments (minus the black boxes :)).

Hatchbox handles Rails, Ruby, and Node.js deployments from your own servers (typically Hetzner, DigitalOcean, or even Vultr and AWS) with a Heroku DX-level UI.

Everything is managed for you:

• Zero-downtime deploys
• SSL certificates
• Environment variables
• Process management

You own the server, and Hatchbox handles the electricals.

AppSignal covers what a dedicated DevOps monitoring setup would offer:

• Application performance monitoring
• Host metrics
• Error tracking
• Anomaly detection (this one's particularly neat!)

When your memory surges on a Friday afternoon, you see it. When a slow query starts degrading response times, you see that too. All in one dashboard.

How They Work Together (Hatchbox + AppSignal)

Here’s what a deployment cycle looks like when you put them together:

1. You push to your Hatchbox-connected repo.
2. Hatchbox deploys the changes.
3. AppSignal surfaces the before/after on response times and memory.

If needed, you adjust the server size based on actual usage, not based on tier boundaries. Should you need more RAM, you resize the Hetzner instance for a few euros more per month. No tier upgrade, no plan negotiation.

What you get is PaaS-level convenience for the deployment workflow, with full observability and pricing that scales linearly with what you actually use.

When PaaS Still Makes Sense

I should note that PaaS isn’t really wrong for every situation, despite everything we’ve covered. If you're prototyping, hacking away, or at a very early stage in the project, PaaS is still the fastest approach to get something running in production. At that point, you do not need the cognitive overhead of what server, region, or deployment tool to use.

The issue isn't starting with PaaS; it’s sticking with it once the project has grown past the point where these tradeoffs make sense.

Conclusion: The End of the One‑Size‑Fits‑All Cloud

PaaS isn't dead. Sometimes, the balance just shifts to a different approach. Now, you might be thinking that not using a managed platform means doing extra work for no reason. But, this assumption comes from the time when the alternative was using bare metal hardware and writing deployment scripts from scratch.

You don't need to reject convenience. The difference between “managed” and “owned” isn't as big as you think.

The one-size-fits-all cloud had a good run. Now’s the time for you to thrive and reclaim the stack. Run it, observe it, and learn what it’s doing in the background.

The tools are already there. Deploy with Hatchbox, and let AppSignal tell you when your RAM needs to be bumped.