Fix Docker container name collisions for multi-project machines

[Copilot]

When multiple projects are based on labzero-project on the same machine, hard-coded container_name values cause Docker to reuse the same containers across projects — silently sharing database state.

Changes

docker-compose.yml

• Removed all container_name: directives
• Added top-level name: ${COMPOSE_PROJECT_NAME:-myapp} so Docker Compose namespaces containers per project (e.g. shopify-db-1, shopify-redis-1)

.env.example

• Added COMPOSE_PROJECT_NAME=myapp — Docker Compose reads this from .env automatically

README.md

• Removed rename.sh references (project is moving to the Drupal model — no renaming)
• Added instruction to set COMPOSE_PROJECT_NAME in .env before make up
• Updated Customize section to reflect the new approach: add code in src/myapp/ rather than renaming

BACKGROUND.md

• Updated the "Known Issue: Docker Container Name Collisions" resolution to describe the manual .env workflow instead of the now-deprecated rename.sh path

# .env — set this to a unique name per project on the same machine
COMPOSE_PROJECT_NAME=shopify

Original prompt

write BACKGROUND.md, this project initially a project template based on cookie cutter library. Maintaining and developing templates is hard, every changes need rebuild, no continuation, once project generated, no longer received updates to the template. Also depending on cookiecutter user has to install it first. Then move to simple rename.sh bash script to rename all key files and naming as a way to create our own project. no dependencies but still no continuation. as workaround many features built into separate app like labzero and django-umin, added as git submodule in ext-src/. But some code still need to be in labzero-project, such as docker-compose, Procfile, AGENTS.md etc. All this still suffer from discontinuation once the project is generated. Then I remembered back in the old days when using Drupal as framework, we checkout Drupal project but develop our own code as extensions in sub dir. not much changes to Drupal structure so we can still git pull to get updates from Drupal.

So I think labzero would go into that direction. User git clone labzero to get the project structure that already include admin dashboard, authentication, user management etc. Then they add their own code in src/appname, alongside src/labzero. so it just a fork of labzero project with potential to sync with future changes.

---

⚡ Quickly spin up Copilot coding agent tasks from anywhere on your macOS or Windows machine with Raycast.