I assume a vm on DO is HA protected. Also storage might live on a Cluster. Did you consider a socond dedi or do you just accept the risk of longer failover time and data loss time (RPO) for recovering to a newly provisioned server? Would love to know your thoughts on this especially as the migration was well designed and executed.
Migrating from DigitalOcean to Hetzner
241–250 of 454 posts
Re: Migrating from DigitalOcean to Hetzner
#242I moved two servers, one from Linode and the other from DO to Hetzner a few months ago, with similar savings. The best part was that the two servers had tens of different sites running, implemented in different languages, with obsolete libraries, MySQL and Redis instances. A total mess. Well: Claude Code migrated it all, sometimes rewriting parts when the libraries where no longer available. Today complex migrations…
IMO nobody was paying for magic compute. they're paying to not touch ten years of glue.
if agents eat that glue, the moat gets thin fast.
Re: Migrating from DigitalOcean to Hetzner
#243This 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 also find bare metal to be a lot more performant in general
I measured this several years back and never looked at virtual servers again. Since CPU time isn't reserved (like RAM is), the performance is abysmal compared to real hardware.
https://jan.rychter.com/enblog/cloud-server-cpu-performance-...
Re: Migrating from DigitalOcean to Hetzner
#244Earlier quoted context omitted.
I have just seen with my own eyes Claude astroturfing on a gamedev subreddit from a botting account that was picked up by Google so I could see a few of their other comments. This account's operation was going on development subs complaining about how good Claude's latest model is and how awful it is being afraid of losing one's job to AI. I know your comment is tongue-in-cheek and the poster here is kinda known, but…
It's not necessarily astroturfing. There is a seismic shift under way regarding how things get done in this business, and if you don't acknowledge it, that's weird in itself.
I've certainly noticed a seismic shift in how bad support and updates have gotten with some 3rd party vendors we use, and the answer they come back with is always that they're experimenting with AI. Not saying AI isn't part of the job now, but it is getting seriously over hyped and over extended.
Re: Migrating from DigitalOcean to Hetzner
#245We are currently moving from heroku to Hetzner. Same story, thousands saved / month.
Re: Migrating from DigitalOcean to Hetzner
#246Every time I see this kind of article, no one really bothers about sb/server redundancy, load balancers, etc. are we ok with just 1 big server that may fail and bring several services down? You saved a lot of money but you'll spend a lot of time in maintenance and future headaches.
It depends on the service and how critical that website is. Sometimes it's completely acceptable that a server will run for 10 years with say 1 week or 1 month of downtime spread over those 10 years, yes. That's the sort of uptime you can see with single servers that are rarely changed and over-provisioned as many on Hetzner are. Some examples: Small businesses where the website is not core to operations and is more…
A week of downtime every decade I think still works out to a higher uptime than I've been getting from parts of GitHub lately. So I'd consider that a win.
Re: Migrating from DigitalOcean to Hetzner
#247Earlier quoted context omitted.
I have just seen with my own eyes Claude astroturfing on a gamedev subreddit from a botting account that was picked up by Google so I could see a few of their other comments. This account's operation was going on development subs complaining about how good Claude's latest model is and how awful it is being afraid of losing one's job to AI. I know your comment is tongue-in-cheek and the poster here is kinda known, but…
I see a lot of these posts on Reddit, too, but I don't think it's actually Anthropic or Claude doing it. It's the same old Reddit karma farmers picking up on the latest trends. They've always combined headlines with ragebait to build karma and now LLM bots make it easier than ever. It's too bad Reddit allows accounts to hide their comment history now. That was an easy way to identify bot accounts before they started…
That is a pity but on the bright side it also helps people to avoid being stalked and harassed.
Re: Migrating from DigitalOcean to Hetzner
#248I moved two servers, one from Linode and the other from DO to Hetzner a few months ago, with similar savings. The best part was that the two servers had tens of different sites running, implemented in different languages, with obsolete libraries, MySQL and Redis instances. A total mess. Well: Claude Code migrated it all, sometimes rewriting parts when the libraries where no longer available. Today complex migrations…
Wow a Claude add embedded into a Hetzner add. How deep does this go?
This is the redis guy you're replying to, I doubt he's on Claude's payroll
Re: Migrating from DigitalOcean to Hetzner
#249> Old server: CentOS 7 — long past its end-of-life, but still running in production. New server: AlmaLinux 9.7 — a RHEL 9 compatible distribution and the natural successor to CentOS. So they did same mistake all over again. Debian or Ubuntu would just be upgrade-in-place and migrate
I work with Linux deployments for a living and I have no idea what you are talking about.
[flagged]
Re: Migrating from DigitalOcean to Hetzner
#250If you’re migrating a large MySQL database and you’re not using mydumper/myloader, you’re doing it the hard way. If you aren't using xtrabackup you are doing it wrong. I recently migrated a database with 2TB of data from 5.7 to 8.4 with about 15 seconds of down time. It wouldn't have been possible without xtrabackup. Mysqldumper requires a global write block, I wouldn't call blocking writes for hours a "zero downtime…
Correct me if I'm wrong, but done with a proxy in-between that can "pause" requests, you could have done the move with 0 seconds and no rejected requests, and I don't think mydumper/myloader/xtrabackup matters for that. The "migration" would be spinning up a new database, making it catch up, then switching over. If you can pause/hang in-flight requests while switching, not a single one needs to fail :)
The "making it catch up" is the tricky part. You need an initial backup for that. xtrabackup can take that backup "hot" without blocking read/writes. mysqldumper will block writes for whatever time that initial backup takes, for 2TB of data that's going to be hours.
Once you have that initial back up you can set your replica and make it catch up , then you switch. I choose to take the few seconds of downtime doing the switch because for my use case that was acceptable.