Migrating from DigitalOcean to Hetzner: From $1,432 to $233 With Zero Downtime
In this technical retrospective (2026), @yusufusta shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Post-ZIRP & AI (2023–2026)
COMMUNITY SCORE ★ 38 points
TOTAL DISCUSSIONS 12 comments
I migrated from Google Cloud to Hetner beginning of March. I currently have about 9 vms running and I pay a around 130 euro per month. There are very little other fees and generous freemiums for things like networking and storage. I have 3 projects, one LB, a handful of storage buckets, and a private network in one of the projects. That 130 is for everything. Their 40% price increase kicked in shortly after I signed up. It's still very affordable and good value. Their support was very helpful when a few days in I requested additional server quota.
The flip side is technical limitations and reliability. We've had a few network glitches. The vm boot disks are unencrypted (not ideal). And a few other things. Do your homework before you migrate. Most of these things you can DYI around.
I managed the whole migration via Codex orchestrating my Ansible scripts. It made fast work out of figuring out how to do NAT in Hetzner private networks and a few other hairy issues that would have otherwise derailed me for a bit. I got the whole migration completed in two days.
You get what you pay for with Hetzner and it is good value. But if you need more than they offer, you might want to look at other companies. They scale by keeping things simple. This is my second time with Hetzner. We used them around 2013 for a bit. I had six bare metal servers at the time for something like 300/month in total.
This is something we've[0] done a number of times for customers coming from various cloud providers. In our case we move customers onto a multi-server (sometimes multi-AZ) deployment in Hetzner, using Kubernetes to distribute workloads across servers and provide HA. Kubernetes is likely a lot for a single node deployment such as the OP, but it makes a lot more sense as soon as multiple nodes are involved.
For backups we use both Velero and application-level backup for critical workloads (i.e. Postgres WAL backups for PITR). We also ensure all state is on at least two nodes for HA.
We also find bare metal to be a lot more performant in general. Compared to AWS we typically see service response times halve. It is not that virtualisation inherently has that much overhead, rather it is everything else. Eg, bare metal offers:
- Reduced disk latency (NVMe vs network block storage)
- Reduced network latency (we run dedicated fibre, so inter-az is about 1/10th the latency)
- Less cache contention, etc [1]
Anyway, if you want to chat about this sometime just ping me an email: adam@ company domain.
[0] https://lithus.eu
[1] I wrote more on this 6 months ago: https://news.ycombinator.com/item?id=45615867
I use and love Hetzner as well. But you have to go into it eyes open. Concrete example - a month ago I was notified that network infra my systems ran over was going down for maintenance. Public link: https://status.hetzner.com/incident/ff8335b8-6fda-4370-8431-ae50022573fe
So, for me that was a production DB, fairly low usage but still. In the end I judged that it was going to take so much time to work around the outage that I just planned "maintenance downtime" myself and took it offline for a couple of hours until they finished.
Now, could I have architected better? No doubt. But it's a good reminder of what you're paying for and where the differences emerge in practise. AWS may be an overcomplicated, expensive mess - but I've literally never had any service of theirs go down for maintenance for any reason. Outages, sure, but taking things down for routine maintenace? Unheard of at AWS.
For me the formula is - I do whatever I want for my stuff, but if it's someone else's business, I use AWS.
And DigitalOcean customer support is non-existent. I had a mail server down and they cut service instead of trying to contact me in any other way. But worse, when they do that, they immediately destroy your data without any possibility to restore. Or at least that's what they told me with their bog standard, garbage support replies. I was a customer for nearly a decade. After it happened, I realized that never would have happened on GCP, AWS, etc. Because they take billing seriously with multiple contact info, a recovery period, etc. All the things a company would be expected to do to maintain good relationships with customers during a billing issue that lasts a few weeks. That was a couple of years ago, so maybe they fixed some stuff. But the complete lack of support and unprofessional B2B practices was an eye opener.
DigitalOcean just absolutely is just not an enterprise solution. Don't trust it with your data.
Oh, and did I mention I had been paying the upcharge for backups the entire time?
I had my fair share of Hyperscaler -> $something_else migrations during the past year. I agree, especially with rented hardware the price-difference is kind of ridiculous.
The issue is though, that you loose the managed part of the whole Cloud promise. For ephemeral services this not a big deal, but for persistent stuff like databases where you would like to have your data safe this is kind of an issue because it shifts additional effort (and therefore cost) into your operations team.
For smaller setups (attention shameless self-promotion incoming) I am currently working on https://pellepelster.github.io/solidblocks/cloud/index.html which allows to deploy managed services to the Hetzner Cloud from a Docker-Compose like definition. E.g. a PostgreSQL database with automatic backup and disaster recovery.