Migrating from DigitalOcean to Hetzner
isayeter.com
isayeter.com
if agents eat that glue, the moat gets thin fast.
No wonder they hallucinate :)
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.
How deep does this go?
I know your comment is tongue-in-cheek and the poster here is kinda known, but this kind of astroturfing is a new low and it's everywhere on forums such as these.
Or maybe it's just advertising/astro-turfing. At some point it has to be obvious.
So it's a Claude ad inside a Hetzner ad inside a decent grammar ad.
I don't see it as much different from "I used script X to do it" or something.
It might surprise you to learn that nowadays there are a lot of people using LLM code assistants. Those who do can also use them to help them write blog posts.
Sure you lose a little of the benefit of a “virtual” server which can be migrated but Hetzner’s support has always been super fast and capable, should I wind up in a situation where I’ve got downtime.
Obviously I agree that AI can be useful to write boilerplate, but it's in no way something you should use blindly when trying to do a migration or anything touching prod
So, to be more precise: no, "Claude Code didn't migrate it all". Claude Code helped you write boilerplate so that you could migrate
And, recent research suggests that anthropomorphization may actually be positively correlated with intelligence.
I got a dedicated VPS just for the one thing and it did everything. I don't have a perfect understanding of possible openings that might have been left by misconfiguration. The data in question is so trivial that it doesn't matter to me if it's read so long as my VPS doesn't become party to a botnet and I can monitor to make sure that doesn't happen and shut it down if it does.
What’s exciting is how simple cli tools can be so impactful to dev workflows
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...
Amazon might think that they’re locking people in with the egress fees. But they’re also locking people out. As soon as you switch one part to a competitor, the high egress forces you to switch over everything.
It’s going to be complicated to switch, but it’s made easier by the fact that I didn’t fall into the trap of building my platform on Amazon-specific services.
AWS matched a few months later:
https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-i...
I'm not trying to convince you to stay (I work for neither anymore!), just wanted to note that you can technically request a waiver. I'm not sure how this works in practice though. Like, if you want to leave Athena and move to something on-premise is that enough to have just that workload? Maybe!
Edit: I also didn't follow this at the time, but the AWS wording suggests that the "EU Data Act" is also involved.
This doesn't actually work as advertised. I attempted free data egress from AWS in December. It took them 31 days to respond to my initial ticket. At which point they gave me a multi-page questionnaire to determine eligibility and they also told me I could not begin DTO until 60 days had passed from approval of the questionnaire.
By the time I was allowed "free egress" my cumulative S3 storage charges over the prior 100 days would have roughly matched the cost of egress if I just did so originally.
I'm in the US so the EU Data Act protections don't apply.
So in my case that would have been 14 weeks plus the time to migrate away. The egress costs are equivalent to around 17 weeks storage cost. So you save around 1c/gb if they don't find some reason to reject it.
https://digital-strategy.ec.europa.eu/en/factpages/data-act-...
You saved a lot of money but you'll spend a lot of time in maintenance and future headaches.
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 of a shop-front or brochure for their business.
Hobby websites too don't really matter if they go down for short periods of time occasionally.
Many forums and blogs just aren't very important too and downtime is no big deal.
There are a lot of these websites, and they are at the lower end of the market for obvious reasons, but probably the majority of websites in fact, the long tail of low-traffic websites.
Not everything has to be high availability and if you do want that, these providers usually provide load balancers etc too. I think people forget here sometimes that there is a huge range in hosting from squarespace to cheap shared hosting to more expensive self-hosted and provisioned clouds like AWS.
This is a general response to it.
I have run hosting on bare metal for millions of users a day. Tens of thousdands of concurrent connections. It can scale way up by doing the same thing you do in a cloud, provision more resources.
For "downtime" you do the same thing with metal, as you do with digital ocean, just get a second server and have them failover.
You can run hypervisors to split and manage a metal server just like Digital Ocean. Except you're not vulnerable to shared memory and cpu exploits on shared hosting like Digital Ocean. When Intel CPU or memory flaws or kernel exploits come out like they have, one VM user can read the memory and data of all the other processes belonging to other users.
Both Digital Ocean, and IaaS/PaaS are still running similar linux technologies to do the failover. There are tools that even handle it automatically, like Proxmox. This level of production grade fail over and simplicity was point and click, 10 years ago. Except no one's kept up with it.
The cloud is convenient. Convenience can make anyone comfortable. Comfort always costs way more.
It's relatively trivial to put the same web app on a metal server, with a hypervisor/IaaS/Paas behind the same Cloudflare to access "scale".
Digital Ocean and Cloud providers run on metal servers just like Hetzner.
The software to manage it all is becoming more and more trivial.
The confusing part about this article is the emphasis on a zero-downtime migration toward a service that isn't really ideal for uptime. It wouldn't be that expensive to add a little bit of architecture on the Hetzner side to help with this. I guess if you're doing a migration and you're paid salary or your time is free-ish, doing the migration in a zero downtime way is smart. It's a little funny to see the emphasis on zero downtime juxtaposed to the architecture they chose where uptime depends on nothing ever failing
Clever architecture will always beat cleverly trying to pick only one cloud.
Being cloud agnostic is best.
This means setting up a private cloud.
Hosted servers, and managed servers are perfectly capable of near zero downtime. this is because it's the same equipment (or often more consumer grade) that the "cloud" works on and plans for even more failure.
Digital Ocean definitely does not guarantee zero downtime. That's a lot of 9's.
It's simple to run well established tools like Proxmox on bare metal that will do everything Digital Ocean promises, and it's not susceptible to attacks, or exploits where the shared memory and CPU usage will leak what customers believe is their private VPS.
Nothing ever failing in the case of a tool like Proxmox is, install it on two servers, one VPS exists on both nodes (you connect both servers as nodes), click high availability, and it's generally up and running. Put cloudflare in front of it like the best preference practices of today.
If you're curious about this, there's some pretty eye opening and short videos on Proxmox available on Youtube that are hard to unsee.
Also, don't underestimate the reliability of simplicity.
I was a Linux sysadmin for many years, and I have never seen as much downtime from simpler systems as I routinely see from the more complicated setups. Somewhere between theory and reality, simpler systems just comes out ahead most of the time.
Usually those articles describe two situations:
- they were "on the cloud" for the wrong reasons and migrating to something more physical is the right approach
- they were "on the cloud" for the right reasons and migrating to something more physical is going to be a disaster
Dealing with over engineered bullshit, that behaved in strange ways that disrupted the service was far more often a problem.
So, yes, redundancy is something that can be left away, if you're comfortable to be responsible for fixing things at a Saturday morning.
As a bonus, Hetzner is European.
Like, I know Leetcode tells otherwise, but most companies really don't need full FAANG stack with 99.999% uptime. A day of outage in a few years isn't going affect bottom lines.
LARPing as a FAANG is waste of money and lots of companies doesn’t even need 3 nines let alone 5ve.
They saved money and lost nothing.
Now, if they so wish, they could use a portion of that to increase redundancy - but that wasn't the point of the article.
Given the downtimes we saw in the past year(s) (AWS, Cloudflare, Azure - the later even down several times), I would argue moving to any of the big cloud providers give you not much of a better guarantee.
I myself am a Hetzner customer with a dedicated vServer, meaning it is a shared virtual server but with dedicated CPUs (read: still oversubscribed, but some performance guarantee) and had zero hardware-based downtime for years [0]. I would guess their vservers are on similar redundant hardware where the failing components can be hotswapped.
[0] = They once within the last 3 years sent me an email that they had to update a router that would affect network connectivity for the vServer, but the notification came weeks in advance and lasted about 15 minutes. No reboot/hardware failure on my vServer though.
I know people like FAANG LARPing. Not everyone has budget or need to run four nines with 24/7 and FAANG level traffic.
If someone starts thinking about redundancy and load balancers than DO's solution is rent a second similar sized droplet, and then add their load balancing service. If you do those things with Hetzner instead, you would still be spending less than you did with Digital Ocean.
Personally, what is keeping me on DO is that no single droplet I have is large enough to justify moving on its own, and I'm not prepared to deal with moving everything.
Updates have zero downtime and there's lots of compute headroom so it never locks up.
No, there's no redundancy and it is only performant in a single region - but that's okay with the customer as it's just a custom CRM.
Not every use case requires Kubernetes, multiple nodes, dedicated database infra and auto-scaling.
Not a bad tradeoff for 99.8% of shops out there.
It seems that to start off the original system was hosted on a single Digital Ocean droplet with 32vCPUs and a total 192GB of RAM.
They switched to a single Hetzner AX162-R instance.
So the blogger switched from a single odd with 32 vCPUs to a dedicated server running a AMD EPYC 9454P and 256GB of RAM.
That should answer your question with a clear yes.
> You saved a lot of money but you'll spend a lot of time in maintenance and future headaches.
People underestimate how far you can go with one or two servers. In fact, what I have seen in ky career is many examples of services that should have been running on one or two servers and instead went for a hugely complex microserviced approach, all in on Cloud providers and crazy requirements of reliability for a scale that never would come.
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.
If you can tolerate few hours of downtime and some data rollback/loss, single server + robust backups can be viable strategy
Look from my perspective, I'll got flying color from my owner because of the cost saving and got my team morale up that I really need them to maintain the system instead of lay them off.
Also in some cases that also mean new jobs opening.
Deploying a new docker instance or just restoring the app from a snapshot and restoring the latest db in most cases is enough.
If your scaling need is not that high, you can get very far with a single server
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.
[1] I wrote more on this 6 months ago: https://news.ycombinator.com/item?id=45615867
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-...
My entire stack is.. k8s, hosted Postgres, s3 type storage. I can always host my own Postgres. So really down to k8s and s3. I think hetzner has some kind of s3 storage but haven’t looked into, and I assume moving in 100 TB is a process….
High availability, in case anyone else was wondering.
Your post was reasonable until the spam tagline.
Not cool.
I see the DigitalOcean vs Hetzner comparison as a tradeoff that we make in different domains all day long, similar to opening your DoorDash or UberEats instead of making your own dinner(and the cost ratio is similar too).
I work in all 3 major clouds, on-prem, the works. I still head to the DigitalOcean console for bits and pieces type work or proof of concept testing. Sometimes you just want to click a button and the server or bucket or whatever is ready and here's the access info and it has sane defaults and if I need backups or whatnot it's just a checkbox. Your time is worth money too.
You're describing Hetzner Cloud, which has been like this for many years. At least 6.
Hetzner also offers Hetzner Cloud API, which allows us to not have to click any button and just have everything in IaC.
One is about all the steps of zero downtime migration. It's widely applicable.
The other is the decision to replace a cloud instance with bare metal. It saves a lot in costs, but also the loss of fast failover and data backups is priced in.
If I were doing this, I would run a hot spare for an extra $200, and switched the primary every few days, to guarantee that both copies work well, and the switchover is easy. It would be a relatively low price for a massive reduction of the risk of a catastrophic failure.
i hardly ever visit their website, everything from terminal.
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.
So, not an exclusivity of Hetzner for sure.
I used to get those emails all the time, but the type of downtime they were talking about was extremely minimal (the entire point of VPS systems).
The last email I got about possible downtime was increased latency for the UI and API for ~10s last year. The email before that was ~5s of potential lost traffic to a droplet.
Because with a single-server setup like this, I'd imagine that hardware (e.g. SSD) failure brings down your app, and in the case of SSD failure, you then have hours or days downtime while you set everything up again.
Once the first SSD fails after some years, and your monitoring catches that, you can either migrate to a new box, find another intermediate solution/replica, or let them hotswap it while the other drive takes on.
Of course though, going to physical servers loses redundency of the cloud, but that's something you need to price in when looking at the savings and deciding your risk model.
And yes, running this without also at least daily snapshotting/backup to remote storage is insane - that applies to cloud aswell, albeit easier to setup there.
For quite a while we ran single power supplies because they were pretty high quality, but then Supermicro went through a ~6 month period where basically every power supply in machines we got during that time failed within a year, and replacements were hard to come by (because of high demand, because of failures), and we switched to redundant. This was all cost savings trade-offs. When running single power supplies, we had in-rack Auto Transfer Switches, so that the single power supplies could survive A or B side power failure.
But, and this is important, we were monitoring the systems for drive failures and replacing them within 24 hours. Ditto for power supplies. If you don't monitor your hardware for failure, redundancy doesn't mean anything.
Have 2x servers atleast then invest in proper monitoring.
Server can fail without disk failures.
Not every app needs 24/7 availability. The vast majority of websites out there will not suffer any serious consequences from a few hours of downtime (scheduled or otherwise) every now and then. If the cost savings outweigh the risk, it can be a perfectly reasonable business decision.
A more interesting question would be what kind of backup and recovery strategy they have, and which aspects of it (if any) they had to change when they moved to Hetzner.
Yeah. This blog post reads like it was written by someone who didn't think things through and just focused on hyper-agressive cost-cutting.
I bet their DigitalOcean vm did live migrations and supported snapshots.
You can get that at Hetzner but only in their cloud product.
You absolutely will not get that in Hetzner bare-metal. If your HD or other component dies, it dies. Hetzner will replace the HD, but its up to you to restore from scratch. Hetzner are very clear about this in multiple places.
Recently, I did it in PostgreSQL using pg_auto_failover. I have 1 monitor node, 1 primary, and 1 replica.
Surprisingly, once you get the hang of PostgreSQL configuration and its gotchas, it’s also very easy to replicate.
I’m guessing MySQL is even easier than PostgreSQL for this.
I also achieved zero downtime migration.
However, the dealbreaker for me was that Hetzner IPs have a bad reputation. At work, I learned that one of the managed AWS firewall rules blocks many (maybe all) of their IPs. I can’t even open a website hosted on a Hetzner IP from my work laptop because it’s blocked by some IT policy (maybe this is not an issue for you if you are using CloudFlare or similar).
I've read online that the DDoS protection is very bad as well.
So in the end, I picked DO App Platform in one of the EU regions. Having the option to use a managed DB was a big plus as well.
https://news.ycombinator.com/item?id=47279518
It looks like Hetzner is Tor (and Tor adjacent) friendly, I suggested this might affect IP reputation, 2 users responded they had no IP reputation issues. But it looks like that wasn't quite the whole story
https://community.torproject.org/relay/community-resources/g...
It seems that Hetzner holds 7% of the Tor network. (if I understood the table right)
so much that I'm thinking of selling nothing but an aws and azure blocker as a service.
source: moved away from DO for this very reason.
I wish the industry would adopt more zero knowledge methods in this regards. They are existing and mathematically proven but it seems there is no real adoption.
- OpenAI wants my passport when topping up 100 USD
- Bolt wanted recently my passport number to use their service
- Anthropic seems wants to have passports for new users too
- Soon age restriction in OS or on websites
I wished there would be a law (in Europe and/or US) to minify or forbid this kind of identity verification.
I want to support the companies to not allow misuse of their platforms, at the same time my full passport photo is not their concern, especially in B2B business in my opinion.
Absolutely no to this - reason enough to go with AWS or alternatives. And why are ppl willingly giving it to hosting providers?
Unnecessarily exposing yourself to identity theft if they get compromised.
Not sure what differs in our cases, I'm based in EU.
Recently we had several of our VMs offline because they apparently have these large volume storage pools they were upgrading and suddenly disks died in two large pools. It took them 3 days to resolve.
Hetzner has no integrated option to backup volumes and its roll your own :/ You also can't control volume distribution on their storage nodes for redundancy.
Sure, it cost me £6/mo to serve ONE lambda on AWS (and perhaps 500 requests per month). Sure it was awesome and "proper". But crazy expensive.
I host it now (and 5 similar things) for free on Cloudflare.
But if you need what AWS provides, you'll get that. And that means sometimes it's not the most cost-effective place.
It's worse than Oracle and they don't even use lawyery contracts.
The technology itself is the tendrils.
If you’re migrating a large MySQL database and you’re not
using mydumper/myloader, you’re doing it the hard way.
Aside from the blocking you mentioned during the initial snapshot, you'd need to block writes to the old DB before the cutover as well. There's no way to guarantee in-flight writes to the old DB aren't lost when promoting the replica to a primary otherwise. I'm surprised the author didn't go into more detail here. Maybe it was fine given their workload, but the key issue I see is that they promoted the new DB to a primary before stopping the old application. During that gap, any data written to the old DB would be lost.
Now, prices are so bad that I have to choose between a bare metal server with 500 GB of SSD storage, 16-core CPU and 16 GB of RAM with OVH or a VM with 1/10 of that with Vultr.
It doesn't make any sense.
Also, Vultr has the nasty policy of topping your account $100 whenever you run out of money, even if your server is $3/month.
Last weekend, I transferred a handful of personal projects and my monthly expense for hosting went from $500 to $100, for vastly superior servers.
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.
Anyone who thinks DO and Hetzner dedicated servers are fungible products is making a mistake. These aren't the same service at all. There are savings to be had but this isn't a direct "unplug DO, plug in Hetzner" situation.
One of the new risks is if anything critical happens with the hardware, network, switch etc. then everything is down, until someone at Hetzner go fixes it.
With a virtual server it’ll just get started on a different server straight away. Usually hypervisors also has 2 or more network connections etc.
And hopefully they also got some backup setup.
It’s still a huge amount of of savings and I’d probably do the same of I were in their shoes, but there is tradeoffs when going from virtual- to dedicated hardware.
As the other person already said here, this blog post comparison is skewed.
BUT
EU cloud providers are much better value for money than the US providers.
The US providers will happily sit there nickle and diming you, often with deliberately obscure price sheets (hello AWS ;).
EU cloud provider pricing is much clearer and generally you get a lot more bang for your buck than you would with a US provider. Often EU providers will give you stuff for free that US providers would charge you for (e.g. various S3 API calls).
Therefore even if this blog post is skewed and incorrect, the overall argument still stands that you should be seriously looking at Hetzner or Upcloud or Exoscale or Scaleway or any of the other EU providers.
In addition there is the major benefit of not being subject to the US CLOUD and PATRIOT acts. Which despite what the sales-droids will tell you, still applies to the fake-EU provided by the US providers.
Moving away from the US also felt great.
Happened to me.
I now advise people to avoid clown-led services like Hetzner and stick to more reputable, if not as cheap, options.
Sounds like from the requirement to live migrate you can't really afford planned downtime, so why are you risking unplanned downtime?
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?
BTW, I've been a client of Hetzner (Cloud, Object Storage, and Storage Box) for a few years now, very happy with them!
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.
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.
As such, I doubt the noted price reduction is reproducible. Combine this with Hetzner's sudden deletions of user accounts and services without warning, and it's a bad proposition. Search r/hetzner and r/vps for hetzner for these words: banned, deleted, terminated; there are many reports. What should stun you even more about it is that Hetzner could ostensibly be closely spying on user data and workloads, even offline workloads, without which they won't even know who to ban.
The only thing that Hetzner might potentially be good for is to add to an expendable distributed compute pool, one that you can afford to lose, but then you might as well also use other bottom-of-the-barrel untrustworthy providers for it too, e.g. OVH.
> $1,432 to $233
a difference of 5/6 in price does not materially change the decision to move between providers, even with a 40% price increase
One thing people skip: you also lose AWS's managed failure modes. Managed Postgres, VPC peering, IAM roles on instance metadata - you now own all of that. For a solo project or small team that's fine (rsync + pg_dump | pg_restore has worked for 20 years). For anything with on-call rotations it's a meaningful shift.
So a big win win all round. So good to see European providers are finally having their moment.
* I wish there were even more available and not sold out regions across Europe.
They do offer VPS in the US and the value is great. I was seriously looking at moving our academic lab over from AWS but server availability was bad enough to scare me off. They didn't have the instances we needed reliably. Really hoping that calms down.
Nice to see it used _twice_ :D
Asking the obvious question: why not your own server in a colo?
The problem with actually owning hardware is that you need a lot of it, and need to be prepared to manage things like upgrading firmware. You need to keep on top of the advisories for your network card, the power unit, the enterprise management card, etc. etc. If something goes wrong someone might need to drive in and plug in a keyboard.
Eventually we admitted to ourselves we didn't want those problems.
At one point in the early 2000's, my brother was soldering new capacitors onto dell raid cards. (I like to call that full-stack ops.)
Then, say if the motherboard gives up, you have to do quite a bit of work to get it replaced, you might be down for hours or maybe days.
For a single server I don't think it makes sense. For 8 servers, maybe. Depends on the opportunity cost.
Most expense is initial setup and automation, but once you get thru that hump and have non-spiky loads it can be massively cheaper
Have you seen what the LLM crowd have done to server prices ?
But it's indeed cheaper with high, sustained workloads.
What was the config on the receiving side to support this? Did you whitelist the old server IP to trust the forwarding headers? Otherwise you’d get the old server IP in your app logs. Not a huge deal for an hour but if something went wrong it can get confusing.
This isn't something others should use as an example.
My foray into multiplayer games.
Namely, all remote access (including serving http) must managed by a major player big enough to be part of private disclosure (e.g. Project Glasswing).
That doesn't mean we have to use AWS et al for everything, but some sort of zero trust solution actively maintained by one of them seems like the right path. For example, I've started running on Hetzner with Cloudflare Tunnels.
Anyone else doing something similar?
How much latency does this add?
- reduce dns ttl (if not doing an ip swap)
- rsync website files
- rsync /etc/letsencrypt/ ssl certificates
- copy over database (if writes don't happen often and database is small enough, this can be done without replica, just go read_only during migration)
- test new server by putting new ip in local /etc/hosts
- turn off cron on old server
- convert old server nginx to reverse proxy to new server
- change dns (or ip swap between old and new server)
- turn on cron on new server
you can basically go on hetzner and spin up a vps with linux that is exposed to the open internet with open ports and user security and within a few hours its been hacked, there is no like warning pop up that says "if you do this your server will be pwnd"
i especialy wonder with all the ai provisioned vps and postgres dbs what will happen here
So a near 44% price reduction for a 50% reduction in only one of the components. Looks like progression to me.
For OP though who is a Turkey-based company and want European region servers anyway, it might make sense.
I think Hetzner makes most sense (for myself, and OP seemingly too) because they have dedicated servers, and they're in Europe. Extra bonus is the unmetered connection, but primarily just good and cheap servers :)
This reasoning does not add up. They could simply say they needed to move somewhere cheaper, like Hetzner. Inflation is still high but getting lower. Weakened Turkish Lira part is not correct because dollar is artificially suppressed for a very long time.
I've spent time eating the costs of things like DigitalOcean or SaaS products because my time is better spent growing my revenue than reducing infrastructure costs. But at some point, costs can grow large enough that's it's worthwhile to shift focus to reducing infrastructure spend.
None of it is mission critical - but it’s certainly something I’d use in production with a few more instances.
Networking over Tailscale works flawlessly with my Proxmox nodes at home.
No matter what I try, they refuse which is frustrating. Even setting up a new company is not a realistic solution as the verification still requires passport.
If anybody knows an alternative, kindly leave a suggestion.
Hetzner cannot outsell your CPU or SSD
VMs on cloud can.
On dedicated server they can't but we're talking about VPS (cloud plan)
Full of scanners, script kiddies and maybe worse.
And i say it every time they came up: Their cloud UX is brilliant and simple! Compared to the big ones out there.
> 30 MySQL databases (248 GB of data)
> 34 Nginx virtual hosts across multiple domains
> GitLab EE (42 GB backup)
> Neo4J Graph DB (30 GB graph database)
> Supervisor managing dozens of background workers
> Gearman job queue
> Several live mobile apps serving hundreds of thousands of users
I'm not against vertical scaling and stuff, but 30 db instances in one server is just crazy.
They didn't say that and the article didn't allude to that. 1 instance with 30 databases.
With decades of well engineered open source software and some help from AI virtually anyone can run their own bespoke stack on bare metal servers. You need to know a think or two but it is possible.
If you want to go crazy you can also deploy your own agent inside the machines to maintain them.
If some people can chime in with their positive experiences I might switch.
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.
Cloud is ludicrously marked up.
So they did same mistake all over again. Debian or Ubuntu would just be upgrade-in-place and migrate
Plus, this is not what DHH was doing, he was not saving few bucks, but unlocking potential for his company to thrive.
When I’ve seen this work well, it’s either built into the product as an established feature, or it’s a devops procedure that has a runbook and is done weekly.
Doing it with low level commands and without a lot of experience is pretty likely to have issues. And that’s what happened here.
Over the years I've heard plenty of horror stories from Hetzner customers.
Not everyone likes wasting money.