Peeling the PaaS layer

Tuist is becoming an infrastructure company. This is by design – we are intentionally picking problems that will allow us to ship more open source, not less, because we want to contribute to bringing more freedom to the world. As part of this transition it became obvious that we had to evolve our approach to managing the infrastructure, so we went from using PaaS solutions like Render or Fly to declaring infrastructure as code using Kubernetes.

Until we started to adopt it, Kubernetes was for me synonymous with unnecessary complexity. PaaS solutions exist because most projects' infrastructure needs are just running a server, permanently or on invocation, that talks to a database. Both can be managed by someone like Vercel or Supabase, and you can go a long way with that. But we had to face that complexity, so we did, with a little twist: we had a coding agent in our toolbox. We deployed a management cluster using syself/cluster-api-provider-hetzner on Hetzner Cloud infrastructure (i.e. VMs), modeled our infrastructure using templates, and got everything up and running in a matter of days. What followed is something we hadn't planned for.

First, k8s is a language all LLMs speak, and that means you can lean on them to iterate on the design of the infrastructure and have a runtime that can reconcile those changes. But even more important than that, there's a runtime API for agents to inspect the state of the cluster. This became an indispensable tool for us, and we started using it more and more, to the point that we had to put some safeguards in place to prevent agents from going rogue and doing more than just read operations to debug. This was insanely useful because we could have conversations with agents about the system, translate those into specs, get them deployed, and iterate as needed based on what we learned. That's priceless. If you depend on something like Vercel, Render, Fly, or any of the many PaaS solutions out there, you depend on them to provide an interface to the infrastructure. The infrastructure is an implementation detail by design, which also comes with its own set of tradeoffs. For example, at Tuist we once had issues with Fly's network, and we had no way to debug what was going on at the lowest level, so that resulted in many back-and-forth emails with their support team and eventually moving to another PaaS platform, Render.com.

With this work, something became clear to me. In a world of agentic development, it's a perfect opportunity to peel away static layers of convenience like PaaS solutions, and go lower with dynamic compressors of complexity: coding agents. If you don't believe me, tell your coding agent of choice to set up a k8s cluster to deploy your project. I bet it'll be very effective at that if you give it access to Hetzner through their hcloud CLI. This motivated me to move some open source deployments that I had in a Hetzner VM using Cloudron, and make them part of a cluster. In essence, I have a management cluster for my personal projects, and another one with the workloads, for example Gesttalt, a blogging engine that I built with Elixir, or more recently Markdow, which I've built as a remote semantic layer to store Markdown files with MCP interfaces. Whenever I create a new project, I just tell the agent to make it part of the cluster, and voilà.

And I didn't stop there. I deployed GlitchTip, an error tracking solution that's compliant with the Sentry SDKs, so I can have all the services reporting errors to the same place, smolanalytics to collect analytics from the applications, a Grafana stack to report metrics, logs and traces, and I topped it off with Hermes, a bot so I can interface with the constellation of services from Telegram and ask questions like "are there recent errors?" or "has anyone signed up on X since yesterday?".

I'm moving all the services managed by Cloudron in a Hetzner VM, like Mastodon, PeerTube, or Nextcloud, to the k8s cluster, and shutting that instance and the Cloudron subscription down. Being able to lean on agents to set up, maintain, and evolve the infrastructure in Hetzner VMs has been quite empowering, and hosting most open source solutions is just one prompt away. This is something I've been thinking a lot about, especially in the context of open source projects monetizing by hosting them as a service, but that'll be a subject for another blog post.

By the way, I've written this blog post myself, fixed the grammar with Claude, and pushed it to Gesttalt through its MCP interface. Voilà. You can run your own Gesttalt instance in your k8s cluster too. It's fun, and I'd strongly recommend it.