I had to ban the whole DigitalOcean AS. Full of scanners, script kiddies and maybe worse.
My fail2ban is loaded with DO scanners everyday.
Migrating from DigitalOcean to Hetzner
321–330 of 454 posts
Re: Migrating from DigitalOcean to Hetzner
#322Earlier quoted context omitted.
What company can't pay 36 euro and legislate it after? Are hetzner in the wrong for denying service to clients in a deficit?
They stated to have the bank statements showing everything was paid but the company refused to look at it. Sounds like they may not have been in a deficit but company refused to look at anything
Then pay it again and sort it out after. There’s a time to be right and there’s a time to be pragmatic.
Re: Migrating from DigitalOcean to Hetzner
#323> The key: proxy_ssl_verify off — the new server’s SSL cert is valid for the domain, not for the IP address. Disabling verification here is fine because we control both ends.
Yeah - no, it's not. They made the MitM attack possible with this change. The exposure was limited to those 5 minutes, but it should have been a known risk.
Also not certain how they could check the apps on the new server with the read-only database, while it was a replica?
Still, nice to hear it succeeded, the reasons sound very familiar.
Re: Migrating from DigitalOcean to Hetzner
#324Earlier quoted context omitted.
They have to operate within the laws of the countries they’re physically located in. Those countries want to know that they’re not hosting illegal content, providing services to crime rings, Russia or North Korea, etc. If Hetzner allows you to host something and you use it for illegal acts, they aren’t going to jail to shield you for €10/month.
Hosting companies managed to shutdown illegal sites without requiring you to submit your pics and passport first. And if someone wants to do illegal things, what's stopping them from submitting a fake ID?
You buy your fake ids at the grocery store?
Re: Migrating from DigitalOcean to Hetzner
#325> The key: proxy_ssl_verify off — the new server’s SSL cert is valid for the domain, not for the IP address. Disabling verification here is fine because we control both ends.
Not really, a MITM could do anything here. It's not very likely to happen here, but I think this comment shows a misunderstanding of what certificates and verification does.
Re: Migrating from DigitalOcean to Hetzner
#326I 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…
I too, am bravely using Claude for more DevOps. I run all of my virtual machines on proxmox atop bare metal servers I own and I’m just blown away at how quickly Claude can optimize and set up entire new networks across all of these machines. Truly feels like a coworker or well paid sysadmin.
Re: Migrating from DigitalOcean to Hetzner
#327I 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.
The problem is a lot of this glue is proprietary by design at the various cloud services. I realize there are open source and alternative abstractions for a lot of of the same services, but there’s still quite a bit of glue if you’re on AWS, for example, and looking to move to bare metal.
But maybe I’m just thinking of the current capabilities of agents, and if we fast forward a couple years, even removing these abstractions or migrating will be very low friction.
Re: Migrating from DigitalOcean to Hetzner
#328I 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…
> Today complex migrations are much simpler to perform, which, I believe, will increase the mobility across providers a lot.
Syntax did a nice episode on this topic recently. They went over where it works well, and where it does not work well.
https://syntax.fm/show/992/migrating-legacy-code-just-got-ea...
Re: Migrating from DigitalOcean to Hetzner
#329Every 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.
Downtime happens in all different contexts of life that a web site/service being knocked offline is soo far down the priority list for most people.
It’s amusing that the US government can shutdown for days/weeks/months over budget reasons and there’s no adult discussions that take place about fixing the cause. Yet the latest HN demo that 100 people will use need all 9’s reliability and hundreds of responses.
Re: Migrating from DigitalOcean to Hetzner
#330Earlier quoted context omitted.
Surely you must've noticed that pretty much all of their bare metal offerings ("dedicated" and the stuff on "auction") have multiple disks, allowing for various RAID configurations?
> Surely you must've noticed that pretty much all of their bare metal offerings ("dedicated" and the stuff on "auction") have multiple disks, allowing for various RAID configurations? I don't know where to start with this comment. Do I really need to spell out the difference between cloud and bare metal ? A few examples... - Live migration ? Cloud only. - Snapshots ? Cloud only. - Want to increase disk space ? Tick b…
You can get snapshots and live migrations working on-prem. The cloud isn't magic, it's just servers with hypervisors and software running on top of them. You can run that same software.
Also, with something like Hetzner you would not be going in and physically doing anything. You also just tick a box for a RAM upgrade, and then migrate over or do active/passive switch.
The cloud does have advantages, mostly in how "easy" it is to do some specific workflows, but per-compute it's at least 10x the cost. Some will argue it's less than that, but they forget to factor in just how slow virtual disks and CPU are. Cloud only makes sense for very small businesses, in which the operational cost of colocation or on-prem hosting is too expensive.