Paddock

What is Paddock?

Paddock is a project-first launchpad for herdctl. It turns Claude Code into something you run on a server and reach from a browser: long-lived agents, one per project, whose chats persist and resume — instead of a laptop full of terminal tabs you can’t get back to from your phone.

A project is just a directory. Each one gets a herdctl keeper agent whose working directory is that project, and the chats you see in the UI are that agent’s Claude Code sessions — persisted on disk and resumable across reloads, reconnects, and devices.

Paddock isn’t just for software engineers. A project can be a codebase, but it can just as easily be a research notebook, a writing desk, or a home-ops runbook — anything you’d want a capable, always-available agent to work on. It shines when you run it on an always-on machine and give its agents the tools they need (a scoped GitHub token, ffmpeg, whatever your work calls for). See Who Paddock is for.

Project-first

Every project has its own keeper agent, files, and changelog. Notebook projects live in your data repo; repo-backed projects clone an external git repo as the agent’s working directory.

Persistent, resumable chats

Server-hosted sessions survive reloads, reconnects, and devices. Fork, queue-while-streaming, stop, search, and archive are built in.

Real tool use, streamed live

File writes, commands, and subagents render as they run, with a live context/cost meter per chat.

Built on herdctl

A thin project layer over the herdctl FleetManager. Anything the fleet engine does, Paddock can wire in.

Start here

Getting started Run Paddock with Docker or from source.

Deploying Paddock The recommended always-on, low-power setup.

Securing Paddock Put authentication in front — read before exposing it.

Concepts Projects, keeper vs scratch agents, chats-as-sessions, the sweeper.

Configuration Every PADDOCK_* environment variable, with defaults.

Architecture Storage model, WebSocket flow, MCP injection, auth.