Docker Compose Project Name Collisions: Stop Stacks Overwriting Each Other

January 8, 2026 • February 3, 2026 • Read: 23 min • Views: 13

Was this helpful?

It starts as a harmless “quick test.” Someone runs docker compose up -d in a new directory, on a host that already runs three other Compose stacks. Five minutes later, a pager goes off. A container got “recreated,” a network name got reused, and a volume got mounted by the wrong service. Production didn’t just drift. It got mugged in an alley by a naming convention.

Compose is friendly right up until it isn’t. The failure mode is subtle: nothing “crashes” immediately; instead, stacks quietly overlap, containers get adopted, and down removes the wrong things with the confidence of a toddler holding scissors.

What a Compose “project name” really is (and why it bites)

In Compose, the project name is the namespace boundary. It’s how Compose decides which containers, networks, and volumes belong together as “one stack.” If you’re thinking, “the directory name is the project,” you’re half-right. That half is what causes trouble.

Compose uses the project name to generate resource names and to apply labels that it later uses to find and manage the stack. That means:

Container names often look like <project>_<service>_1 (or with hyphens, depending on Compose version and settings).
Default network names often look like <project>_default.
Named volumes often become <project>_<volume> unless you explicitly name them.
Labels like com.docker.compose.project and com.docker.compose.service are attached, and Compose uses those labels later during up, down, ps, and cleanup.

A project name collision is when two Compose runs use the same project name (intentionally or not) on the same Docker daemon. Compose then treats them as the same stack. It will happily “reconcile” state: recreate containers, reattach networks, reuse volumes, or remove resources the other stack needed.

Here’s the part that surprises people: collisions don’t require identical Compose files. They only require the same project name and overlapping resource names/labels. Compose is not a cluster scheduler. It’s a state reconciler that assumes you meant what you typed.

Joke #1: Docker Compose project names are like office kitchen labels: if two people write “Lunch,” somebody’s eating sadness.

Where the project name comes from (precedence matters)

Compose picks a project name using an order of precedence. If you don’t deliberately set it, you’re letting the environment set it for you, which is an optimistic way to run production.

Common sources, roughly from “most explicit” to “least”:

docker compose -p <name>
COMPOSE_PROJECT_NAME environment variable
Top-level name: in the Compose file (supported by modern Compose v2)
The base name of the project directory (often the current directory)

If your organization has multiple repos named app, multiple directories named docker, or a habit of cloning things into /srv without unique folder names, you’ve already built a collision machine. Add CI runners that use the same checkout path and you can manufacture outages on demand.

How collisions happen: the three naming layers

To stop collisions, you need to understand what’s colliding. Compose stacks overlap in three main ways:

1) Compose’s project namespace (labels and lookup)

Compose finds “its” resources by labels. The big one is com.docker.compose.project. If two stacks share the same project name, Compose will select resources across both when performing actions like down, restart, and sometimes up with orphan cleanup.

This is where “stacks overwriting each other” really happens. Compose isn’t overwriting files; it’s reconciling container definitions against a set of labeled objects it believes are one project.

2) Docker object names (containers, networks, volumes)

Even if labels are correct, Docker object names can collide if you hardcode names:

Hardcoded container names via container_name: are global on a daemon. Two stacks can’t both have container_name: postgres. One will fail, or worse, you’ll hand-manage it and forget what owns it.
Hardcoded network names via networks: default: name: foo can make separate projects share a network. That might be intentional. It also might be a data-leak party.
Hardcoded volume names can make separate projects share data. Again, maybe intentional. But most of the time it’s a “why is staging using prod data?” kind of intentional.

3) Port bindings and host resources

Even if naming is perfect, the host is still one host:

Two stacks binding 0.0.0.0:80 will collide. Compose will error out (best case) or you’ll route traffic somewhere weird (worst case: front proxy points to the wrong backend).
Two stacks mounting the same host path (like /var/lib/app) can overwrite each other’s state.
Two stacks using the same secrets/configs paths on the host can cause “works on my machine” failures with a production twist.

The sneakiest collisions are the ones where Docker allows sharing (volumes, networks) and Compose encourages it unless you tell it not to.

Interesting facts and historical context

Some context helps because Compose behavior didn’t appear out of thin air. Here are concrete facts that explain why the project name is both powerful and dangerous:

Compose started as “Fig” (2013–2014 era). Its early job was: “spin up a bunch of containers from YAML,” not “manage multi-tenant environments on the same daemon.” Namespacing was pragmatic, not paranoid.
Compose v1 was a Python tool for years. The modern docker compose (v2) is a Docker CLI plugin, and some defaults and naming output changed across the transition.
Project names were designed to be derived from directories because it made local dev easy: clone repo, run Compose, get isolated resources “automatically.” On shared hosts, that “automatic” becomes “random.”
Labels became the primary ownership mechanism as Docker matured. Compose relies heavily on labels like com.docker.compose.project because container names alone aren’t reliable once users customize them.
container_name: is intentionally discouraged in many production patterns because it breaks scaling and increases global-name collisions. Compose can’t create multiple replicas of a service with a fixed container name.
Default network per project was a major usability win: it reduced the need for manual linking and gave service discovery within a project. It also made the project name the network namespace.
“Orphan containers” cleanup evolved over time. Options like --remove-orphans are useful, but when project identity is wrong, they become a chainsaw.
Compose’s “down” semantics are intentionally destructive: it removes resources it believes it created. That’s correct behavior—unless your project boundary is wrong.
Swarm stacks and Compose projects are different concepts, but humans confuse them because both use YAML and both say “stack.” That confusion causes operational shortcuts and naming mistakes.

Three corporate mini-stories from the collision trenches

Mini-story 1: The incident caused by a wrong assumption

At a mid-sized SaaS company, a team ran “temporary” load testing on the same Docker host that ran a staging environment. They were careful, they said: different directories, different Compose files, different service names. What could collide?

The assumption was: “Different directories means different stacks.” They didn’t pass -p, didn’t set COMPOSE_PROJECT_NAME, and their working directory for both runs happened to be /srv/app because they used a shared automation script that cd’d there unconditionally.

The load test Compose file defined a Redis service and a worker service. Staging also had Redis and workers. Same project name meant Compose believed it was one project. When the load test started, Compose “helpfully” recreated the worker container with the load-test image because it matched the service name under the same project label.

Nothing failed immediately. The worker process came up fine. It was just the wrong worker, connected to the same staging Redis and queue. Staging users saw jobs processed out of order and some jobs “disappeared” due to incompatible message formats. The incident wasn’t a crash; it was corrupted behavior. Those are the ones that steal your weekend.

The fix was boring: explicit project names for every environment, and automation that refuses to run Compose without a project name. The postmortem line that mattered: “Directory names are not isolation.”

Mini-story 2: The optimization that backfired

A platform team wanted faster deploys. They noticed Compose recreations took time on a busy host, so they optimized by pinning object names: explicit container_name, explicit network names, explicit volume names. The idea was to make troubleshooting easier and reduce “churn.”

It worked for a month. Then two internal teams deployed different services that both used a shared “base” Compose snippet. The snippet set container_name: api because someone thought it was “clean.” Now two stacks tried to create a container called api on the same daemon.

Compose refused to start the second stack, and the team “fixed” it by manually removing the existing container and restarting. That got the second stack running… and silently killed the first service. The outage wasn’t from Docker; it was from humans wrestling a naming decision that removed Compose’s ability to safely manage multiple instances.

The final twist: the explicit network name caused cross-talk. Debug containers from one stack could resolve and reach services in another stack because they were on the same user-defined network. Nobody intended that. It just happened because the “optimization” replaced isolation with convenience.

They rolled back the naming “optimization,” kept explicit project names, and only hardcoded names when the requirement was real (like integrating with external systems that expect a stable network name). The performance gain wasn’t worth the ambiguity tax.

Mini-story 3: The boring but correct practice that saved the day

A regulated enterprise ran Compose on a fleet of snowflake VMs (don’t laugh, you’ve been there). They had a habit that looked overkill: every stack had a unique project name, the project name included environment and owner, and it was set in two places: CI passed -p, and the repo included a .env with COMPOSE_PROJECT_NAME for local runs.

One day an engineer needed to hotfix a staging issue and accidentally ran Compose from the wrong directory on the host. The Compose file was correct, but the working directory was inside another repo. Without the safeguards, that would have reused the other repo’s project name and started the overlap dance.

Instead, their deploy wrapper printed the resolved project name and refused to proceed unless it matched an allowlist for that host. It was simple: parse docker compose config, check the name, check the expected labels, then run up. The engineer grumbled, corrected the command, and moved on.

Weeks later, during an unrelated incident review, they realized the wrapper had prevented a collision that would have compounded the outage. Nobody wrote a heroic Slack thread about it. That’s the point. Boring controls are what keep you from starring in your own postmortem.

Practical tasks: 12+ commands that expose collisions (and what to do next)

These are not “nice to know.” They’re what you run when someone says “Compose overwrote my stack” and you want evidence, not vibes. Each task includes: command, what the output means, and the decision you make.

Task 1: See what project name Compose will use before it touches anything

cr0x@server:~$ cd /srv/staging/app
cr0x@server:~$ docker compose config --format json | head
{
  "name": "app",
  "services": {
...

What it means: The resolved project name is app. If you expected staging-app, you’re already in collision territory.

Decision: If the name is too generic, stop and rerun with -p or set name:/COMPOSE_PROJECT_NAME. Do not run up.

Task 2: Confirm the project name Compose is using for a running stack

cr0x@server:~$ docker ps --format 'table {{.Names}}\t{{.Label "com.docker.compose.project"}}\t{{.Label "com.docker.compose.service"}}' | head
NAMES              COM.DOCKER.COMPOSE.PROJECT   COM.DOCKER.COMPOSE.SERVICE
app-web-1          app                          web
app-db-1           app                          db
payments-web-1     payments                     web

What it means: The first two containers belong to project app. The third belongs to payments. If you see containers you don’t expect under the same project label, you have a collision.

Decision: Identify which repo/automation is also using that project name. Quarantine by choosing a new project name for one of them.

Task 3: List Compose “projects” on the daemon (quick inventory)

cr0x@server:~$ docker compose ls
NAME       STATUS              CONFIG FILES
app        running(2)          /srv/staging/app/docker-compose.yml
payments   running(1)          /srv/payments/docker-compose.yml

What it means: Compose thinks there is a project called app and it associates it with a config file path. If multiple deployments use the same project name, this list becomes misleading or flips between paths.

Decision: If the project shows an unexpected config path, assume a collision and audit recent deploys.

Task 4: Inspect a suspicious container’s labels to find ownership

cr0x@server:~$ docker inspect app-web-1 --format '{{json .Config.Labels}}' | head
{"com.docker.compose.config-hash":"b1b4...","com.docker.compose.container-number":"1","com.docker.compose.oneoff":"False","com.docker.compose.project":"app","com.docker.compose.project.config_files":"docker-compose.yml","com.docker.compose.project.working_dir":"/srv/staging/app","com.docker.compose.service":"web"}

What it means: The container says it was created from /srv/staging/app. If you find containers with the same project label but different working_dir, you have two sources feeding one project.

Decision: Pick one source of truth. Rename one project and redeploy cleanly. Don’t keep “sharing” the project label across repos.

Task 5: Identify networks that are shared (sometimes unintentionally)

cr0x@server:~$ docker network ls --format 'table {{.Name}}\t{{.Driver}}' | grep -E 'app|payments'
NAME              DRIVER
app_default       bridge
payments_default  bridge
shared_frontend   bridge

What it means: app_default is the default network for project app. If you see two projects attached to one network, that might be deliberate—or a leak.

Decision: If you didn’t intentionally create a shared network, don’t attach multiple projects to it. Use distinct networks per project by default.

Task 6: Check which containers are attached to a network

cr0x@server:~$ docker network inspect app_default --format '{{json .Containers}}' | head
{"3c1f...":{"Name":"app-web-1","IPv4Address":"172.20.0.2/16"},"a77b...":{"Name":"app-db-1","IPv4Address":"172.20.0.3/16"}}

What it means: Only app-web-1 and app-db-1 are on app_default. If you saw payments-web-1 here, that would be a cross-project attachment.

Decision: Cross-project attachments demand a security and debugging conversation. If it’s accidental, detach and redeploy with corrected network definitions.

Task 7: Find volumes that look project-scoped but aren’t

cr0x@server:~$ docker volume ls --format 'table {{.Name}}\t{{.Driver}}' | grep -E '^app_|^payments_'
NAME          DRIVER
app_dbdata    local
payments_pg   local

What it means: These are named volumes, likely created by Compose. If two stacks use the same volume name via explicit name:, they will share data.

Decision: If volume sharing isn’t explicitly intended and documented, rename volumes and migrate data. Treat accidental volume sharing as a data incident until proven otherwise.

Task 8: Confirm which containers mount a given volume

cr0x@server:~$ docker ps -a --filter volume=app_dbdata --format 'table {{.Names}}\t{{.Status}}'
NAMES      STATUS
app-db-1   Up 3 hours

What it means: Only app-db-1 uses app_dbdata. If you see multiple stacks’ DB containers using the same volume, you have shared state.

Decision: Stop and assess data integrity. Separate volumes before you do any “cleanup.”

Task 9: Detect orphan containers that Compose might delete

cr0x@server:~$ docker compose -p app ps
NAME       IMAGE          COMMAND                  SERVICE   CREATED        STATUS        PORTS
app-web-1  nginx:1.25     "/docker-entrypoint.…"   web       3 hours ago    Up 3 hours    0.0.0.0:8080->80/tcp
app-db-1   postgres:16    "docker-entrypoint.s…"   db        3 hours ago    Up 3 hours

What it means: Compose lists what it thinks belongs to -p app. If you recently changed services in YAML and now see unexpected containers with the same project label, --remove-orphans could delete something you still need.

Decision: Don’t run --remove-orphans until you confirm the project boundary is correct.

Task 10: Preview what will be created/recreated by a Compose change

cr0x@server:~$ docker compose -p app up -d --no-start
[+] Running 2/2
 ✔ Network app_default  Created
 ✔ Container app-web-1  Created

What it means: --no-start still creates resources but doesn’t start them. It’s a safer way to see whether Compose is about to create objects under a project name you didn’t mean to use.

Decision: If you see resources being created that already exist under another stack’s expectations, abort and fix the project name first.

Task 11: Prove a collision by comparing config hashes across containers

cr0x@server:~$ docker inspect app-web-1 --format '{{.Config.Labels.com.docker.compose.config-hash}}'
b1b4c7f2d4a0...
cr0x@server:~$ docker inspect app-db-1 --format '{{.Config.Labels.com.docker.compose.config-hash}}'
b1b4c7f2d4a0...

What it means: Matching hashes suggest the containers were created from the same resolved Compose config. If within one “project” you see different hashes for what should be the same stack generation, you may have two different Compose configs managing the same project name over time.

Decision: Freeze changes. Decide which config is authoritative and redeploy with a new project name if needed to separate state safely.

Task 12: Check for hardcoded global names that will collide

cr0x@server:~$ grep -R --line-number -E 'container_name:|name:' /srv/staging/app/docker-compose.yml
14:    container_name: postgres
33:  default:
34:    name: shared_frontend

What it means: container_name: postgres is a global container name. The network shared_frontend is explicitly shared across projects (or will be, if another stack uses the same name).

Decision: Remove container_name unless you have a very specific operational requirement. Treat explicit network names as a security boundary decision, not a convenience.

Task 13: Verify what Compose thinks the project name is when a .env file is present

cr0x@server:~$ cat /srv/staging/app/.env
COMPOSE_PROJECT_NAME=app
cr0x@server:~$ docker compose config --format json | head
{
  "name": "app",
  "services": {
...

What it means: The project name is being forced by .env. People forget these files exist, especially during incident response.

Decision: If the value is too generic, change it and redeploy. Also check whether other repos copied the same .env template.

Task 14: Show events during “overwrite” to catch recreation and removal

cr0x@server:~$ docker events --since 10m --filter type=container --filter event=destroy
2026-01-03T10:11:22.123456789Z container destroy 3c1f... (name=app-web-1, image=nginx:1.25)

What it means: You have proof a container was destroyed, when, and under what name. Combine with deploy logs to correlate the responsible Compose run.

Decision: If destruction happened during a deploy on a different repo/host path than expected, you have a project name collision or an operator ran down in the wrong place.

Task 15: Confirm whether “down” will target the right project before running it

cr0x@server:~$ docker compose -p app ps --all
NAME       IMAGE          SERVICE   STATUS
app-web-1  nginx:1.25     web       Up 3 hours
app-db-1   postgres:16    db        Up 3 hours

What it means: This is your pre-flight. If the list includes containers you didn’t mean to manage, down will remove them.

Decision: If anything looks unfamiliar, do not run down. Fix project naming first, or use targeted container operations instead.

Joke #2: Running docker compose down with the wrong project name is like firing the intern because your badge reader broke.

Fast diagnosis playbook

When a stack “overwrites” another, you don’t have time to philosophize about YAML. You want the shortest path to: what changed, what owns it, and how to stop the bleeding.

First: establish the project namespace that is colliding

Run docker compose ls and look for suspiciously generic names (like app, backend, prod).
Run docker ps with label output and confirm which containers share com.docker.compose.project.
Inspect at least one container’s labels for com.docker.compose.project.working_dir. That tells you where it was created from.

Second: identify what’s actually being shared (networks, volumes, ports)

List networks and inspect the network for unexpected containers.
List volumes and find which containers mount them.
Check port bindings on the “overwritten” service: if a port moved, traffic moved.

Third: stop automation and prevent additional reconciliation

Pause CI/CD jobs or scheduled deploy scripts that might keep running Compose.
Do not run down until you can prove the target project boundary is correct.
If you must stabilize service quickly, prefer docker stop/docker start on specific containers while you untangle ownership.

Fourth: recover with a clean, explicit project name

Pick a new unique project name for the stack you’re restoring (team-env-app style).
Deploy it side-by-side with different ports (or behind a proxy switch) and with isolated volumes unless data continuity requires reuse.
Only after recovery, clean up the collided project resources carefully and explicitly.

One quote that belongs on every operations team wall, because it explains why you standardize boring stuff like naming: paraphrased idea from John Allspaw: incidents come from normal work interacting in unexpected ways.

How to prevent project name collisions (hard rules, not vibes)

If you run multiple Compose stacks on the same daemon, you need explicit, enforced names. Not “remember to pass -p.” Enforced. Humans forget. Automation repeats.

Rule 1: Always set a unique project name explicitly

Pick one method and standardize it:

Preferred for automation: always use docker compose -p with a computed name (like payments-staging).
Preferred for developer laptops: top-level name: in the Compose file, or a per-developer .env that includes username in the project name.

What you should avoid: relying on the directory name, especially on shared hosts and CI runners.

Rule 2: Ban `container_name:` unless you have a written justification

It breaks scaling, breaks multi-stack reuse, and encourages manual docker commands that drift state away from Compose.

If you need a stable DNS name for other containers, you already have it: service names on the project network. If you need stable external integration, use a reverse proxy, a stable hostname, or a stable network alias—not a global container name.

Rule 3: Treat explicit network and volume names as shared infrastructure

If you set name: for a network or volume, you’re stepping outside Compose’s per-project namespace. That can be correct. It can also be an accidental multi-tenant bridge.

Make it a policy: explicit names must include environment and ownership, like shared_frontend_prod or payments_pg_prod. “shared” should mean “reviewed,” not “someone typed it once.”

Rule 4: Make “pre-flight” mandatory in deploy scripts

Your wrapper should print the resolved project name and fail fast if it’s not what you expect. You can do this without building a platform:

Resolve config (docker compose config)
Check the resulting name
Check that docker compose -p NAME ps matches expected services (or is empty on first deploy)
Then run up -d

Rule 5: Separate environments by daemon when you can

Yes, you can run prod and staging on the same host. You can also ride a bicycle through a car wash. If you must co-locate, naming discipline becomes non-negotiable, and you should isolate ports, volumes, and networks with intent.

Common mistakes: symptom → root cause → fix

This is the section you’ll wish you’d read before the incident. Each item is specific and points to the actual lever to pull.

1) Symptom: `docker compose up` “recreated” a container from another stack

Root cause: Same project name, same service name. Compose reconciled and replaced the container definition.

Fix: Use unique project names via -p, COMPOSE_PROJECT_NAME, or top-level name:. Redeploy the overwritten stack under a new name.

2) Symptom: Running `docker compose down` removed containers you didn’t intend

Root cause: You ran down with a project name that matched multiple deployments; Compose removed everything labeled with that project.

Fix: Before down, always run docker compose -p NAME ps --all. If the list is wrong, stop and correct the project name.

3) Symptom: A service is reachable from another “unrelated” stack

Root cause: Shared user-defined network due to explicit network name or manual network connects.

Fix: Remove explicit shared network names unless intentionally shared; audit docker network inspect for attachments; redeploy with isolated networks.

4) Symptom: Staging database contains production-looking data

Root cause: Shared named volume caused by explicit volume name: or same project name, leading to same generated volume name.

Fix: Separate volumes per environment. If you must clone data, do it via explicit backup/restore, not accidental volume sharing.

5) Symptom: Compose refuses to start with “Conflict. The container name is already in use”

Root cause: container_name: forces a global name. Another container already uses it.

Fix: Remove container_name:. If you need stable addressing, use service DNS names or a proxy.

6) Symptom: A deploy worked yesterday, fails today on the same host

Root cause: Another team introduced a project name or network name collision; your stack is now sharing namespace or ports.

Fix: Inventory with docker compose ls, check labels, and enforce a naming convention. Add guardrails in CI.

7) Symptom: `--remove-orphans` deleted something “important”

Root cause: Project name boundary wrong; Compose considered the “important” container an orphan in that project.

Fix: Don’t use --remove-orphans on shared hosts unless project naming is enforced and audited. Prefer explicit cleanup after validation.

Checklists / step-by-step plan

Checklist A: Safe standard for every Compose deployment

Choose a project naming scheme: <team>-<env>-<app>. Keep it short, unique, and human-parsable.
Enforce it in automation: deploy scripts always call docker compose -p "$NAME".
Enforce it in repos: add a .env.example that sets COMPOSE_PROJECT_NAME with a safe pattern for local dev (include username).
Ban container_name: by policy unless reviewed.
Audit explicit network/volume names: any name: must be reviewed like infrastructure.
Pre-flight before changes: docker compose -p NAME config and docker compose -p NAME ps must look sane.

Checklist B: Step-by-step recovery after a collision

Stop the churn: pause deploy pipelines and scheduled jobs that might run Compose again.
Identify the collided project name: use labels to confirm which containers share com.docker.compose.project.
Snapshot state if data is involved: if volumes are shared, take a backup before changing anything.
Bring up a clean stack under a new project name: use isolated networks and volumes unless you intentionally reuse data.
Shift traffic: update reverse proxy config or port bindings to route to the restored stack.
Clean up the collided stack carefully: remove only what you can prove is wrong; avoid blind down if ownership is mixed.
Add a guardrail: deploy wrapper that prints resolved project name and fails if it doesn’t match host expectations.

Checklist C: Host hygiene for shared Docker daemons

Inventory projects weekly: docker compose ls and check for generic names.
Inventory dangling networks/volumes: confirm explicit names have owners.
Document shared networks: if you truly need cross-stack communication, treat the shared network as a controlled interface.
Keep environments apart: if possible, separate daemons/hosts for prod vs staging.

FAQ

1) What exactly gets “overwritten” during a project name collision?

Compose doesn’t overwrite YAML. It reconciles Docker objects under the same project label. That can mean containers get recreated with different images/env, networks get shared, and volumes get reused.

2) If I use different Compose files, can I still collide?

Yes. Same project name is enough. Different config files can still generate resources under the same project namespace, especially if service names overlap.

3) Is the directory name always the default project name?

Often, yes, but not always. A .env file, COMPOSE_PROJECT_NAME, or a top-level name: can override it. That’s why you should always check docker compose config before deploying.

4) Should I set project name in `.env` or always pass `-p`?

For CI/CD and production: prefer -p so the deploy system controls it. For developers: .env is fine, but include a username to avoid collisions on shared dev hosts.

5) Why is `container_name` considered harmful?

It forces a global name on the daemon, breaks scaling, and makes stacks less portable. It also encourages manual intervention, which is where “temporary fixes” go to become permanent outages.

6) Can I intentionally share a network or volume between projects?

You can, and sometimes you should (for a shared reverse proxy network, for example). But treat it as an interface contract. Explicitly name it, document it, and review attachments. Don’t do it “because it worked.”

7) How do I tell which repo created a container?

Inspect labels. Look for com.docker.compose.project.working_dir and com.docker.compose.project.config_files. That usually points straight to the path used during creation.

8) Is `docker compose down` safe?

It’s safe when the project name boundary is correct. On shared hosts with sloppy naming, it’s a demolition tool. Always run docker compose -p NAME ps --all first.

9) Does this problem go away if I use Kubernetes/Swarm?

You trade this specific failure mode for different ones. Namespaces in Kubernetes help, but you can still collide with shared volumes, cluster-wide resources, and misconfigured selectors. Discipline doesn’t get deprecated.

Conclusion: next steps you can ship today

Compose project name collisions aren’t a quirky edge case. They’re the predictable result of letting defaults decide your isolation boundaries. The fix is straightforward, but it has to be enforced, not suggested.

Do these next:

Pick a project naming convention that encodes team + environment + app.
Update every deploy command to pass -p explicitly.
Audit Compose files for container_name: and explicit network/volume name:; remove or formalize them.
Add a pre-flight check in automation that prints the resolved project name and refuses to run if it’s generic or unexpected.
Run the inventory commands in this article on your busiest host and look for collisions before they look for you.