Getting started

Test environment Live

The staging variant is a real deployment with its own database, Redis and Kafka listeners — not a mocked sandbox. You test against the same reconciliation behaviour you will run in production.

What staging requires

The docker-compose.staging.yml overlay requires its own settings so staging can never collide with production state:

POSTGRES_USER, POSTGRES_PASSWORD — staging-only credentials
STAGING_POSTGRES_DB — a separate database name
STAGING_KAFKA_ADVERTISED_LISTENERS — separate broker identity

Configuration comes from the repository-root .env, which is git-ignored. Compose has no top-level env_file; the launcher passes --env-file for interpolation and per-service env files for container variables.

Validate without leaking secrets

SHELLconfigure.py

python infra/configure.py --env-file .env.staging compose -- \
  -f infra/docker/docker-compose.staging.yml config --quiet

--quiet validates the merged configuration and prints nothing. Plain config without it can render resolved credentials into your terminal — avoid that.

Bring it up

python infra/configure.py --env-file .env.staging compose -- \
  -f infra/docker/docker-compose.staging.yml up -d --build

Then confirm health as in the quickstart, against the staging value of PESAGUARD_API_URL.

Changing init variables does not migrate state

Changing Postgres initialization variables does not rename existing databases or rotate passwords in existing volumes. Treat credential changes as deliberate operations with a recovery path.

Next: Production checklist and the full environment variables reference.