Infrastructure now gives each project its own Postgres role, S3 identity limited to its bucket and a Zitadel service account that owns only its project, instead of handing out the admin accounts. - Postgres and S3 settings default to Ping's own (ping). - zitadel-init mounts ZITADEL_PAT_DIR (Infrastructure's zitadel/.output/ping), waits for that PAT and uses it. It no longer creates the Zitadel project, which that account can't do: Infrastructure does.
Ping deploy
Reuses the Zitadel and SeaweedFS instances already running in the separate
Infrastructure repository, instead of starting new ones. That stack must be
up first (see its own README for the exact command).
cp deploy/.env.example deploy/.env
# edit deploy/.env if your Infrastructure checkout isn't where
# ZITADEL_PAT_DIR assumes, or if its PING_* credentials differ from the
# defaults
docker compose -f deploy/compose.yml -f deploy/compose.dev.yml up -d
This starts LiveKit and the one-shot jobs (waiting for Postgres, EF Core
migrations, the Zitadel project for Ping, the ping-storage S3 bucket). The
usual dev loop runs the API and frontend from the IDE against these.
To also build and run the API/frontend in Docker instead:
docker compose -f deploy/compose.yml -f deploy/compose.dev.yml --profile apps up -d --build
By then zitadel-init has already written AUTH_CLIENT_ID / WEB_CLIENT_ID
into deploy/.env.
Ports (dev): API 5211, web 3100, LiveKit 7880 (signaling), 7881 (RTC
TCP) and 50000-50100/udp (media). Postgres, Zitadel and the SeaweedFS S3 API
come from Infrastructure's own stack. See its README for that port table.