Skip to content

fix(docker): bind compose Postgres and Redis to loopback - #688

Open
CaptainAni187 wants to merge 1 commit into
truefoundry:mainfrom
CaptainAni187:fix-compose-bind-datastores-to-loopback
Open

fix(docker): bind compose Postgres and Redis to loopback#688
CaptainAni187 wants to merge 1 commit into
truefoundry:mainfrom
CaptainAni187:fix-compose-bind-datastores-to-loopback

Conversation

@CaptainAni187

@CaptainAni187 CaptainAni187 commented Sep 10, 2026

Copy link
Copy Markdown

Summary

Both compose stacks publish Postgres and Redis on all interfaces, and Redis runs with no password. The comment above it notes it carries executor peering, so on a shared network anyone can reach live orchestration traffic unauthenticated and the database port is open too. That also cuts against the project's own posture, where HOST= defaults to localhost and the standalone stack is documented as local-only.

Closes #421

Changes

  • Publish Postgres and Redis on 127.0.0.1 in docker-compose.yml and docker-compose.dev.yml
  • Host ports (5433/6380 vs 5432/6379) are unchanged, so the two stacks still run side by side

Left Redis auth out deliberately — the issue offers it as an "and/or", and --requirepass pulls in REDIS_PASSWORD plumbing across .env.example and the in-network REDIS_URL. Loopback binding closes the reachability on its own. Happy to follow up with the password if you want it.

How was this tested?

docker compose config on both files, which resolves to:

docker-compose.yml       postgres 127.0.0.1:5433->5432   redis 127.0.0.1:6380->6379
docker-compose.dev.yml   postgres 127.0.0.1:5432->5432   redis 127.0.0.1:6379->6379

Checklist

  • I have read the contributing guidelines
  • format:check passes on both files
  • Tests added/updated — compose-only change
  • No hand-edits to generated code
  • Docs / .env.example — not applicable

No changeset, per AGENTS.md: docker-compose changes don't need one. On process: CONTRIBUTING asks for approval first, and all six help wanted issues are assigned or already have PRs. Close this if you'd rather it went through the queue.

Both compose stacks published their datastores on all interfaces, and Redis
runs with no password while carrying executor peering. On any shared network
that leaves an unauthenticated Redis and a database port reachable from other
machines, which contradicts the project's own posture that the standalone
stack is for local use.

Publish both on 127.0.0.1 in each file, keeping the deliberately different
host ports so the two stacks still run side by side.

Fixes truefoundry#421
@changeset-bot

changeset-bot Bot commented Sep 10, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: f851116

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

docker-compose publishes Postgres and a passwordless Redis on 0.0.0.0 — peering/DB reachable from the LAN by default

1 participant