Not another cloud billing horror story
There are plenty of horror stories with obscene bills from cloud providers. Fortunately, I am not in that category, but I don’t want to become complacent either.
Updated August 2026 - I wrote this in June 2024, a couple of weeks after the migration, when Coolify was still in beta. Two years later the whole GetSite stack (including this blog) still runs on it, and Coolify v4 finally hit stable. I kept the original story as-is and added a “two years later” section at the end with what changed.
Old infrastructure
GetSite started with a hybrid infrastructure. Some services were deployed on Hetzner with Rancher, and others were split between AWS and MongoDB.
On the MongoDB cloud, I was using Atlas and ran a serverless instance for the database. The invoices started to ramp up, but not in direct proportion with the traffic we were getting. At first, it was a couple of monthly bucks and very quickly increased to $40 / mo. As you might have guessed, this was a strong motivator for moving from Mongo.
Before making the move, I tried to figure out what inflated the invoices so much. The database instance was getting 20 req/s at all times, and had no idea why. The official support was quite unresponsive and not helpful in this regard.
Mind you, this spike in requests started about a month ago, however, the traffic to GetSite didn’t increase. Something’s fishy if you ask me, but I didn’t want to spend more time looking into it.
On AWS, I had a few Elastic Beanstalk instances that were quite expensive compared with Hetzner. The instances were part of an autoscaling group.
Did I mention I was using Rancher 1 for the self-hosted services? It is a great piece of software, but it was discontinued a while back. Rancher 2 is very complex to use and geared towards enterprise users and big clusters.
New infrastructure
Enter Coolify, the successor to Rancher. I have been trying to find a replacement for Rancher for a few years. All container managers (Portainer included) seem to be tailored to the enterprise. I read about Coolify a few months ago but wasn’t convinced. Their website is not doing them justice.
A couple of weeks ago, after the inflated MongoDB invoice, I decided to jump in and install Coolify on a Hetzner server. The onboarding process is a bit unintuitive, but it grew on me as I started using it.
I moved all services from AWS, MongoDB, Rancher, and some old MySQL and Redis servers to Coolify in a day. Spent another day setting up workers, load balancers, backups, and security, and testing everything out. All of this while keeping 100% uptime (ok… maybe like 99.99%).
Costs
I cut costs down to about $40 / month for the whole infrastructure. That’s how much the last MongoDB invoice was, for reference. While bringing the cost down, I also beefed up the server capacity. The current setup has plenty of spare room for future growth.
Two years later (August 2026 update)
The short version: I would make the same call again, sooner.
Everything I migrated in 2024 is still running on the same Coolify setup on Hetzner - the API, the workers, the databases, the marketing site, and this blog (which I later moved off Ghost onto the main app, also deployed through Coolify). The monthly bill has stayed flat while GetSite’s traffic and the number of deployed services grew. No cloud invoice surprises in two years.
Coolify v4 is finally stable
When I wrote this post, Coolify v4 was in beta - and it stayed in beta for a remarkably long time. In April 2026, after roughly two years and hundreds of beta releases, v4.0.0 went stable. The releases since then have kept a steady pace:
- The UI became a proper single-page app. The old full-page Livewire reloads are gone, which fixes most of the “unintuitive onboarding” I complained about above. It feels like a finished product now.
- v4.1 added Railpack as a build pack option next to Nixpacks and Dockerfiles, with build-time environment variables and multi-stage builds. I still deploy most things with plain Dockerfiles - boring, but nothing to debug.
- Audit logging and an MCP server landed at the instance level, so API mutations are traceable and AI agents can read your Coolify resources. Niche, but I have started poking at the MCP integration from Claude Code.
- v5 is in development, focused on horizontal scalability in the core. Importantly, the team has said v4 support continues - so no forced migration on the horizon.
What I would do differently
Not much, honestly, but a few notes for anyone doing this migration today:
- Do the move in one push. The band-aid approach from the title held up. Running half your stack on the old infra and half on the new one is the worst of both worlds - you pay twice and debug across two systems.
- Set up backups before you migrate data, not after. Coolify’s built-in scheduled database backups to S3-compatible storage are good; configure them on day one.
- Keep the Coolify server itself boring. One dedicated Hetzner box, automatic OS updates, and Coolify’s own auto-update enabled. The less you customize the host, the less there is to break.
- Uptime is still public if you want to check my homework.
Self-hosting in 2024 felt like a contrarian bet. In 2026, with v4 stable and a real company behind the project, it is just a sensible default for anyone comfortable with a terminal.