Bloated Clouds, Anyone? A developer is building Gagarin Cloud, a platform aimed at simplifying web deployment in response to the complexity and cost of conventional cloud infrastructure. The developer argues that mainstream clouds have become bloated, forcing teams to choose between managing Kubernetes and DevOps overhead or delegating operations to AI agents that cannot be held accountable for failures. The proposed alternative combines Vercel for frontend hosting, managed databases from providers like DigitalOcean and Supabase, and GitHub Actions for CI/CD. TL;DR 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 we'll look at the options in the next post , - 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 for instance, Next.js https://nextjs.org has server-side caching, and it doesn't work when you run it as a scale-to-zero container , - Firebase Cloud Functions https://firebase.google.com/docs/functions are public by default and weird to set up they have their own CLI just to package and deploy them, and only JS/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. Suppose you do want the scalability, smooth CI deploys that just make sense, and all your code living in a GitHub repo you control. Welcome to Kubernetes https://kubernetes.io and the 4,000 lines of YAML config that come with it. - Welcome to provisioning a Docker image registry. - Welcome to setting up Traefik https://traefik.io 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 https://claude.ai 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 https://vercel.com for most of us, their $20/mo tier https://vercel.com/pricing is enough . - Provision managed resources Postgres https://www.postgresql.org , MongoDB https://www.mongodb.com , Kafka https://kafka.apache.org , RabbitMQ https://www.rabbitmq.com , etc. from DigitalOcean https://www.digitalocean.com , Supabase https://supabase.com , Scaleway https://www.scaleway.com , AWS https://aws.amazon.com , or Google Cloud https://cloud.google.com . 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 https://www.digitalocean.com/products/app-platform . - Set up a GitHub Actions https://github.com/features/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. 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 Cloud https://gagarin.cloud/ , where deploying a web app is just: And a nice dependency graph is included: