Every service, ranked by real customers

Has used DigitalOcean for years, finds it very reliable and has never needed to contact support because it has always just worked.

Stopped using Railway after security incidents and because prices skyrocketed once there was some traffic; now on cheaper Hetzner servers.

They could not open a support ticket during the outage even as owner and creator of the subscription, getting through automated support agents only to be told to ask their provider to open it.

Liked not thinking about infrastructure on Railway, but recent downtime is a blocker and they are looking at self-hosting.

They had about an hour of trouble with their SQL elastic pool in West Europe where the server was reachable but no tables were accessible.

They saw not only SQL problems but also disconnected virtual machines during the West Europe incident, all of which came back later.

Their AKS VMs were live migrated several times a week, which exposed a Redis client config issue causing latency and pod restarts. After tuning pings and keep-alives they have had no VM freeze in months.

They ran a cluster of 40 then 120 nodes on Azure and hit network backplane flooding, fixed by bigger VMs and then API refactoring. They say Azure documents these best practices poorly.

They found the Azure health history still showed no event for their subscriptions during the West Europe incident and felt the status and health reporting is lacking.

They chose Railway for its managed setup and infrastructure visualizer at a price close to a VPS, and say it is far cheaper than AWS for them, despite its reliability issues.

They saw no problem during the West Europe outage because their Azure SQL server is only privately accessible, which they suspect explains why others were hit.

They had to restart a stuck elastic pool with eight databases during the incident, with SSMS not showing logins and a job looping on authentication.

Their VMs sat on full servers with no capacity, so every small hiccup shuffled the whole rack slowly, and they eventually moved region.

Their Windows VMs crashed right after provisioning with disk hardware errors and a month of work with support, including kernel dumps, got no result. They switched from spot to on-demand VMs at higher cost.

They hit an Azure SQL outage in West Europe where connections failed intermittently and tables could not be listed in SSMS on the primary of their failover group, while the read-only failover copy looked fine.

They could connect to their server but not browse the databases in their Azure SQL elastic pool, and restarting the pool failed with an internal server error while service health showed nothing.

They lost metrics and databases during the West Europe elastic pool outage, a restore failed, and support gave no response for two hours beyond generic automated replies.

For a month their AKS Linux VMs froze together with connectivity issues and support was not useful. Switching from Dasv6 to Dsv7 stopped the freezes but costs more.

They report essentially zero downtime in the 5 years their team has used Render.

AI API key stolen via Railway; an Anthropic alert, not Railway, revealed it, and a spend cap limited the loss.

They lost invoice access entirely, and after weeks support told them to create another subscription for billing. First-line support just follows a script until a senior engineer gets involved.

As a student they used the $300 trial to host a Minecraft server on virtual machines and ended up with a $157 charge. Their billing account is closed and support redirects them to an automated assistant.

Railway is insanely fast to deploy with a nice UI, but security and reliability let them down; switching permanently.

With about a decade in cloud, they ran two startups on GCP and never had a billing or alerting issue.

After an earlier outage they moved their services from Railway to AWS. After the latest incident they cancelled their subscription, saying even the support page would not load.

Their team spent a full day rotating secrets after the Railway incident and lost count of the complaints in their chat.

Beta site on Railway: Gemini key abused for about $2k in two hours, no notice from Railway, deleted all accounts.

Started on Railway because it was easy and cheap, but two years of outages and the breach handling are pushing them off.

On a 7-day Railway trial, could not deploy on day 3 and is not happy.

Moved everything to Cloudflare; Railway's infrastructure stability was not consistent.

API credits drained despite usage limits after the Railway breach, and they could not redeploy for 30+ hours.

Revoked an OpenAI key before it was used, but says Railway has had too many issues and will use a better-known host for sensitive apps.

They had downtime during the Railway incident while they redeployed their app on DigitalOcean, and do not plan to return.

They moved their Rails apps to DigitalOcean Kubernetes a few years ago using the Cuber gem and say it works perfectly.

They use Heroku for all their client work and say elsewhere they have had no issues in about 10 years.

After the Railway incident, migrating to Fly.io was far easier than expected, about 30 minutes.

They describe a Railway outage running toward 48 hours with their availability dropping from 99% to about 95%.

Their app got a big traffic boost from a podcast shoutout, but new users could not sign up and they could not deploy a fix because Railway deployments were down.

They say Railway's status page claimed slow builds while deployments were not working at all, even on the pro plan.

Railway asked them to change exposed variables but they could not deploy a new build, leaving their service inoperable.

Cybersecurity worker says Railway was unreliable for six months before the env-var breach and is moving off.

Solo founder's OpenAI and Anthropic keys were compromised; rotated them but could not deploy because Railway paused deployments.

Anthropic disabled a Railway-linked key after unauthorized use; Railway never notified them.

Outages are common on Railway and the breach handling gave no proper notifications or dashboard warning.

Spent hours rotating keys after the Railway breach only to find the new ones leaked again; fixes would not deploy.

Liked Railway but the env-var breach spooked them into moving small projects to EC2.

Production database down for hours with no way to restore or redeploy on a Hobby plan.

Third time burned by Railway; migrated their business to DigitalOcean.

Many issues lately; says Railway is not worth the $200/month they pay and is moving.

OpenAI key leaked through the Railway incident and was burned; a spend cap limited the loss.

OpenRouter disabled leaked keys; Railway never said which projects or keys were affected.

Their Anthropic key was used by an unknown party after the Railway breach and deployments stayed down for 10-14 hours.

A 7k increase in OpenAI costs from a key leaked via Railway.

They say Railway has had major issues for over a year and two incidents in two days left them unable to update projects. Even support was down, and they are asking for an alternative.

They needed to ship an important product and Railway had been unable to deploy for 12 hours.

They could not deploy a critical update to their PHP services during the Railway outage and had to take the services down.

As a paying customer running client applications, they could not access projects or deploy during the outage. They give Railway 24 hours before cancelling their subscription.

They moved projects off Railway after the underlying GCP provider cut it off for about a day. They also saw services locking up and needed repeated restarts.

Railway deployments began failing just before they pushed their new Android app announcement to production, and had been down since.

They have thousands of users and could not deploy during the Railway outage, so they are asking for alternatives.

They have the opposite experience of the complaints: they are amazed by Railway's performance and by the features they get for the cost.

They deliberately run on Google-operated regions in Belgium and the Netherlands rather than the London colo region. They were unaffected by the europe-west2 outage and hope it leads to improvements.

They have used Azure since 2010 but are migrating to AWS after a year in which they say support went from present to non-existent.

Free-tier Flask apps deployed on Render were suspended, forcing a search for alternatives.

They once had a support ticket open for a year; the issue was known but support said they lacked access to fix it.

They see capacity shortages across many GCP machine families and regions, even on the alternative GCP suggested, which threatens production scaling.

Despite paying for a support subscription, their Azure ticket was answered by an AI that kept asking and suggesting.

Hosts a site on Fly.io with no problems and perfect 100 scores across the board on page insights.

They report almost all GCP machine types (C3, C4, C4A, N4A, N2, N4) currently unavailable and call it a disaster.

Paid account suddenly said the trial ended, nothing worked, and support was useless.

Clusters on DO, Linode, AWS and Hetzner over a decade: DigitalOcean never had an incident in years.

Tried AWS Lightsail once and never liked it because of poor performance.

Found AWS-native snapshot consistency tricky for SQL Server on EC2 if not set up right, and had a restore fail once.

Left DigitalOcean because the control panel interface lags terribly.

They tried for five days to migrate to Cloud SQL Enterprise Plus, which worked in every region except us-central1.

They run their C# app as a docker image with docker-compose on a DigitalOcean droplet, fronted by nginx and letsencrypt.

They spent a month failing to get a Kubernetes networking setup working on AWS EKS, then had it working the same day on GKE, which uses eBPF.

Their new GCP free-tier project was suspended within seconds of enabling Gmail APIs. The appeal got a nonsense reply and no further answer, so they filed to delete the whole org.

Their startup project on Google Cloud was hit by an exploited old service account that spammed Model Garden APIs for 20+ hours, producing a charge of about 600k they cannot pay.

At their company, moving terabytes of Cloud Storage data from Standard to Archive tier triggered Class A operation charges of about $170k. They say Google would hold the customer responsible, so no refund was possible.

They run many training workloads on GKE with H100 GPUs and say it has been great so far, and they like the project structure. They found Azure VMSS painful and slow when scaling about 1000 L4 GPUs.

They have been on GCP for 7 years and criticise Google for not implementing network ACLs and for pushing everything into Private Service Connect. They say VPC Service Controls only covers googleapis.

They call Google Cloud enterprise support a joke and add from their own experience that most of their issues are known bugs with no ETA for a fix.

Runs production apps with around 500 users each on shared CPU droplets and recommends premium AMD.

Not a single five-minute downtime in over four years.

Shared CPU droplets for internal apps and testing without problems for years.

Shared droplets caused occasional Minecraft lag spikes, but work fine for production cron scripts and they are very happy overall.

Tested shared premium AMD droplets and is moving all servers since no performance impact is noticeable.

They would trust Azure with production only if UI, support and reliability matched AWS, and their one Azure use case has constant issues.

Moved to DigitalOcean because droplets are cheap and the support is still really good.

After 10 years DigitalOcean capped domains at 20 per account and only raised their 132 to 50, so they are leaving.

Runs self-managed database nodes on EC2 for network control and NVMe drives, plus a fleet for ECS task placement.

Free Oracle VPS works for IPv4 termination with WireGuard behind CGNAT.

Moved from AWS and GCP to DigitalOcean for the simple UI, but a redesign has cluttered the dashboard.

They report about 2600 dollars in unexpected Azure charges and cannot find how to open a billing or support ticket, only seeing a refund option that loops back.

They stopped using Google Cloud because usage billing controls are obscure and only notifications can be set, with no hard limit.

Their Azure account was hacked and used to create unnecessary virtual machines and storage accounts. After Azure investigated, the invoice was reverted.

They had a billing case in which the Azure billing team forgave a 15 dollar debt.

A billing account and project they never created were generated in Google Cloud and they were charged $70. Support could only give a simple refund and could not fix the root cause.

Railway's only downside for them is occasional downtime and outages.

Railway has had flaky uptime in recent months though the developer experience is nice.

Runs a Node and Postgres production setup on Railway that has been solid for background jobs and cron.

Left Render for Cloudflare Workers because of cold starts.

Railway handles Node and Postgres with zero configuration headache and its built-in cron jobs work flawlessly.

Using Railway on a project for a while with no complaints; simple setup and pay for what you use.

Render is super easy but webhooks only come with the $20/mo plan, so they moved to a cheaper Hetzner VPS.

Runs a Node and Postgres stack with about a hundred users on Railway; it has been solid for months.

Railway is cheap and easy but a couple of major outages took hours to resolve; moving off to AWS.

They find unoptimized Azure cost slightly higher than AWS but for them it ends up cheaper thanks to lower transaction and bandwidth costs.

They are moving a legacy single-subscription environment to landing zones and support only raised their subscription limit from 5 to 10 while repeatedly demanding business justification. They remained blocked for weeks.

A min-instances=1 setting sat unnoticed in their Cloud Run config for months and quietly cost $206 in idle warm containers. They only caught it because config changes now land in a reviewed diff.

They have used Google for 8+ years but hit capacity problems, including an 8 hour period without one instance, and are now talking to AWS and OCI.

They are struggling to provision AlloyDB and Valkey clusters on GCP because of capacity limits.

They keep hitting stock out errors on regular CPU instances across node sizes and regions, and must search all regions for on-demand compute.

They have C4 capacity problems on GCP and may have to move production GKE workloads to another region.

They found suspicious sign-ins and a very large Azure bill, stopped all components and contacted Microsoft.

On a non-PAYG free account gets only about 50Mbps each way, the standard cap for free accounts.

Their service account keys lived only in GitHub Actions secrets, yet the same compromise happened to them, and they could not reach support.

Added free Oracle nodes to a home Nomad cluster over WireGuard for extra compute at no cost.

In France, repeatedly gets out-of-capacity errors trying to create the free 24GB A1 server.

On a PAYG A1 instance in Stockholm measured about 1.9 Gbps down and 2 Gbps up, so no 50 Mbps cap.

DigitalOcean permanently deleted their infrastructure after a billing issue and refused any refund or explanation after escalation.

A commitment applied on a FinOps recommendation led to a roughly $12,100 charge, and support first promised a full refund in writing then reversed to 50 percent after repeated agent handoffs.

Took about two months of scripted attempts to get an Ampere A1 without a PAYG account.

They pay for the most expensive enterprise support and say it is still hit or miss, with calls declined or rerouted for months, worse than basic AWS support.

They ship faster on Cloud Run and avoid the works-in-dev-not-in-prod issues they had with Lambdas.

Forgot an experimental EC2 instance for two weeks and was billed about $1,700.

DigitalOcean has worked great for over a month with no issues or ID verification.

Their multi-region setup (SQL primary/secondary, app services with Traffic Manager, Kubernetes in both regions) failed over automatically during the West US outage with little impact.