What you get
A console for agents that keep running
Every session, in one place
Sessions are tagged by what started them, so a nightly cron run and a Telegram question sit in the same list with the same transcript. A worker can be restarted without losing the thread — history lives on a Docker volume, not in the container.
Watch the agent think
The broker reads the worker's SSE stream and fans it out over a WebSocket. Tool calls, reasoning blocks and todo lists appear as they happen; compact events go to SQLite and the full transcript is kept when the session goes idle.
Agents defined once, reused everywhere
An agent is a row in SQLite — model, mode, temperature, permissions, system prompt —
plus the MCP servers and skills attached to it. At session start that becomes a stock
opencode.json and a set of markdown files in the worker's workspace.
Nothing proprietary: what the worker sees is ordinary opencode configuration.
Automation that ships with the box
Cron schedules carry a timezone and record every run. Webhooks give any external system a URL to start an agent, optionally guarded by a secret, optionally blocking until the answer is ready. Telegram runs inside the broker on long polling — no public URL, no extra dependency — and streams the reply by editing the bot's message. Point it at a notification chat and every scheduled or webhook run reports back there, either always or only when it fails.
Events that go out, not just in
Outgoing webhooks turn the broker into a source of events instead of only a target.
Subscribe a URL to session.completed, session.failed,
schedule.fired or webhook.received and it gets a POST with
the session summary. Set a secret and the raw body is signed with HMAC-SHA256.
Failed deliveries retry with backoff — 1s, 5s, 15s, 60s, 300s — and every attempt,
successful or not, stays in the per-webhook delivery log with its response code,
ready to be replayed by hand.
POST https://ci.example.com/hooks/vibeprod X-Vibeprod-Event: session.completed X-Vibeprod-Signature: sha256=… {"event": "session.completed", "timestamp": "2026-08-15T09:00:00Z", "data": {"id": "…", "title": "Review PR #482", "result_text": "…"}}
Files that outlive the container
A worker's workspace disappears with the worker. Project files don't: every project
gets its own bucket in a MinIO container that comes with the compose file, browsable
and uploadable from the Files page. Agents reach the same storage
through the files MCP server in the catalog — one click to attach —
whose upload_file tool pushes a file out of the worker and returns a
link. Together with Playwright and the bundled screenshot-to-files
skill that is a complete loop: take a screenshot, put it in the project, answer with
the URL.
A browser, a database, an API — one click each
The MCP catalog holds reusable servers: ordinary local and remote ones, and Docker services that Vibeprod starts on demand. The bundled Playwright service gives any agent a real browser in its own container, on a private network the workers share.
Keys you can actually verify
Provider keys live in your database and are injected into workers as environment variables. Check spins up a throwaway container with the same opencode image and your key, confirms the provider registers, lists the models it offers and makes a real generation call — the exact path a worker will take, so a bad key fails here instead of halfway through a scheduled run.
A lock on the front door
Put a login and password in .env and the UI asks for them: pages and the
whole API move behind a signed cookie that lasts a week. Webhook endpoints keep their
own secret and the operator's MCP endpoint keeps its bearer token, so automation
carries on working. Leave both variables empty and nothing changes — no login at all,
the way it was. This is one shared account, not user management: there is no user
list, no roles, and no audit trail.