Run a self-hosted cloud console on a $6 VPS with an AI DevOps agent

Sre Chakra Yeddula moved nine apps off managed cloud onto one $6 a month VPS and has a Grok agent called Devvy deploy, patch and audit the server, cutting a $100 to $200 monthly bill.

Done withGrok BotinDockerPostgresql· Oct 19, 2026

What they did

Yeddula had websites and apps spread across AWS and Google Cloud and wanted the managed feel without the bill. With AI help they built OpenCloud, a small open source layer on one VPS: Caddy as the single public entry, a deploy service that builds and rolls back Docker containers, per-app Postgres on private networks, an S3-style store on SeaweedFS, mounted secrets, a log and alarm service and a shared AI gateway in front of OpenRouter. A Grok agent the author calls Devvy acts as the DevOps engineer. It maintains the server, ships deploys, fixes bugs and runs checks, and the author approves each change in chat. OS patches come from unattended upgrades rather than the agent.

How it went

All nine apps now run on the one box for $6 a month, against an estimated $100 to $200 before. After the move, Devvy and the author compared the live setup with the intended design and found drift: a database app on a superuser role, apps that had lost read-only roots and health checks, the console on the shared app network, a builder that could reach the agent API and a stale gateway still holding a provider key. The author says all of it was fixed. The last full test run on October 17 passed 192 of 192 checks.

Worth knowing

It is still one server, so one point of failure, with monitoring on the same machine and backups not yet off-site. Apps share one internal network, and the builder is only meant for trusted code. The post says little about how Devvy is set up beyond calling it a Grok agent with chat approvals, so the exact Grok product is an inference.

Try it

With Grok Bot· 4 parts to fill in

You are the DevOps engineer for my single server at [server address], which runs [list of apps] in Docker behind [Caddy or my reverse proxy]. First, read the intended architecture in [design doc or repo] and compare it with the live configuration: database roles, read-only filesystems, health checks, which networks each container joins, open ports and where secrets are mounted. List every place the live setup has drifted, with the fix for each. Then, one change at a time, apply the fixes and any deploys I ask for, rolling back if a health check fails. Show me each change and wait for my approval in chat before you run it, and never open a new public port or touch backups without asking.

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

Related