Add Docker Compose profiles for dev, full, test and integration

[daveades]

Closes #606

docker-compose.test.yml is absorbed into docker-compose.yml so that docker compose --profile test up works against the default file, which is what the issue asks for. Every service now names a profile, so a bare docker compose up starts nothing and you always say which stack you want.

Command	Starts
docker compose --profile dev up	backend, postgres, redis
docker compose --profile full up	the same, plus the built frontend on :3000
docker compose --profile test up	the API under test on :5001 and its own database
docker compose --profile integration up	a local standalone Stellar network on :8000

Two splits are worth explaining.

The frontend is in full, not dev. The issue asks for dev to be app + postgres + redis, and the Vite build is by far the slowest thing in the file. full is dev plus the frontend, so nobody doing backend work pays for a UI build. The dev services belong to both profiles, so --profile full still resolves frontend's depends_on: backend.

stellar-standalone is in integration, not test. It pulls stellar/quickstart, a multi-gigabyte image used only by the Soroban contract tests under tests/integration/. Putting it in test would drag it into every API test run.

Dev and test use separate databases on separate host ports (5432 and 5433), so both stacks can run at once.

Two things the merge exposed

api-test could never reach its own database. It declared networks: [stellar-test-net] while postgres-test had no networks key and so sat on the default network, making postgres-test:5432 unresolvable. Rendering the old file shows the split:

api-test       -> ['stellar-test-net']
postgres-test  -> ['default']

Both are on one network now, and the custom network is gone since nothing else needed it.

Dockerfile.test could not build. It ran npm ci with only package*.json copied, but postinstall is prisma generate:

prisma/schema.prisma: file not found
npm error command sh -c prisma generate

Copying prisma/ before npm ci fixes it, which is what the main Dockerfile already does for the backend target. EXPOSE also said 5000 while the service runs on 5001.

Both of these had to be fixed for the test profile to be worth anything.

Also updated

tests/integration/{run.sh,deploy.sh,README.md} referenced docker compose -f docker-compose.test.yml up -d stellar-standalone; they now use --profile integration. The .dockerignore comment pointing at the removed file is updated too.

The README gains a "Docker Compose profiles" section with the table above, the both-stacks-at-once command, COMPOSE_PROFILES, and a note that you must pass the same profile to down.

Verification

Docker is not available in my environment, so I validated with the standalone Compose v2 binary, which resolves profiles without a daemon. Every profile renders exactly the intended service set, and nothing renders by default:

default      -> (nothing)
dev          -> backend postgres redis
full         -> backend frontend postgres redis
test         -> api-test postgres-test
integration  -> stellar-standalone

All four profiles together parse clean, and dev + test have no host port collisions.

The npm ci failure and its fix were both reproduced directly, outside Docker, by running the same install against the same package-lock.json with and without prisma/ present.

What I could not verify is the actual image builds and container startup, since that needs a daemon. The layer-ordering fix is confirmed at the npm level only.

Backend suite unchanged: 51 suites, 859 tests. Markdown passes cspell.

[vercel]

@daveades is attempting to deploy a commit to the Abdulazeem's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@daveades Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits