monoceros apply

Materializes a config into ~/.monoceros/container/<name>/ and brings the dev container up.

monoceros apply <name> [--open <tool>] [--verbose]

What it does

Reads container-configs/<name>.yml, validates it (schema + catalog), and generates the dev container: devcontainer.json (plus compose.yaml when there are services), the multi-root .code-workspace, the AI briefing (AGENTS.md / CLAUDE.md), and .monoceros/state.json. The first apply pulls the base image and the service images; later applies build from the cache, so they are fast and land the same result on any machine.

Once the container is up it also installs the agent plugins the yml declares, and refreshes the ones already there. That step is best-effort: a marketplace it cannot reach is reported at the end and does not fail the apply. See Claude Code.

Note

The yml must pin a runtimeVersion. apply reuses it verbatim and never bumps it - an unpinned yml is rejected (run monoceros upgrade, or add it by hand). See Reproducibility and upgrades.

Running apps come back

apply recreates the container, so the long-running app servers you had up are torn down with it. Once the container is back, apply restarts the ones that were running - exactly the set you had started and not deliberately stopped, the same unless-stopped spirit as the rest of the stack. A server you stopped on purpose stays down; if nothing was running, nothing is printed.

Note

Needs a workbench on runtime 1.6.0 or newer. Below that, apps stay down across an apply (the prior behavior) - run monoceros upgrade to move up. See Long-running app servers.

Options

Flag	Description
--open <tool>	Attach an editor or a shell after a successful apply, same as monoceros open. code, codium or shell. A failure here only warns and never changes the exit code.
--verbose	Stream the raw @devcontainers/cli output instead of the phase spinner. On automatically when stderr is not a TTY.

monoceros apply acme --open code    # apply, then open VS Code on it

See the IDE guides for the editor setup.

What moves, what stays

The features in your workbench are brought up to date before you get a shell, and apply lists what it did. Everything your yml gives a version to stays put: languages, the runtime image, and any feature you pinned yourself. Service images are pulled on a workbench’s first apply and after that only by monoceros upgrade, because your data lives there.

   Features refreshed
     • claude 2.1.247 (updated from 2.1.240)
     • gh 2.60.1 (updated from 2.55.0)

A check that fails never fails your apply: offline it keeps what is in the image and says so. When the base image and the service images have not moved in a while, apply reminds you (default 30 days, upgrade.staleDays in monoceros-config.yml). The reasoning behind the split is in Reproducibility and upgrades.