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.

A project registered in one is invisible to the other

If you run mdocker init in a terminal, that project lands in ~/.config/multi-docker/ and the app won’t list it — and vice versa. They’re genuinely separate worlds, not two views of one dataset.

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.

Symptom to remember

“The app and my terminal see different projects / different tunnels” is not a bug — it’s the two config directories. See the FAQ.