Keep the agent you already use, and give it somewhere to work. Your stack, your services and your repos come 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.gitIt opens ACME-126 itself, reads it, gathers what it needs 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, one builds exactly that, and one checks the result before it reaches you.
How the roles work →A workbench holds exactly what its project needs and nothing more. The versions, the services and the access are already there when the agent starts.
Adding components →The agent starts signed in and briefed. 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. There is nothing to set up. It is the same box the agent works in, so you see what it sees.
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 what 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. It is one YAML file, and you can edit it.
› 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 You get a real container with your stack, up in minutes. That is the box your agent works in.
› monoceros apply acme ▸ pulling image, installing features... ✓ workbench ready
Hand over a ticket number and let it run. It opens ACME-126 itself, reads the comments, and works with the stack it was briefed on. On its own, 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
The loop starts at a ticket. If you don't have one yet, you say what you want to build, answer the questions that come up, and get back a backlog the agent can work from. From an idea to a Jira backlog
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. The version one project needs is the version the next one gets. An agent working there can reach 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 nothing 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. It keeps working when the network does not.
You write a Dockerfile for the project, connect each tool by hand, and keep the agent roles up to date 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.
It is open source and it runs on your machine. Install it on macOS, Linux or Windows, then build a workbench with one command.
› 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. We build and test against Docker Desktop. On Windows you need it, 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 you add one of them with a single line in your file. An agent the catalog does not have goes into the same file, either as a dev-container feature or as an apt package. Do not install it by hand inside the container. That only lasts until the next apply, because Monoceros builds the container from that file again.
How the file works →Only what you send on purpose. There is no account, no telemetry and no Monoceros service in between. The images come from a registry, and your agent talks to the 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: 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, 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 →