Self-hosted deployment
A summary of the self-hosted form factor, service topology, and operational discipline.
PandaAuth is a self-hosted product: several services are deployed as containers, with a host-level Caddy handling same-domain routing and TLS termination. This page describes the deployment topology and the operational discipline; the concrete orchestration and go-live checklists are deployer materials provided during integration talks.
Architecture and routing
| Path | Service | Port |
|---|---|---|
/connect/* /account/* /.well-known/* /healthz |
IdP (panda-auth-server) | 127.0.0.1:9004 |
/ /status /docs/* etc. |
Product site (panda-auth-website) | 127.0.0.1:9005 |
/admin/* |
Admin console (panda-auth-admin) | 127.0.0.1:9006 |
/me/* |
Account center (panda-auth-me) | 127.0.0.1:9007 |
Containers always use host networking with loopback binding; the management and data planes expose no extra ports to the public internet. Public traffic all goes through the Caddy reverse proxy, with TLS certificates issued and renewed automatically.
Operational discipline
- Releases: single services are rebuilt individually, without side effects on each other; image versions map one-to-one to source commits, and when the version anchor is missing the orchestration fails closed instead of silently running an old version; failed health checks trigger an automatic rollback.
- Database migrations: the long-running service account has no DDL privileges; schema changes run through a one-off migration job (a separate least-privilege account).
- Backups: before any migration or release, the database is backed up and the backup verified as restorable; a release rollback reverts only the application images, with the backup as the last line of defense for data — back up first is therefore a discipline, not a suggestion.
- Secrets: database passwords, the initial administrator password, and client secrets exist only in protected local files on the deployer’s servers; they never enter code repositories or container images.