Files
Ping/backend/deploy
Admin 7e9e90c3ba Use Ping's own credentials on the shared services
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.
2026-09-24 17:05:24 +02:00
..

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.