Skip to content

FAQ

Several things that look like bugs are actually deliberate design decisions. Here’s the reasoning behind the most common questions.

OrbStack is recommended. With OrbStack, every container is automatically reachable from the host as <service>.<project>.orb.local, which makes database access painless. With Docker Desktop, host DNS into containers isn’t available, so reaching a database from the host means temporarily mapping a port by hand (a future mdocker expose will smooth this over). Everything else works on both.

Why does my browser ask for “Local Network” permission?

Section titled “Why does my browser ask for “Local Network” permission?”

Because MultiDocker domains resolve to container IPs on your machine, recent macOS versions require the Local Network permission before the browser will connect. Grant it once and the HTTPS padlock behaves normally. This is a macOS privacy prompt, not a MultiDocker error.

My demo-tunnel URL keeps changing / has no password

Section titled “My demo-tunnel URL keeps changing / has no password”

That’s by design. Public demo tunnels use a Cloudflare trycloudflare.com quick tunnel with no account:

  • The URL is random and changes on every start.
  • There is no password protection — anyone with the link can reach it.
  • Tunnels don’t survive a reboot (the process is gone, so mdocker share ls prunes it).

Named tunnels and password protection are on the roadmap; for now, treat a shared link as temporary and public.

Shopware assets in the shared tunnel point at my local domain

Section titled “Shopware assets in the shared tunnel point at my local domain”

Applications that generate absolute URLs — like Shopware building asset/link URLs from the sales-channel domain — will keep pointing at your local domain even through the tunnel. Align the sales-channel domain with the Traefik hostname using mdocker shop domain sync. See Shopware Workflows.

mdocker git info shows stale ahead/behind numbers

Section titled “mdocker git info shows stale ahead/behind numbers”

On purpose. The git snapshot is entirely local — it never runs git fetch. Ahead/behind reflect your last local sync with the remote, so the command is fast and side-effect-free. Fetch yourself if you want fresh numbers. See Git Status per Project.

The app and my terminal see different projects and tunnels

Section titled “The app and my terminal see different projects and tunnels”

Also by design. The macOS app uses ~/.multidocker/config/ while the standalone CLI uses ~/.config/multi-docker/separate config directories, separate registries and tunnels. A project registered in one won’t appear in the other. See CLI vs. App: Separate Worlds.

I changed the base domain and nothing works

Section titled “I changed the base domain and nothing works”

Changing it via mdocker config set BASE_DOMAIN <new> regenerates the certificate, the resolver files, every project override and the edge stack automatically. Two follow-ups: restart your browser (so it re-reads the CA and clears cached lookups), and if a specific project is still off, run mdocker rerender <name>. See Changing the Base Domain.

edge down stopped all my projects — is that a bug?

Section titled “edge down stopped all my projects — is that a bug?”

No. The edge stack (Traefik, DNS, certs) is the foundation every project depends on, so mdocker edge down deliberately stops all running projects first — otherwise they’d dangle unreachable on the removed network. To bounce only the edge and leave projects running, use mdocker edge restart. See The Edge Stack.

After an app update, are my certificates gone?

Section titled “After an app update, are my certificates gone?”

No. Certificates live under ~/.config/multi-docker/certs/ (CLI) / the app’s config/certs/outside the versioned runtime folder — precisely so a runtime update can’t overwrite or delete them. See Filesystem Layout.