Reading up on devops

A few months ago my kids started vibecoding little web games with Cursor and wanted their friends to play them. GitHub Pages was fine until the games needed real backends, so I hacked together a setup where each game was a folder in one repo that deployed to a Hetzner box on every push. That held up until we shipped FULL SEND for Vibe Jam 2026 and it took off with 38,000+ players. The duct tape needed to become something real, so I rebuilt it properly and pulled it out into its own project. It turns one Linux server into a push-to-deploy host for many apps. The whole thing is a single Go binary that installs and drives Docker, Kamal, Cloudflare, Tailscale, and GitHub for you. After that: - Each app is a GitHub repo. - A git push is live in <5 seconds. - Deploys are zero-downtime. - Each app runs in its own container. - Automatic Cloudflare DNS and TLS tunnels. - SQLite-aware backup and restore. It's deliberately single server using convention over configuration, so for a typical app there's no YAML or Dockerfile to write. The idea is that one decent VPS can reliably run all your projects without per-app bills or piles of infra config. It's built on top of Kamal, so it's basically a Kamal wrapper for the "lots of apps on one server" case, with the Cloudflare, Tailscale, DNS, and backup glue wired up by convention. Setup is one interactive command on a fresh Linux box, which walks you through connecting everything. If you also have a bunch of projects you want to run on a single server, tell your Claude Code, Codex, Cursor, or favorite AI agent to grab a VPS and try it for you. It's fully open source and you can customize it to your liking:

@dvassallo

When I built menugen ~1 year ago, I observed that the hardest part by far was not the code itself, it was the plethora of services you have to assemble like IKEA furniture to make it real, the DevOps: services, payments, auth, database, security, domain names, etc... I am really looking forward to a day where I could simply tell my agent: "build menugen" (referencing the post) and it would just work. The whole thing up to the deployed web page. The agent would have to browse a number of services, read the docs, get all the api keys, make everything work, debug it in dev, and deploy to prod. This is the actually hard part, not the code itself. Or rather, the better way to think about it is that the entire DevOps lifecycle has to become code, in addition to the necessary sensors/actuators of the CLIs/APIs with agent-native ergonomics. And there should be no need to visit web pages, click buttons, or anything like that for the human. It's easy to state, it's now just barely technically possible and expected to work maybe, but it definitely requires from-scratch re-design, work and thought. Very exciting direction!

@karpathy

Semi shameless plug for https://t.co/IB5IP4luON (this + docker + kamal = enough ?.)

@dmarctrust