Bloated clouds, anyone?

Clouds had to serve everyone, so they got bloated and gave up on the developer experience that made them worth having. A rant, and what I did about it.

Conventional cloud platforms had to serve everyone, and they became bloated with features. Chasing the next big thing, they abandoned any attempt at improving developer experience, which is the reason clouds blew up in the first place. Big tech companies have the money to pay for DevOps. The rest of us have to choose between wasting developer time on it or delegating it to an AI agent that can't be held responsible when it all comes crashing down.

You can rent a plain VM, but

• regular deployments have to arrive via SSH or some elaborate CI setup,
• you'll be paying for more compute than you actually use,
• and when your service becomes popular enough to use its entire CPU/RAM allowance, you have to scale it up manually.

You can go serverless and it will scale up and down automatically, but

• servers with stateful functionality will underperform — Next.js has server-side caching, and it doesn't work when you run it as a scale-to-zero container,
• Firebase Cloud Functions are public by default and weird to set up: they have their own CLI just to package and deploy them, and only JS and Python are allowed,
• a few providers let you create a cloud function right in the cloud console. That's terrible, because it's a piece of code that lives in a weird online editor and isn't type-checked against your latest code changes. You will forget to update it sooner or later, and it will crash with a bug.

So you want scalability, CI deploys that make sense, and the code in a repo you control

Welcome to Kubernetes and the 4,000 lines of YAML config that come with it.

• Welcome to provisioning a Docker image registry.
• Welcome to setting up Traefik for TLS termination.
• Welcome to setting up security groups and service accounts.
• Welcome to configuring ingress and egress rules.
• Welcome to not understanding why this call from web to api times out. Is it egress, ingress, or both? Or is it because the api service link you put into the web env is cluster-local, and web lives in a different cluster?

I can hear you thinking, "Claude can do that for me, no problem," and you're right — but every time? For every project you start from scratch? And remember, all this setup bought you a nicer dev experience, aside from having to set it up and maintain it, but Kubernetes runs on top of real VMs. So the money problem isn't solved. It might even have gotten worse.

Here's what I came up with

• Put your Next.js app on Vercel — for most of us, their $20/mo tier is enough.
• Provision managed resources (Postgres, MongoDB, Kafka, RabbitMQ) from DigitalOcean, Supabase, Scaleway, AWS or Google Cloud. It doesn't really matter which; they all offer good SLAs.
• Put your API on DigitalOcean or Scaleway, either as serverless or on App Platform.
• Set up a GitHub Actions workflow — lint + test + build + deploy — as early as possible.

Doing this for every project is still a stretch, but when it's done properly you can git push to main and it'll just deploy, without having to run your own k8s.

Enough

This rant covers only a fraction of what's wrong with today's cloud infra. As a developer, I have to live with it every day. So I said "enough," and now I'm building gagarin, where deploying a web app is just:

gg resource add gagarin/pg postgres
gg ship         gagarin/api:8080 --deps pg
gg ship         gagarin/web:3000 --deps api
gg domain   add gagarin/web
# => Live at https://web-3cnciet6.apps.gagarin.cloud/

And a nice dependency graph is included:

First published on dev.to on 18 September 2026.