Files
Inboxintel/docker-compose.staging.yml
T
cesnimda 3f8b5c6ea4
CI / backend (pull_request) Successful in 1m2s
CI / frontend (pull_request) Successful in 21s
Security / secrets (pull_request) Successful in 6s
Security / dependencies (pull_request) Successful in 1m4s
fix(staging): robust env write + stop double-binding prod ports
Two fixes to the auto-deploy path found on the first host-mode run:
- Write deploy/.env.staging line-by-line instead of a here-string, so the step
  can't be broken by how act_runner indents/wraps the PowerShell script (the
  here-string terminator must be col 0; the runner's wrapping broke it, leaving
  POSTGRES_PASSWORD blank so postgres/api failed while frontend came up).
- Tag the staging 'ports' lists with !override so the overlay REPLACES the base
  ports instead of merging — staging no longer also binds prod's 8080/8081.
Verified locally: compose config shows only 18080/18081/15432.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-01 12:44:14 +02:00

47 lines
1.7 KiB
YAML

# Staging overlay for InboxIntel.
#
# The base docker-compose.yml IS the production definition (Linux containers,
# ASPNETCORE_ENVIRONMENT=Production). This overlay layers a *staging* variant on
# top of it so you can run a production-shaped stack locally on Windows WITHOUT
# clobbering a real production deployment's data, ports, or volumes.
#
# It differs from prod only in the ways staging is meant to differ:
# - the dev/test banner is on (App__DevMode=true)
# - the initial Gmail sync is capped so a big mailbox doesn't take forever
# - ports are shifted into the 18xxx range so staging can run alongside prod
# - a distinct project name gives it its own isolated pgdata + keys volumes
#
# Run it with the -p (project name) flag so volumes/networks are namespaced:
#
# docker compose -p inboxintel-staging \
# --env-file deploy/.env.staging \
# -f docker-compose.yml -f docker-compose.staging.yml up --build -d
#
# (deploy/up.ps1 -Staging / up.sh --staging wrap this for you.)
services:
postgres:
# !override replaces the base port list instead of merging with it, so staging
# binds ONLY its shifted 18xxx/15432 ports and never squats on prod's 8080/8081.
ports: !override
- "127.0.0.1:15432:5432"
api:
environment:
# Same Production runtime as prod (real config binding, real build), but
# flagged as a non-production instance so the UI shows the staging banner
# and the first sync is bounded.
App__DevMode: "true"
GmailSync__MaxMessages: ${MAX_MESSAGES:-2000}
Cors__Origins__0: ${FRONTEND_ORIGIN:-http://localhost:18081}
ports: !override
- "127.0.0.1:18080:8080"
frontend:
ports: !override
- "18081:80"
nginx:
ports: !override
- "18000:80"