I'm running AudioMuse-AI on a home server, but each instance can connect to either Navidrome or Jellyfin—not both. I'd like to run two separate instances at the same time, each with its own configuration and media-server connection.
I created a second project directory, cloned the application again, changed the port settings, renamed some container names in the Compose file, and started it with `docker compose --project-name am2 -f deployment/docker-compose.yaml up -d`. That works, and the second stack has names such as `am2-audiomuse-ai-flask-app`, but I'm not sure this is the correct or most maintainable approach.
What is the Docker Compose equivalent of a Kubernetes namespace? How should I organize, list, scale, and independently stop or remove multiple deployments of the same Compose application without them conflicting?
3 Answers
Use the Compose project name as the isolation boundary. Don’t set `container_name` manually in the Compose file; Compose will generate names based on the project, service, and instance number, such as `am2-audiomuse-ai-flask-app-1`. Different project names prevent collisions.
You can launch each instance with a different project name, for example `docker compose -p am2 up -d` and `docker compose -p am1 up -d`. To inspect one project, run `docker compose -p am2 ps`; to stop or remove only that stack, use `docker compose -p am2 down`. You can also list everything with `docker ps --filter label=com.docker.compose.project=am2`. Separate repository copies aren’t required as long as the configurations, environment files, volumes, and project names are kept distinct.
The project name normally comes from the Compose project directory, but you can override it with `-p` or configure it in the Compose setup. Keeping each deployment in its own directory can still be useful for mental organization, especially when each instance has different `.env` values, ports, bind mounts, or volumes. The important part is that the project names and external resources don’t overlap.
Profiles and multiple Compose files are other options, but they solve slightly different problems. Profiles are useful when the same project sometimes runs optional services. For two simultaneously running copies of the same application, separate Compose projects with unique names are generally the simplest approach. Make sure every host port, named volume, network, and any external resource that must be isolated is unique or intentionally shared.
I’ll probably keep the deployments in separate folders for clarity, while using project names for the actual Compose isolation. That should also make bringing down one instance straightforward.
That clears things up. I was treating the container names as the main isolation mechanism, but using separate project names and letting Compose generate the names is much cleaner.