The Self-Hosting Rabbit Hole

Trading convenience for over-optimization is a sin that has killed the momentum of many projects. But if you lower the stakes and package this swap as a learning opportunity, it suddenly becomes excusable, even encouraged.

Until recently, I was a paying customer of a cloud-hosted analytics platform built on an open-source core. Then I turned to Coolify, a PaaS (Platform as a Service) for managing self-hosted codebases, to try running that same open-source version myself. In fact, I was so excited to finally try out Coolify, I was actually looking forward to the DevOps headaches I was inevitably about to run into.

I already had servers up in production, and my Plausible Analytics bill was getting expensive. However, the convenience of the low-hanging fruit or cost-cutting played no major role here. The possibility of introducing a significant improvement to my usual deployment workflow was the real catalyst.

If you're already familiar with platforms like Heroku or Vercel, you know that you're paying for the convenience of running your code on AWS's infrastructure without dealing with AWS's complexity. These platforms "wrap" the power of the Amazon's cloud, and serve it to their customers in a streamlined form. This is more convenient for someone with no DevOps experience, and people are often willing to pay a premium for convenience.

Think of Coolify as a similar abstraction layer - it simplifies the process of managing your own server, removing much of the manual configuration.

Without Coolify:

  • you need to manually ssh into your server
  • configure Nginx
  • use docker compose to orchestrate your database, backend, frontend, etc.
  • need a to deploy the latest version of your applictaion? you need to ssh again and pull the latest updates from your remote.

With Coolify:

  • you access your server via a web interface
  • you link it to your own GitHub account
  • select the repos Coolify should have access to
  • every push to the main/ master branch will trigger a new production deployment; no need to ssh into your server and clone the latest version of your repository

Is life without Coolify really that bad? No, not at all. It's like driving a car with manual transmission. If you're a real car buff, you might actually like it better. I know I do.

Additionally, too much abstraction can take the fun away. In the right scenario, abstraction makes processes more efficient. A human will never be able to shift gears as fast as an automatic transmission, and I will need to take just a bit longer to deploy my apps without something like Coolify.


How to start self-hosting

I use servers with dedicated vCPUs from Hetzner. You can get a VPS capable of running production applications, for $20/mo ($15 for the server + $5 for the automatic backups). The costs are capped (better said, fixed), so you won't have any unpleasant surprises when you get the monthly bill.

I initially installed Coolify on an existing VPS that already had a few manually configured containers. This made setting up Coolify more complicated than it had to be. Simply running docker-compose down wasn’t enough to avoid conflicts. Because of this, I highly recommend installing Coolify on a fresh server.

In fact, the most time-consuming problem I faced could have been avoided if I had started with a clean server. After completing the setup, I ran into an issue where Coolify was running properly, but the server itself was inaccessible from localhost.

Coolify Dashboard

I only discovered the real cause a few days later when I tried assigning custom subdomains. The issue? Coolify’s built-in proxy (Traefik) was being blocked by Nginx, which was still running from my previous container setup.

The issue in question:

Server is not reachable. Reason: root@host.docker.internal: Permission denied (publickey).

For a step by step guide that walks you through installing Coolify, check out my DevOps repository.


Why add another layer of complexity?

Vendor lock-in is always a risk. When a platform controls both your tooling and your infrastructure, they can raise prices overnight, and there’s not much you can do about it. That’s what happened with Heroku in 2022. Heroku was my go-to place for launching my Django projects. Additionally, Heroku was an important platform for researchers and hobbyists. 6 years ago, every cool Computer Vision project I was seeing on Twitter was hosted on Heroku.

Unfortunatelly, Vercel followed a similar path in 2023. Crazy pricing changes. This was even more concerning. Since Vercel makes Next.js, it’s no surprise that deploying Next.js apps over there is a smooth experience. But what happens when you want to leave?

People talk as if hosting Next.js outside Vercel is some huge ordeal, but in my experience, it’s been surprisingly easy. I kept seeing posts on Twitter/X about how difficult it was, so I expected a mess. Instead, I found that with a bit of configuration, it works just fine on a basic VPS. It’s not quite as plug-and-play as Vercel, but it’s nowhere near the nightmare people make it out to be.

That said, I still have projects hosted on Vercel. I respect the fact that they at least offer a free tier for early-stage projects. If they ever get rid of that though, I imagine we’ll see history repeat itself.


Further down the rabbit hole

I was already comfortable running my own code on my own infrastructure. By hosting Plausible myself, I was joining a growing trend in tech—people running their own instances of open-source software: sometimes to learn, sometimes to save money, sometimes just for the fun of it.

When you build something yourself, you know exactly how it works. If something breaks, you can usually guess why. But running someone else’s code is different. It comes with its own assumptions, constraints, and quirks that you have to figure out as you go.

There was a time when the Coolify team offered Plausible as a 1-click install, but due to a dispute, this option is not longer available. With that said, Plausible is still an easy deployment. But I couldn't resist looking deeper into its inner workings.

One interesting discovery was Plausible's data storage approach: PostgreSQL for transactions and ClickHouse for OLAP. I'd worked with analytical databases in ML pipelines before, where query speed on large datasets matters. Seeing these two types of databases working together in a production system showed me how they complement each other in practice.

Figuring this process out was so much fun, I already have my eye out for other prospective self-hosted candidates.

Final thoughts

Why would anyone pay for Plausible's hosted version when they could just run it themselves?

I believe it is for the same reason people use Heroku or Vercel instead of raw AWS (which is already an abstraction in itself). Sure, you don't technically need them, but AWS is for professionals, it is complex. Regular people value simplicity.

Plausible works the same way. The community edition is free, but running it yourself means handling servers, maintenance, and updates. If you choose their cloud version, you don't have to worry about any of that.

Additionally, they have employed a really smart tactic. To create a protective barrier for their paid version, they only update the open-source release twice a year. This way, they can claim that their Plausible is "cutting edge" and the Community Edition is "stable".

This is a dream scenario for them. Since they've reached a critical mass of users, and an even more impressive fanbase, the open source community builds their product, while they focus on keeping the business viable. Lesson learned. I am actually applying this to one of my own projects.

Self-hosting is a great learning experience. But at the end of the day, the real question is: are you in the right position to trade convenience for optimization?


Bogdan Andrei, 2025

Coolify
Plausible Analytics