Skip to content

Registering & Detecting Projects

Before MultiDocker can run a project, it has to know about it. Registration records the project’s path, chosen profile and hostnames in registry.json and generates its override file.

scan walks a directory tree looking for compose files (default root ~/Projects, maximum depth 4):

mdocker scan
mdocker scan
mdocker scan ~/clients --json

It is read-only — nothing is registered until you init.

detect runs the profile heuristic against a compose file without registering anything:

mdocker detect
mdocker detect ~/Projects/aurora/docker-compose.yml
mdocker init
mdocker init ~/Projects/aurora

init detects the profile, writes ~/.config/multi-docker/overrides/<name>.override.yml, and adds the project to the registry. For dockware-based projects it also patches the project’s .docker/proxy/*.conf files.

Flag Purpose
--name <N> Use an explicit project name instead of the directory name.
--profile <P> Force a specific profile instead of the detected one.
--host <H> Set a hostname. Repeat the flag for multiple hostnames.
explicit registration
mdocker init ~/Projects/aurora \
--name aurora \
--profile generic \
--host aurora.coding9.test \
--host admin.aurora.coding9.test

The heuristic (engine/detect.sh) inspects image and service names in the compose file and picks the best-matching template. Bundled profiles include:

  • shopware-dockware — Shopware 6 with the dockware proxy.
  • strapi-next — a Next.js front-end with a Strapi headless backend.
  • api-web-postgres — an nginx reverse proxy in front of a split api + web service with a PostgreSQL database.
  • generic — the fallback: any service exposing port 80 or 8080 gets synthesized Traefik labels automatically.

If detection guesses wrong, pass --profile at init, or change it later and re-render. To learn how templates are written and customized, see Writing & Customizing Profiles and the Profiles & Templating concept page.