{"slug": "bloated-clouds-anyone", "title": "Bloated Clouds, Anyone?", "summary": "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.", "body_md": "## \n  \n  \n  TL;DR\n\nConventional 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.\n\n## \n  \n  \n  You can rent a *plain VM*, *but*\n\n- regular deployments have to arrive via SSH or some elaborate CI setup (we'll look at the options in the next post),\n- you'll be paying for more compute than you actually use,\n- and when your service becomes popular enough to use its entire CPU/RAM allowance, you have to scale it up manually.\n\n## \n  \n  \n  You can go *serverless* and it will scale up and down automatically, *but*\n\n- 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),\n- \n[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),\n- 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.\n\n## \n  \n  \n  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.\n\n- Welcome to provisioning a Docker image registry.\n- Welcome to setting up [Traefik](https://traefik.io) for TLS termination.\n- Welcome to setting up security groups and service accounts.\n- Welcome to configuring ingress and egress rules.\n- 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?)\n\nI 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!\n\n## \n  \n  \n  Here's what I came up with\n\n- Put your Next.js app on [Vercel](https://vercel.com) (for most of us, their[$20/mo tier](https://vercel.com/pricing) is enough).\n- 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.\n- Put your API on DigitalOcean or Scaleway, either as serverless or on [App Platform](https://www.digitalocean.com/products/app-platform) .\n- Set up a [GitHub Actions](https://github.com/features/actions) workflow (`lint + test + build + deploy` ) as early as possible.\n\nDoing 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.\n\nThis 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:\n\nAnd a nice dependency graph is included:", "url": "https://wpnews.pro/news/bloated-clouds-anyone", "canonical_source": "https://dev.to/sharpvik/bloated-clouds-anyone-1jhc", "published_at": "2026-09-18 19:25:58+00:00", "updated_at": "2026-09-18 19:53:14.651908+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools"], "entities": ["Gagarin Cloud", "Vercel", "DigitalOcean", "Supabase", "Scaleway", "Kubernetes", "GitHub Actions", "Claude"], "alternates": {"html": "https://wpnews.pro/news/bloated-clouds-anyone", "markdown": "https://wpnews.pro/news/bloated-clouds-anyone.md", "text": "https://wpnews.pro/news/bloated-clouds-anyone.txt", "jsonld": "https://wpnews.pro/news/bloated-clouds-anyone.jsonld"}}