The HN Front Page Just Told Every Indie Dev to Leave DigitalOcean — The Hetzner Math Actually Works
The HN Front Page Just Told Every Indie Dev to Leave DigitalOcean — The Hetzner Math Actually Works
"Migrating from DigitalOcean to Hetzner: From $1,432 to $233/month With Zero Downtime" hit the top of Hacker News on April 18 with 727 points. It is not a Hetzner fan piece. It is a developer who ran the numbers, moved 24 production services over a weekend, and walked away saving $14,388 a year on a more powerful machine.
If your entire hosting story is "one DigitalOcean droplet I forgot to resize in 2024," this is the post that should make you open your billing page tomorrow. But only after you sit through the honest decision tree, because the Hetzner migration does not work for everyone, and the people for whom it does not work will lose more than they save.
The Headline Numbers
$1,432 per month dropped to $233 per month. Thirty-two vCPUs upgraded to ninety-six logical CPUs. Twenty-four hours of migration work. Zero user-facing downtime. Roughly $14,000 saved per year at the small-business scale.
Those are the attention-grabbing numbers, and they are real. They are also the high end. Most solo operators are not running a $1,400 a month DigitalOcean bill. But the cost ratio holds all the way down the tier list.
A Hetzner CPX22 — two vCPUs, four gigabytes of RAM — costs about €7.99 a month, which runs to just under $9.50 depending on the exchange rate. The equivalent DigitalOcean Basic Droplet is $24. Hetzner includes twenty terabytes of monthly egress on that tier. DigitalOcean includes four.
If your solo setup is one mid-sized box plus some egress, you are probably looking at a 50 to 70% monthly saving, not 85%. Still substantial. Still worth an afternoon.
What DigitalOcean Does That Hetzner Does Not
This is the part the cost-comparison posts rush past, and it is the part that decides whether the migration is actually a good idea for you.
Hetzner does not offer managed databases. You run your own Postgres, your own Redis, your own backups. When something breaks, it is your problem at 3 AM.
Hetzner does not offer managed Kubernetes. You roll your own, or you use something like K3s on top of raw servers.
Hetzner does not offer managed load balancers in the DigitalOcean sense. You run HAProxy or Caddy yourself.
Most importantly, Hetzner does not offer automatic failover. When a Hetzner host node fails, your server goes down until either the hardware issue is resolved or you manually intervene. There is no live migration. There is no automatic restart on a different host. Your uptime SLA is your responsibility entirely.
DigitalOcean is not cheap because a lot of ops work is already baked in. Hetzner is cheap because a lot of ops work is not.
The Honest Solo Operator Decision Tree
Answer two questions honestly.
First, are you comfortable running systemd, nginx, and a Postgres backup strategy yourself? Not in theory — in practice, at midnight, when your database is down and you are trying to remember whether you tested the restore path three months ago. If the answer is yes, Hetzner is probably a good call. If the answer is "I would figure it out," the migration is going to cost you more than $14,000 in the form of a bad weekend.
Second, where does your time bleed out right now? If you already spend your evenings tinkering with infra, saving $40 or $100 a month by running more of your own infra is a fair trade. If you barely have time to ship features, the DigitalOcean surcharge is buying you time, not just compute. Keep paying it.
There is a third category worth naming: Render, Railway, and Fly. These are PaaS-style platforms that are neither Hetzner-cheap nor DigitalOcean-managed-database-expensive. For a solo operator who wants managed Postgres, push-to-deploy, and a reasonable monthly bill without running their own servers, these are often the right answer, and the Hetzner migration posts never compare them because they are not in the same category.
If you are moving off DigitalOcean to save money, it is worth running the math against a Render or a Fly deploy before defaulting to "I will rent a Hetzner box and configure it myself."
The Migration Itself
If you have decided you want to do it, the zero-downtime version is well-understood now.
Provision your new Hetzner box. Install the same stack — same Postgres version, same application runtime, same nginx config. Bring over your application code and your environment configuration. Do a full staging run to verify it works end to end.
For the data migration, set up streaming replication from your old Postgres to the new one. When the replication lag is under a few seconds, stop writes on the old database, wait for the replica to catch up, promote the replica, and point your application at the new database. DNS-level cutover for the web layer lands in a few minutes of observable latency, not real downtime.
The full playbook is in the original Isa Yeter post, and it is worth reading end to end before you touch anything. Zero-downtime migrations are not hard in 2026, but they are hard the first time you do one, and the first time is not the time to improvise.
The European Data Center Thing
The one objection that comes up constantly: Hetzner's data centers are in Europe. If your users are all in North America, you add 80 to 120 milliseconds of latency on every request.
The honest answer: it matters for some products and not for others. A real-time multiplayer game cares. A dashboard that loads once per session with good client-side caching mostly does not. A blog or a content site basically does not. A transactional SaaS with chatty API patterns probably does.
Measure. Do not assume. Push a copy of your app to a Hetzner box in Frankfurt or Falkenstein for an afternoon and put your real frontend against it. If the p95 latency is acceptable, the migration is on the table. If it is not, it is not.
Hetzner is also quietly expanding US capacity. The calculus on this is going to keep shifting.
What I Actually Did
I already ran this migration on my own stack six months ago. Three servers went over, one stayed on DigitalOcean because the managed database it relied on was doing too much work I did not want to replicate, and one went back to DigitalOcean after two months because I did not like running my own Postgres on a non-failover host for a workload that actually mattered.
That is the shape of a sensible migration. Not "move everything to Hetzner and save $200 a month." Move the workloads where the ops cost is low and the compute cost is high. Keep DigitalOcean or a PaaS for the workloads where you want managed anything.
The solo operator version of this is not ideology. It is arithmetic.
The One Thing to Check Tonight
Open your DigitalOcean (or Render, or Vercel, or Fly) billing page. Write down what you pay monthly. Write down what you would pay for the equivalent Hetzner CX-series instance. Subtract. Multiply by twelve.
If the difference is under $500 a year, stay where you are. The ops tax is not worth it.
If the difference is over $2,000 a year and you are comfortable running your own stack, set aside a Saturday. Run the migration on one non-critical service first. See how it feels. Decide from there.
If you are between those numbers, use the extra money to pay for your time back somewhere else — an accountant, a VA, a cleaner. Hosting cost arbitrage is real, but it is not the most valuable arbitrage available to a solo operator. Your time still is.