podland

About 9 months ago I built ‘Errol’, our internal issue triage bot. He’s incredibly useful at investigating all our Linear tickets and errors but it was built as a Rails 8 app. Things are moving quickly so surely there’s a better way to deploy a persistent event-driven agent in the cloud? 

When I asked around, the answer was “Cursor agents” and they do sound pretty good. But also, what if we built our own?

After the success of Errol, I have big ambitions for running agents in the cloud particularly for code review, issue triage, automated bug fixes, production monitoring, outlier identification, and incident response. I would also be ideal if we could run our own coding session in the cloud, in the same environment as these persistent agents, so we could leverage the same sets of scripts & skills. I’m curious about mob-programming in the age of AI so cloud-hosted agents would let us gather around the same agent session to review and direct it together.

One insight was that almost none of this needs to be built. The harness (Claude Code, OpenCode, Codex) is off the shelf and the substrate (Fly Sprites) has already solved how to run/persist/suspend lightweight VMs. The only custom pieces are really a control plane to tie it altogether with a UI, a supervisor inside each workspace, and some automation that builds the Sprite’s environment.

podland is that control plane. Each workspace is a Fly Sprite with the repo checked out and Claude running in tmux. The dashboard is a wall of live screens: which agents need you, which are ready for review, which are working or failed. Open a workspace and you get its terminal and its diff. The same system runs automations which are just agents woken by a cron schedule or other event such as a webhook (this is how the PR reviewer works).

I’m building it for Podia, as an experiment in adopting more cloud-hosted agents for monitoring and deployment follow-up. The first job is to replace ‘Errol’.

This time the control plane is Cloudflare Workers. It’s mostly glue (webhooks, timers, durable workflows, live status) and Workers do that without a server to look after.

How it was built

A Node supervisor on each sprite drives Claude Code in tmux and installs Claude’s hooks. Every hook becomes an event: a prompt means working, a permission prompt means “needs input” and is named after the tool call that caused it, and when a turn stops, the last line of Claude’s final message decides what happens next. If it ends in a question the workspace needs you; otherwise it’s ready for review.

The control plane is Hono on Cloudflare Workers with D1 for state, a Durable Object as the live feed hub with sockets tagged per viewer so you only receive your own workspaces, and Workflows for provisioning and monitor runs. The UI is React, Tailwind and xterm.js.

The UI was designed first in Claude Design as a nine-board canvas. Features the backend couldn’t support yet were built as visible placeholders marked “not built yet” and filled in as the backend caught up.

About 18,000 lines of TypeScript, CSS and SQL, with 329 test cases, in 110 commits over two days. Built with Claude Code across several sessions, with every change going through a PR, a review pass and a deploy. By the end of the first day it was good enough to run a PR review agent that reviewed its own PRs. By the second day, the UI smoke tests were written by Claude running inside a podland workspace, with the PR opened by podland’s own GitHub App.