Ditching PaaS: Why I Went Back to Self-Hosting

I had never been a fan of devops/server-admin work. The sheer number of headaches involved in setting up the services, configuring them, automating them, and ensuring their reliability were just annoying and time-consuming.

PaaS offerings like Heroku, AWS—and later—Railway, and Render, were appealing options out of this mess. I could do everything from the web interface and didn’t have to run a bunch of commands now and then. I switched to PaaS when they started to look affordable and didn’t look back for many years.

In recent times, my opinion about self-hosting has changed. Instead of paying for multiple services, I am now renting a decently sized VPS on Scaleway, and hosting all my projects on them. It’s been three months, and it has been working out great for me.

Why did I make the switch? Two things happened: I started seeing the disadvantages of using PaaS. I also started seeing self-hosting in a more positive light.

Here’s why PaaS soured on me:

1. PaaS can become very costly: The big advantage of PaaS is that you can start any service (website, database, cache) with a click of a button. But this can also come to bite you when it comes to the cost. No matter how small is the service, no matter how rarely you need it, you’d need to pay the full price. Say, for a service you need a cache, a web app, and a database. The cost can quickly mount to $20-40 a month.

   My biggest beef with this model was the need to pay for a separate service even when I just needed to host a simple API or a cron job.

   This might not matter if you’re already making money, but right now, a single server fits better for my needs.

2. PaaS takes away your flexibility: PaaS looks like a good option if you’re just concerned with a particular task/service, but sometimes, you also want to use the compute to run cron jobs, run background jobs, or host a small service. With PaaS, you don’t have the flexibility to do so. I hack a lot of projects, and being limited by the options PaaS offered felt annoying.

3. PaaS offers low compute for the price: This is a no-brainer. PaaS is always going to offer less for the same price, but what surprised me was how start the difference can be. On Render.com, a 4GB RAM and 2vCPU service costs $85/mo. The same spec costs $14/mo on Scaleway (ARM). Granted, I don’t need to start with a high-spec machine, but having so less compute for the same price started to feel like an unattractive option.

At the same time, I started seeing self-hosting more favorably.

1. Self-hosting has Become Easier: My dislike for self-hosting stemmed from the pain of setting up different services (nginx, postgres, redis). Each involved a separate set of commands. Not only I had to ensure that each service was configured correctly, I had to make sure they started up automatically during the server restarts. Bash scripts were the only tool I used. And boy, they were a mess.

   With docker, this has become way, way easier. I only need to setup docker-compose.yml and use containers that devs have already built for almost all services. The containers handle most of the heavy work, so I don’t have to mess with configurations.

   Caddy was another tool that surprised me positively. It has a leaner config syntax than nginx and comes with automatic HTTPS.

   Github Actions is another addition that made the automation part simple. Earlier automating things from your repo involved setting up webhooks and creating listeners on your server. Now, it can be done with ‘.yml’ file

   The new tooling has made self-hosting way easier than it was before.

2. Self-hosting has become more reliable: Because of docker, self-hosting has also become way more reliable than it was before. You don’t have to worry about a service eating up all your RAM. You can configure it. Ensuring everything starts up automatically during restarts is as easy as, sudo systemctl enable docker.

   docker logs is a single command to access a service’s logs. Way better alternative than fiddling with log.d directories.

   Bot attacks were another headache. One can now use Cloudflare to deter most of these attacks (even on the free plan).

   Keeping services running reliably seems way easier now.

3. Flexibility is awesome: Being able to host any service, or run any job, just by updating a few files, feels way easier than creating a new service on PaaS platforms.

On the negative side, having a single machine creates a single point of failure. Creating failover instances, or things like automated backups and recovery, is still something I need to figure out. Probably, it’s not that simple with self-hosting. However, depending on what you’re building you can be a little flexible with the requirement.

Conclusion

I think self-hosting is a better option when you’re in the hacker stage and haven’t yet started making money. The big advantage is the ability to explore multiple different ideas on the same machine. Of course, this also depends on your level of comfort with Linux and the command line. Docker makes things easier but it still requires working knowledge of server administration.

I found a good fit with self-hosting, and if you are like me, who wrote it off years ago, maybe it’s time to give it another try.