Hook: Can your hosting be deleted by one line of code?
An engineering team budgeted $8,000 for January 2026 and got billed $47,000. Nothing crashed. No alert fired. The auto-scaling group, the CloudWatch alarms and the textbook AWS reference architecture had all worked exactly as advertised — which, on a workload that didn't actually need any of them, is how you spend six times your plan in 30 days.
"A team set up auto-scaling for EC2 instances with CloudWatch alarms and scaling policies, expecting to handle traffic spikes automatically and scale down when not needed, yet this resulted in a $47,000 bill in January 2026." — Devrim Ozcay, awstip.com, Jan 2026
Same week, on the Cloudways feedback portal, a request titled "Add Docker support" rolled past its fifth birthday with no progress. Cloudways still doesn't allow Docker, still doesn't grant root, and according to their own help center this isn't an oversight — it's deliberate.
Pull these two stories together and you get the question every "best hosting for DevOps" listicle in the SERP avoids: which platform on your shortlist can actually be deleted and rebuilt by code? Not "do they have an API." Not "do they have a Kubernetes button." The literal test — if I run terraform destroy at 2 AM, then run terraform apply from a fresh git clone, will my application be back, with state, in under 15 minutes, with no human in the loop?
That's the only definition of "DevOps-friendly" that survives contact with production. Every other definition is marketing.
I've used 45+ hosts since 2014 — small WordPress sites, agency builds, a couple of WooCommerce stores that punched above their weight, and over the last three years a bunch of side projects that I run on infrastructure I can rebuild from a laptop in a hotel room. What follows is a candidate filter, a real-cost table, and a verdict by use case. The Terraform Test cuts roughly half the SERP's recommendations on the first pass.
1. Three categories of impostor: who shouldn't be on your shortlist
The first job is taking out the trash. Most listicles for "best DevOps hosting" mix three product categories and pretend they're a continuum. They aren't.
Category 1: PaaS cosplaying as VPS (Cloudways)
Cloudways gets recommended in nearly every "DevOps hosting" article on page one of Google. Here is the entirety of what you need to know to disqualify it:
"Cloudways won't give you root access — and that's by design, not by accident. Their managed platform centrally orchestrates all servers, and root access would create configuration drift that breaks their automated management." — Cloudways Support Center, "Why can't I have root access to my server?"
No root means no Docker. No Docker means no portable application packaging. No portable packaging means your "infrastructure as code" stops at the SSH line and turns into a set of GUI clicks documented in a Notion page. The Cloudways DigitalOcean 4GB plan costs $46/mo. The same DigitalOcean 4GB droplet underneath it costs $24/mo. You are paying a 92% markup for a wrapper that prevents you from doing the things this article is about.
Cloudways is a fine product. It is not a DevOps product. It's a managed PaaS that happens to bill itself in VPS units.
Category 2: Visitor-cap-as-autoscale (WP Engine, Kinsta, Pressable)
The second category sells "auto-scaling" but ships visit caps with overage billing. WP Engine Startup is $30/mo and includes 25,000 visits. Kinsta's entry plan tiers similarly. Pressable Signature 1 is $20.83/mo for 30,000 visits. When traffic crosses the line, you don't auto-scale — you get an overage charge ($2 per 1,000 visits at WP Engine, $1 per 1,000 at Kinsta) or a forced upgrade to the next plan.
"[Kinsta users noted] caps on visits, storage, and certain resources can sometimes feel a bit restrictive, especially during periods of rapid growth or unexpected traffic spikes." — G2 Reviews, Kinsta
The honest name for this billing model is "metered with a soft ceiling." It's a reasonable model for a marketing site. It is not autoscaling. Putting it on a list next to DigitalOcean's Kubernetes service is a category error, not a comparison. There's also no Terraform provider for any of these in a meaningful sense — you can call their API, but you can't represent a WP Engine "install" as a first-class Terraform resource and apply drift detection on it.
Category 3: Honest PaaS sold as a category replacement (Railway, Render, Fly.io)
This third category is genuinely useful and I'll come back to it later in this piece. Railway, Render and Fly are real PaaS products: you push git, they build and deploy, you don't manage servers. They have decent CLIs and reasonable pricing for small workloads. The mistake is not Railway's — Railway is not pretending to be IaaS. The mistake is the listicle author's, who lumps Railway in with Hetzner and DigitalOcean as "DevOps hosting." If you actively want to abstract over the server, you don't pick a server provider. You pick a PaaS, knowingly. There's a section on this below.
So the shortlist that survives the Terraform Test contains primarily IaaS providers: places where you get a Linux box with root and a Terraform provider that knows about it.
2. The candidate pool: five IaaS providers, six measurable axes
Below is what I actually look at when I have to pick infrastructure for a project I plan to run for at least 12 months. AWS, GCP and Azure are out of this table on purpose — they pass the Terraform Test trivially, but their default-on services and IAM surface area produce most of the bill-shock stories I started this piece with. They deserve their own article.
| Provider | Official Terraform provider | Root SSH | Docker support | API rate limit | Parallel apply (default) | Drift detection |
|---|---|---|---|---|---|---|
| Hetzner Cloud | Yes (hetznercloud/hcloud) | Full root | Native (any container runtime) | 3,600 / hour per project | 10 (raise with -parallelism) | Solid for servers, networks, firewalls; volumes drift on attach state |
| DigitalOcean | Yes (digitalocean/digitalocean) | Full root | Native + Docker droplet image | 5,000 / hour | 10 | Strong for droplets, k8s, managed DB, load balancers; weakest on Spaces metadata |
| Vultr | Yes (vultr/vultr) | Full root | Native + Docker app image | 30 / sec, 4,500 / hour | 10 (apply gets throttled past ~25 concurrent creates) | Adequate for instances and block storage; reserved IPs occasionally drift |
| Linode (Akamai) | Yes (linode/linode) | Full root | Native + Marketplace | 1,600 / 15 min (~6,400 / hr) | 10 | Best-in-class for VPS + LKE managed K8s; account-level resources lag |
| Kamatera | Community provider only | Full root | Manual install | Not formally documented | Low — serial create works, parallel hits failures past ~5 | Limited; reconcile by destroying and re-creating |
Two of these are immediately strong DevOps candidates (Hetzner, DigitalOcean). One is a strong second-tier (Vultr). One is a strong candidate with a current asterisk you have to know about (Linode — below). One is honest about being old-school (Kamatera).
A note on Linode that doesn't appear in the table because it isn't a technical axis: account stability. Linode's automated fraud detection flags new signups aggressively. The Linode community has dozens of threads from 2024-2026 with the same shape: signed up, deposited a card, account suspended within hours, support takes 48-72 hours to manually review. Sample:
"Recently created accounts have been denied activation due to activity or patterns associated with fraudulent behavior." — Linode Community thread #22948
If you are an experienced Linode customer with a 5-year-old account, this is a non-issue. If you are signing up tonight to provision tomorrow morning, factor 2-3 days into your plan, or pick another provider. I lost a half-day on this in February with a brand-new project account, and that was with a residential IP, real card, real phone. The Akamai backend is now strict in a way the old Linode wasn't.
Hetzner has the inverse problem worth flagging, because the Frame of this article is "is your data safe enough to rebuild from": their account suspension policy is unforgiving on payment. There are multiple Trustpilot cases of accounts being locked over a single failed credit card charge, and at least one I've seen where two years of paid-up history did not stop a 48-hour deletion window from running. The other ongoing tax is IP reputation — Hetzner ranges show up on enough abuse lists that outbound transactional email gets flagged by default, and a fresh CPX21 will get rate-limited by some downstream APIs until the IP ages in. The verdict on Hetzner isn't "don't use it." It's "use it knowing the account model is brittle and the IP space carries baggage." What you do about that belongs in the FAQ, not in this paragraph.
3. The real monthly bill: 12-month TCO at 4GB
Headline prices lie. Here's what a single 4GB / 2 vCPU workload — the size where most agency client sites and side projects actually live — costs over 12 months once you add the things people forget. Every base price below was sourced from each provider's own pricing page, current as of April 27, 2026.
| Stack | Base / mo | Year 1 realistic | What pushes it up |
|---|---|---|---|
| Hetzner CPX21 (3 vCPU AMD, 4GB, 80GB NVMe, 20TB EU traffic) | ~$10.20 (€9.49) | ~$122/yr | Backups +20% if enabled. US bandwidth tier is much smaller than EU since the April 2026 update. |
| DigitalOcean Basic 4GB (2 vCPU, 80GB, 4TB) | $24.00 | ~$288/yr base; add backups (~20% surcharge) and a reserved IP held idle | Snapshots are billed per GB, reserved IPs accrue idle fees, transfer overage is on a per-GB tariff |
| Vultr Cloud Compute 4GB (2 vCPU, 80GB NVMe, 3TB) | $24.00 | ~$288/yr | Reserved IP idle fees, backups (~20% surcharge), optional DDoS protection add-on |
| Linode Shared 4GB (2 vCPU, 80GB, 4TB) | $24.00 | ~$288/yr | 2024 Akamai 20% flat raise already absorbed in this number; IPv4 fees layer on top |
| Cloudways DO 4GB (2 vCPU, 80GB, 4TB) | $46.00 | ~$552/yr | Optional email add-on, bandwidth overage on a per-GB tariff. The base is already a 92% markup over the underlying DO instance. |
| WP Engine Startup (1 site, 25K visits, 10GB) | $30.00 (annual) | ~$350/yr if you stay under 25K; $50-150 more if a single Reddit hit pushes you to 30-50K | Visit overage at $2 per 1,000 over plan; storage overage; staging bandwidth |
| Pressable Signature 1 (1 install, 30K visits, 20GB) | $20.83 (annual) | ~$250/yr in cap; like WP Engine, you bleed if you exceed | Visit overage; bandwidth overage; same cap-or-scale model |
The headline cost difference here is roughly 4.5x between Hetzner and Cloudways for the same compute primitives. The cost difference between Hetzner and DigitalOcean is 2.4x, but the Terraform provider quality and account stability for DigitalOcean is enough that for an agency running multi-region production work, I default to DO, not Hetzner. For a side project or personal stack where I'm willing to wear Hetzner's harder-edged account policies in exchange for the price, Hetzner wins.
Two more things that matter at the bill level and don't fit the headline:
- IPv4 is now metered everywhere. Linode now charges for IPv4 separately, AWS started in early 2024, and Hetzner's pricing already separates IPv4 from the base instance. Budget for it as a small per-IP monthly line item that scales with how many static IPs you keep alive.
- Bandwidth overage is usually invisible until it isn't. A WordPress media library plus an unexpected Reddit referral can run a 4TB transfer cap in a weekend. Hetzner caps US bandwidth at a much smaller envelope than EU since 2024 — check the regional details before assuming "20 TB" applies to your data center.
4. The hardware-generation problem (why a $5 host can be 23x slower)
Nothing on a pricing page tells you the box you're renting was last refreshed in 2016. The cheapest VPS on a given provider can be sitting on SATA SSDs and an Ivy Bridge Xeon while the same provider's top tier runs NVMe and Ryzen. The numbers are not subtle:
| Plan | Drive | 4K random read IOPS |
|---|---|---|
| InterServer "price-locked" VPS | SATA SSD | 1,576 |
| Hetzner CPX22 | NVMe | 35,830 |
That's a 22.7x IOPS gap on the disk that holds your Postgres data files and your application binaries. The community has been telling this story for years — here's one thread that captures the loop perfectly:
"InterServer VPS ran slow at 4 slices and was instructed to add more slices, eventually getting to 7, but the server would still fall over to a BSOD or reboot randomly — and each time they asked for help, they were told to purchase more RAM." — WebHostingTalk + Trustpilot, summarized in our hosting-003 source card
RAM does not fix disk-bound workloads. The user is being upsold against the wrong axis. This isn't unique to InterServer — it's the failure mode of any provider whose oldest hardware generation is still on the menu at the cheapest price point. When you're shortlisting, look up YABS results on vpsbenchmarks.com or run YABS yourself on a $5 trial box. If the 4K random read sits below 5,000 IOPS, you're on a hardware generation that won't carry your workload regardless of how many vCPUs you stack on it.
This is also why the Akamai-Linode story matters beyond pricing: when an acquirer flat-raises 20% and the underlying hardware refresh cadence slows, you get a quietly worse deal even with the same plan name on your invoice.
5. Pivot: when PaaS is actually the honest answer
I've spent four sections telling you to pick IaaS. Here's where I have to walk it back, because the Terraform Test is a useful filter, not a religion.
If you are a one-person side project, or a team of two or three with no on-call, the cost of running infrastructure is not the AWS bill. It's the hours you spend at 11 PM debugging why your Nginx config didn't reload after a certbot renew. Coolify, Railway, Render and Fly all exist because that math doesn't work for everyone.
Coolify on a $10/mo Hetzner box is the option I keep coming back to for projects where I want the IaaS bill but the PaaS workflow. You self-host Coolify on a single VPS, point it at your git repo, and you get push-to-deploy with zero-downtime swaps and a managed Postgres add-on. Total monthly cost: roughly $10-15. The catch is that Coolify is the thing that keeps your apps running — if Coolify breaks, you debug it. There's no support contract.
Railway / Render make sense when your team's collective opportunity cost on infrastructure is more than $50-100/mo and you'd rather pay for someone else to be on call for the build pipeline. The price you pay starts at roughly 2-3x what the same compute would cost on Hetzner or DO, and it climbs steeply at scale. The break-even, in my experience, sits around $200-300/mo of usage. Below that, Railway is cheaper than your time. Above it, you've been paying to delay the inevitable: at $400-500/mo of Railway spend, the same workload on a managed Postgres + Hetzner Cloud setup would be roughly $80-150 with comparable uptime, and you have a Terraform state file you can hand to the next engineer.
The honest version of "DevOps hosting" includes admitting the right answer for some readers is "stop self-hosting and pay a PaaS until the bill outgrows your time." If your team's working time is worth more than your infrastructure savings, the IaaS purity test is a trap.
6. Auto-scaling: the part most DevOps engineers get wrong
Back to the $47K AWS bill. The follow-up writeup on dev.to is the part the original story doesn't always carry, and it's the actually useful number:
"When one team disabled auto-scaling and load tested properly, they discovered they didn't actually need auto-scaling at all — their traffic patterns were predictable and could be handled with 6 properly-sized instances running 24/7 for $829/month." — arbythecoder, dev.to
$829/mo of static instances vs. $47,000/mo of "elastic" infrastructure to handle the same load. That's a 56x difference, and it's not because AWS is more expensive than Hetzner per unit — it's because the team configured a system that scaled aggressively up and lazily down, then handed it a workload that didn't need to scale at all.
I want to dwell on that gap for a second, because the 56x is the headline but the experience is the lesson. The team that ended up on the static-instance plan slept the weekend they cut over. The team they used to be had been on Slack at 2 AM watching the autoscaling group spawn faster than they could type "kill the alarms," refreshing the billing dashboard and trying to do the cost math in their head while everything was still on fire. The interesting part of "we didn't need autoscaling" isn't that it was cheaper. It's that you stop being the person who has to be on call for your own architecture's coping mechanism.
The decision rule I use, and which I wish I'd had four years ago:
- Look at one week of real production traffic, not at a guess. CloudWatch will give you 1-minute resolution for two weeks; Datadog longer.
- If peak/baseline ratio is under 3x, do not autoscale. Run static capacity sized for peak with maybe a 20-30% headroom.
- If peak/baseline is over 5x and the peak lasts under 30 minutes (Black Friday windows, new product launches), autoscaling is correct, but you want a hard budget cap, a cooldown of at least 5 minutes, and a warm pool to skip the 2-5 minute EC2 cold-start.
- Between 3x and 5x, autoscale only if you're seeing real overprovisioning waste at baseline. Often the answer is still "no — just buy reserved instances at the peak size."
The other piece nobody tells you: auto-scaling on the compute layer doesn't help if your bottleneck is the database. Most failure stories in the major retail Black Friday postmortems — and there are 40+ public ones from 2018-2024 — trace back to connection pool exhaustion, third-party API limits, or inventory locks. CPU is not the constrained resource. Stamping out 30 EC2 instances because CPU usage hit 70% just gives you 30 instances all blocked on the same Postgres connection pool.
The order of operations for a DevOps engineer hitting capacity walls should be: managed Postgres or MySQL with pgBouncer, then a CDN with origin shielding, then read replicas, then — only then — compute autoscaling. DigitalOcean Managed Databases and Linode Managed Databases both do this competently at low-double-digit monthly entry tiers. Skipping straight to ASG is the move that produces $47K invoices.
7. Verdict by use case
Verdict: side project / solo founder, under $50/mo budget
Pick Hetzner CPX21 (~$10.20/mo) plus Coolify self-hosted. Total monthly cost lands around $10-15. You get root, Docker, push-to-deploy, and an entire stack you can rebuild from a fresh git clone in under 20 minutes. Accept the trade: Hetzner's account policies are strict, and Coolify is your responsibility if it breaks. Keep your Terraform state and Postgres backups in something that isn't your Hetzner account.
Verdict: agency, 5-50 client projects, multi-region
Default to DigitalOcean Droplets + DO Managed Databases. The Terraform provider is the most polished of the IaaS pool, the documentation is honest about edge cases, and the pricing is predictable. Year-one cost for a typical 4GB workload is ~$288 for the droplet plus an entry-tier managed Postgres on top. Use Vultr for any region DO doesn't cover well. Skip Linode for new accounts until the Akamai signup-fraud detection settles down.
Verdict: team of 3-10, no full-time SRE, want push-to-deploy
Pay Render or Railway and stop pretending you're running infrastructure. The break-even in my experience is roughly $200/mo of usage. Below that, time saved > money spent. Above it, plan an exit toward Hetzner or DO + Coolify within 6-12 months — track the Render bill monthly, and when it crosses $400, build the migration.
Verdict: vendor-neutral / EU compliance / can't be on US-controlled clouds
OVH or Hetzner Cloud, both EU-headquartered. Both have Terraform providers. OVH's enterprise SLA is more usable for compliance documentation; Hetzner is cheaper. Neither is HIPAA-eligible, and that's a hard constraint we're not solving in this article.
Don't recommend
- Cloudways for any DevOps workflow. The 92% markup is the small problem. The no-Docker, no-root, GUI-only management plane is the disqualifier. There's no path from a Cloudways stack to an IaC-managed stack that doesn't require leaving Cloudways.
- WP Engine, Kinsta, Pressable for anything described as "scaling." They're cap-and-overage, not elastic. Pick them for a marketing site you don't want to think about, not for a DevOps practice.
- AWS for a team under 5 people running a single application. The IAM surface, the default-on services, and the failure mode of Reserved Instance / Savings Plan financial commitments versus actual usage all conspire to produce the $47K-instead-of-$8K outcome. AWS pays back at scale, in regulated industries, and where the team has dedicated cloud financial management. It punishes solo founders.
- Linode for accounts created today, with a soft asterisk — the platform itself is fine, the signup gate is currently broken in a way that costs you 2-3 days you can't predict.
Where this guide doesn't apply. If you're already 18+ months deep in AWS with 50+ Lambdas and a Step Functions graph that owns half your business logic, the migration math here probably loses to staying put — that's a different article. If you're under HIPAA, PCI Level 1 or FedRAMP, none of the IaaS providers in Table 1 are inside your compliance envelope; you need GovCloud, Azure Government, or a specialty compliant host, not Hetzner. And if your "DevOps hosting" search was actually about a marketing blog or a portfolio site, the Terraform Test is over-engineering for you — pick the cheapest managed WP host that doesn't anger you and move on with your life.
8. FAQ
Can I run Docker on Cloudways, or do I really need to leave?
You can sudo apt install docker-ce on a Cloudways server and run containers manually. The moment you do, you've broken Cloudways' managed plane, support will stop guaranteeing performance and recovery, and your next platform update can wipe your changes. Cloudways' own feedback portal has had a "native Docker support" request open since 2019. Five years is the company telling you the answer is no. If you need Docker, leave. The migration is two days of work for a typical WordPress + WooCommerce stack: mysqldump, wp db export, file rsync, point Coolify at the git repo, update DNS.
Is Hetzner's recent US bandwidth cut a deal-breaker for DevOps work?
Depends on what you serve. Hetzner cut US-region included bandwidth from 20TB/mo to a much smaller tier (1-8TB depending on plan) in the April 2026 update, alongside a 25-40% price hike on certain Cloud lines. For an API service, an admin app, a B2B SaaS — you'll never see the cap. For anything that ships images, video, or large file downloads to US users, you will. If your egress is over 1TB/mo and your audience is mostly US, either pick the EU region (still 20TB included) and accept the latency, put Cloudflare in front of it, or use DigitalOcean US instead. The Hetzner price advantage doesn't survive a $0.01/GB transfer overage.
Should I use Coolify on a $10 Hetzner box or just pay for Railway?
Below Railway $50/mo, Railway saves you maintenance time you wouldn't have spent productively on infrastructure anyway. Once you cross $200/mo on Railway, you're paying a 4-5x premium over the equivalent self-hosted Coolify stack on a $20-30 Hetzner box — that's the exit threshold. The non-cost factors: Railway has multi-region failover and a real CDN out of the box; Coolify gives you neither, and that's worth roughly $50-100/mo of Railway pricing on its own. My rule: if your project will outlive 18 months, do Coolify; if you're not sure it'll survive the year, Railway.
Why did my Linode account get auto-suspended on signup?
Linode (now Akamai) runs an automated fraud-detection model that flags new signups aggressively. The community has 9+ threads in 2024-2026 with the same pattern: signed up, paid, suspended within hours. The workaround that has the highest success rate, distilled from those threads: use a real residential IP (no VPN, no datacenter IP), a US/EU phone number that actually receives SMS, a real credit card (not a virtual card, not a privacy.com number), wait the 24-48 hours support takes to manually review, and don't try to immediately spin up 10 instances via Terraform — that triggers the secondary fraud heuristic. If you need infrastructure provisioned tomorrow morning, pick DigitalOcean. The Akamai signup gate is real, and it doesn't care that you've been a Linode customer since 2014 on a different account.
Do I need managed Kubernetes (EKS / GKE / LKE) or just plain Docker?
Plain Docker on a single VPS handles 90% of side-project and small-team workloads. Reach for managed Kubernetes only when one of two specific things is true: (a) you have 3+ engineers who all need to deploy independently to the same infrastructure without stepping on each other's toes, or (b) you have multi-tenant workloads that genuinely need pod-level isolation Compose can't enforce. If neither applies, you don't need K8s — you need to put your docker-compose.yml in git, version it, and stop thinking about it.
The pricing shape: DigitalOcean Kubernetes (DOKS) and Linode Kubernetes (LKE) bill the same per-node price as a regular VPS, plus a control plane fee. DOKS' single-node control plane is free; LKE charges separately for an HA control plane. AWS EKS and GCP GKE both charge a flat hourly fee for the control plane on top of node costs.
The honest failure-mode signal — and the one I wish I'd had four years ago: at month three, count cluster incidents that traced back to YAML, RBAC or operator misconfig versus actual application bugs. If the cluster is producing more incident hours than it saves, you bought the wrong tool. The unsexy answer to "should we K8s this?" is almost always no. A single 8GB box running Docker Compose under Coolify outlives most "we should K8s this" plans, including the ones written by teams who genuinely needed it — they were just six months too early. Wait until deployment friction is a measurable bottleneck, not a hypothetical one.
How do I migrate from Cloudways without rewriting everything?
For a typical PHP/WordPress stack: (1) wp db export on the source to dump the database. (2) rsync or tar the wp-content directory off the Cloudways server — you have SFTP, even though you don't have root. (3) Provision a Hetzner CPX21 or DO 4GB Droplet, install Coolify, point it at a fresh git repo containing your custom theme and plugins. (4) Restore the DB on a managed Postgres or a Coolify-managed MariaDB instance, change siteurl if you're flipping domains, and update DNS. The last single-site migration I ran was about three hours of actual work, plus a 24-hour DNS TTL window. The thing that takes longest isn't the migration — it's auditing the Cloudways-specific stuff (Breeze cache plugin, their Cloudflare add-on, their server-level config) and replacing each with a documented equivalent.
What "best DevOps hosting" actually means in 2026
I started this with the team that ran $47,000 of EC2 in a month and the Cloudways feature request that's been open longer than some people's careers. They're the same story told from opposite ends. One team paid 56 times the static-instance cost to feel elastic; the other paid a 92% markup to feel managed. Both got billed for the absence of a single test: can this stack be rebuilt by code, alone, at 2 AM, without me?
The hosting market in 2026 is split cleanly along that line, even if the SERP refuses to see it. On one side: Hetzner, DigitalOcean, Vultr, Linode, OVH — places where root, Terraform, and an honest API let you treat infrastructure as code. On the other side: Cloudways, WP Engine, Kinsta, Pressable, Railway, Render — places where the platform itself is doing the work the dashboard implies, and you pay for the abstraction whether you wanted it or not. Both sides are useful. Neither is "DevOps hosting" by default. The category depends on the workflow you're trying to keep alive.
If you take one thing from this: stop reading hosting reviews that grade providers on "developer experience" and start asking what each one will let you do with terraform destroy. The good ones will let you delete everything and rebuild it in fifteen minutes. The rest will send you an email asking if you'd like to talk to your account manager.
One caveat I haven't earned the right to skip: this whole frame breaks down if your team's value comes from features the platform abstraction provides — built-in CDN, automated SSL, image transforms, push-to-deploy — and your engineers' time is genuinely more valuable than any infrastructure cost you'd save. If you'd rather your stack be invisible than replaceable, "best DevOps hosting" for your team was always Vercel or Render, and the Terraform Test is the wrong filter to apply. This article is for people whose answer to "what do you do when the platform is down at 2 AM" is "I rebuild it." If your answer is "I file a ticket and go to bed," ignore me.