Keep the agent you already use and give it somewhere to work: your stack, services and repos from one file, on your own machine, in its own container.
Open source · your own Docker · no cloud, no account, no rental
name: acme
languages:
- node:22
services:
- name: postgres
image: postgres:18
features:
- ref: ghcr.io/getmonoceros/monoceros-features/claude-code:1
- ref: ghcr.io/getmonoceros/monoceros-features/claude-code-roles:1
- ref: ghcr.io/getmonoceros/monoceros-features/github-cli:1
- ref: ghcr.io/getmonoceros/monoceros-features/atlassian:1
mcpServers:
- name: figma
repos:
- url: https://github.com/acme/hosts-guestbook.git It opens ACME-126 itself, reads it, builds the context and implements it. Then it opens a pull request. You come back to an app that already runs.
See all features →Three roles come with the workbench: one writes the plan down, one implements exactly that, one checks the result against it before it reaches you.
How the roles work →A workbench holds exactly what its project needs and nothing more. The agent finds the versions, services and access in place, and can start its work.
Adding components →The agent starts signed in and briefed, so it reads the ticket itself, writes the code, and checks the result against the app running next to it in the workbench.
Claude Code, OpenCode and Rovo Dev. Jira, GitHub, Notion, Figma.
What the agents get →
Attach VS Code, VS Codium, JetBrains or the Claude app over SSH, with nothing to set up. It is the same box the agent works in, so you are looking at the same thing it is.
Open it in your IDE →
The app keeps running after the session ends, at an address you can type. One command puts it on your network over HTTPS, so the thing you just built opens on your phone.
The guest book here is our example app for Airbnb hosts, built in the acme workbench.
Open it on any device →
Describe the workbench, build it, let the agent run, reset to clean. That's the whole loop.
Say what goes in: your stack, your repo, the AI tool. One YAML, editable.
› monoceros init acme \
--with-languages=node \
--with-services=postgres \
--with-features=claude,claude-code-roles,github,atlassian/twg \
--with-mcp-servers=figma \
--with-repos=https://github.com/acme/hosts-guestbook.git A real container with your stack, up in minutes. That's the box your agent lives in.
› monoceros apply acme ▸ pulling image, installing features... ✓ workbench ready
Hand over a ticket number and let it go. It opens ACME-126 itself, reads the comments, and builds against the stack it was briefed on. Unattended, in its own container.
› monoceros run acme --in projects/hosts-guestbook -- claude "Implement Story ACME-126" ▸ reading ACME-126 from Jira... ▸ agent working in acme...
Made a mess? Reset to clean in minutes. Or keep the workbench for next time.
› monoceros remove acme ▸ snapshot saved ✓ host clean
You can get most of this without us. The question is what it costs you, on every project and every time.
The languages, the databases and the tools all sit on the same laptop, so the version one project needs is the version the next one has to live with. An agent working there reaches all of it.
Each project gets its own container, with its own versions and its own services. The agent works inside it, and one command removes the whole thing when the project is over.
Your code and your data live on a vendor's servers, and you pay for every hour they run. Many contracts do not allow that, and none of it works when you are offline.
The workbench runs on your own Docker. There is no account to create, nothing to rent and no hourly bill, and it keeps working when the network does not.
You write a Dockerfile for the project, wire up each connector by hand and keep the agent roles in step with them. Then you do all of it again for the next project.
One file describes the workbench and one command builds it. You never maintain the box yourself, and every project gets its own version of it.
Open source, runs on your machine. Install on macOS, Linux or Windows, then one command to build a workbench.
› curl -fsSL https://raw.githubusercontent.com/getmonoceros/workbench/main/installer/install.sh | bash › irm https://raw.githubusercontent.com/getmonoceros/workbench/main/installer/install.ps1 | iex Yes, and it is the only thing you install on your own machine. Docker Desktop is what we build and test against. On Windows it is required, because the installer connects the managed Linux distribution to it.
Installation →Yes, on WSL2. The installer sets up a managed Linux distribution for you, and the commands are the same ones you would run on macOS or Linux.
Windows setup →Yes. Claude Code, OpenCode and Rovo Dev are in the catalog, and adding one of them is a single line in your file. An agent the catalog does not carry goes into the same file, either as a dev-container feature or as an apt package. Installing it by hand inside the container works only until the next apply, because the container is rebuilt from that file.
How the file works →Only what you deliberately send. There is no account, no telemetry and no Monoceros service in the middle. Images come from a registry, and your agent talks to whatever provider you signed it in to.
What Monoceros is →Nothing. Monoceros is open source under Apache-2.0 and runs on hardware you already own. There is no paid tier waiting behind the free one.
The repository →Underneath it is one, generated from your file. The difference you feel every day is that nothing is lost when you rebuild: the container keeps a persistent home, so your agent stays signed in, your tool settings and editor extensions stay in place, and your repos keep their branches. On top of that come the services, the repos and the agents, and one command that builds or resets the whole thing.
The concept →