Running two copies of the same application is possible at the Docker Compose layer, but changing only the main container name and web port is not enough for a multi-service stack such as Immich.
Use a Separate Compose Project for Each Instance
Docker's Docker Compose project names says Compose project names are designed to isolate multiple environments that might otherwise share service names. Give each instance a unique project name rather than relying on manually renamed containers as the primary isolation mechanism.
The first Docker app explains the ZimaOS Compose layer, while the Portainer on ZimaOS can help advanced users inspect independent stacks.
Immich Is a Stack, Not One Container
The current Immich Docker Compose uses multiple services and separates upload storage from database storage. A second Immich instance therefore needs its own database data, upload path, cache/model data where applicable, and any host ports that would otherwise collide.
What Needs to Be Unique
- Compose project name: isolates service, network, and volume namespaces.
- Published host ports: two instances cannot bind the same host port.
- Persistent folders/volumes: do not point independent databases or upload libraries at the same writable data directory.
- Environment references: keep each stack internally consistent.
The Immich storage migration is useful for understanding which Immich paths are persistent and why they should not be casually shared between installations.
Avoid Hard-Coded container_name Unless You Need It
Compose can normally generate names from the project and service names. Hard-coding container_name increases the chance of global name collisions and makes duplicated stacks more brittle.
Bottom Line
The correct mental model is “two isolated Compose projects,” not “the same app with two renamed containers.” For Immich, isolate every service's persistent state and any published ports. Shared state can make the second stack fail or interfere with the first.
