Pull request overview

This PR removes explicit container names and network definitions from the docker-compose.yml file to enable running multiple MemMachine stacks simultaneously on the same machine. Previously, explicit container names (memmachine-postgres, memmachine-neo4j, memmachine-app) and a named network (memmachine-network) prevented users from starting multiple instances, as Docker would report name conflicts. The changes align with Docker Compose best practices by relying on automatic container naming and network creation.

Changes:

• Removed explicit container_name directives from all services in docker-compose.yml
• Removed explicit network definitions from docker-compose.yml (Docker Compose will automatically create an isolated network per stack)
• Updated memmachine-compose.sh to use docker-compose exec with service names instead of docker exec with container names

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

This is a good proposal, though it's a less common use case.

This cleanly supports multiple deployments on the same host. Without hard-coded names, we can run: memmachine-prod and memmachine-canary, or memmachine-staging and memmachine-prod simultaneously using Compose project names (-p) and/or different directories.

By default, the project name is derived from the directory name you run Compose in (unless overridden). You can override it with:

• docker compose -p <project> …
• COMPOSE_PROJECT_NAME=<project>
• A .env value for COMPOSE_PROJECT_NAME.

Default container & network names

Without a fixed container_name:, Compose names containers like:

• <project>-postgres-1
• <project>-neo4j-1
• <project>-memmachine-1

When the service is scaled, the suffix increments (…-2, …-3, etc.).

Because the explicit networks: block is removed, Compose will create a single default bridge network:

• <project>_default

All services are automatically attached to this network.

The compose file declares named volumes (e.g., postgres_data, neo4j_data, etc.). When they don’t have an explicit name: override, Compose will scope them to the project automatically:

• <project>_postgres_data
• <project>_neo4j_data
• <project>_neo4j_logs
• <project>_memmachine_data
• <project>_memmachine_logs

Challenges

With this approach, we need to find a way to ensure the service ports don't cause conflicts, which they will in this PR.

Docker Compose only auto-assigns a host port if you omit the host port and publish container ports like this:

ports: ["5432"] (instead of "5432:5432")

Then Docker picks an ephemeral available host port (random-ish), which is:

• not predictable,
• not “instance 2 = base+1”,
• and harder for scripts/docs unless you query it (docker compose port ).

If we want predictable A/B stacks (8080 and 8081, 5432 and 5433, etc.), Compose won’t do that for us. If predictable increments are desired, they must be handled by memmachine-compose.sh (or by user-provided .env files).

1. User supplies ports per instance (simplest, most transparent)

   • stack A: defaults
   • stack B: POSTGRES_PORT=5433 MEMORY_SERVER_PORT=8081 ...

2. Script computes ports from an “instance number”

3. Use random ephemeral ports and print them. This is viable, but less friendly because every run can differ; you must query and display the assigned ports.

TODO

Here are some ideas to further improve this PR

• Add explicit Compose project naming support to memmachine-compose.sh

  e.g., support --project <project_name>, -p <project_name>, or honoring COMPOSE_PROJECT_NAME (less desirable) so developers/ops can run multiple stacks without relying on “directory name” defaults.

• Figure out a solution (default and user selectable) for assigning port numbers to the services.