monoceros start

Brings the named workbench up - the workspace container plus all services - without rebuilding. The cheap wakeup after a monoceros stop. With an <app> argument it instead starts a long-running server inside the workbench.

monoceros start <name> [--open <tool>]         # bring the workbench up
monoceros start <name> <app> [--target <t>]    # start an app inside it

The form is chosen by argument count: no <app> is container lifecycle, an <app> addresses a long-running app server.

Aspect	`apply`	`start`
Rewrites the scaffold from the yml	yes	no
Rebuilds when features changed	yes	no
Brings the container up	yes	yes

Use start to resume where you left off; apply to apply yml changes.

Start an app inside the workbench

monoceros start <name> <app> [--target <t>]

Starts the long-running server(s) declared in the app’s launch config (projects/<app>/.monoceros/launch.json). The container is brought up first if it is not already running. <app> is a path under projects/ (it may be nested, e.g. apps/web).

Without --target, start brings up the app’s default set (every target marked default, or its only one) in declared order; pass --target <t> to start a single one. Each server starts detached, so it survives the session. When a target declares a port, start waits until the port actually listens before moving on, then prints the reachable URL (http://<name>-<port>.localhost) - so ordering an entry before what depends on it sequences the set. If one fails to come up, the rest are not started.

Inside the container

The build agent (which has no host monoceros) starts the same app with the in-container runner:

monoceros-ctl start <app> [--target <t>]

The host command above is just a docker exec onto exactly this - one mechanism, two entry points. See Long-running app servers.

Examples

monoceros start acme                          # bring the workbench back up
monoceros start acme --open code              # resume, then open VS Code on it
monoceros start acme web                      # start the "web" app's default target
monoceros start acme apps/api --target dev    # start a specific target

Options

--open <tool> - after a successful container start, attach an editor (or a shell), the same as monoceros open. <tool> is code, codium or shell. A failure here only warns; it never changes the start’s exit code.
--target <t> - with an <app>, which launch target to start. Defaults to the app’s default target, or its only one.

Behavior

No rebuild. It boots the existing container as-is and does not read yml changes - use monoceros apply for those.
Restores the proxy when the yml exposes ports, so your *.localhost hostnames work again after a stop.
App start brings the container up first when needed, then runs the app detached and (with a port) waits for readiness.