docker compose in monrepo

[sevenzing]

Problem

The root docker-compose.yml currently bundles all services together — including devnet — which conflates several distinct use cases:

1. End users who want to run ENSNode against mainnet or a public testnet (Sepolia, etc.)
2. Developers who want a local devnet for development work
3. CI / integration tests that need devnet + postgres as infrastructure

The devnet service is currently included to pin the version used in the monorepo and to support the orchestrate.ts integration-test script, but this is not obvious to users and creates confusion about what the "default" compose setup is supposed to do.

Proposed Solution

Split docker-compose.yml into purpose-specific files under a docker/ directory:

• docker/docker-compose.yml -- Base ENSNode stack (ensindexer, ensapi, ensrainbow, ensadmin, postgres) — no devnet, targets mainnet by default
• docker/docker-compose.devnet.yml -- Extends base compose, adds devnet service and overrides RPC URLs for local development
• docker/docker-compose.sepolia.yml -- Extends base compose, overrides RPC/config for Sepolia testnet
• docker/docker-compose.cicd-tests.yml -- Minimal compose for CI (devnet + postgres only), used by orchestrate.ts

Docker Compose's extends feature can be used so devnet/testnet variants don't duplicate the base service definitions.

Benefits

• A user running docker compose up gets a clean mainnet-targeted stack with no surprise devnet process
• Developers can still do docker compose -f docker/docker-compose.devnet.yml up devnet for a quick local devnet
• CI integration tests get their own minimal compose that doesn't pull in unneeded services
• The version pin for devnet is preserved but scoped to files where it's relevant

Cons

we lose option to make docker compose up -d in monopero. maybe solve this via symlink (/docker/docker-compose.yaml -> /docker-compose.yaml ?

Context

Raised during review of the REST API tests PR: comment

[coderabbitai]

🔗 Related PRs

#1729 - ENSApi Integration Tests in CI [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[sevenzing]

#1873 (comment)

shrugs
we previously had the build param configured but removed it for some reason. but i can't think of a reason to avoid it now
BUT we should update the docker:build:* scripts in package.json to be docker compose build * instead of a direct docker build, to ensure that there's a single path