CLI vs. App: Separate Worlds

The app and the standalone CLI run the same engine, but they don’t share state. Each points MD_CONFIG_DIR at a different directory, so a project registered in one doesn’t appear in the other. This is intentional — but it surprises people, so it’s worth being explicit.

Two config directories

	Config directory
Standalone CLI (`mdocker` in your PATH)	`~/.config/multi-docker/`
macOS app	`~/.multidocker/config/`

Everything derived from config follows the split: separate registry.json, separate overrides/, separate certs/, separate snapshots, and separate share tunnels.

Why they’re separate

The app manages its own bundled runtime and keeps all of its data under one tree (~/.multidocker/) so that installing, updating and migrating the app is self-contained. Mixing its state with a hand-installed CLI would make updates and migrations fragile. Keeping them apart means:

The app can update its runtime and migrate its data without ever touching a CLI you installed yourself.
A broken experiment in one environment can’t corrupt the other.

The shared edge stack

There’s one important thing they do share: the edge stack and the underlying Docker engine. There’s only one Traefik, one multi-docker-edge network, one set of ports 80/443/53 on your machine. So if the app brought the edge stack up, a CLI mdocker edge status sees it up too — and mdocker edge down from either side stops it for both.

The certificates are per-config-directory, but since both are generated by the same mkcert CA mechanism for the same base domain, HTTPS works either way once TLS is set up.

Which am I using?

If you launched MultiDocker.app, you’re in the ~/.multidocker/config/ world.
If you typed mdocker in a terminal, you’re in the ~/.config/multi-docker/ world (unless you set MD_CONFIG_DIR yourself).

The app’s user symlink at ~/.local/bin/mdocker runs the app’s runtime, but a raw mdocker invocation still uses the standalone config directory unless overridden.

Practical advice

Pick one primary environment for a given project and stick with it. If you mostly drive things from the app, register and manage projects there; drop to a terminal only for scripting, and remember that terminal will be looking at the standalone config directory unless you point MD_CONFIG_DIR at the app’s.

MultiDocker · Coding9 GmbH