Coming soon. Depotex is in active development, so features and these docs may still change.

Production checklist

Hardening and go-live checklist for a production Depotex installation

Work through this list before people and CI depend on an installation, and again after each major change. Each item links to where it's configured.

1. Secrets and keys

  • CONFIG_ENCRYPTION_KEY is long and random, the same on every server, kept in a secret store, and backed up separately from the database backups it unlocks. Losing it makes every stored credential and every backup unreadable. See Environment variables.
  • The setup key is no longer delivered to running servers (setup.mode: none in Helm; no SETUP_TOKEN elsewhere), and the setup file was deleted.
  • RECOVERY_TOKEN is kept in your secret store; the recovery page shows diagnostics only to its holder.
  • Encrypt backups with public keys (age), and keep the private key offline.
  • PAGINATION_CURSOR_SECRET is set, the same on every server.

2. Network and TLS

  • Only the reverse proxy is reachable from users; the web app's port (3000) and the server's port (8080) are not.
  • TLS everywhere: at the proxy, to PostgreSQL (sslmode=verify-full), to Redis (rediss://), to object storage.
  • TRUSTED_PROXIES lists exactly your proxies, and FRONTEND_BEHIND_PROXY=true is set only with a proxy that overwrites the forwarded headers. See Behind a proxy.
  • /api/ws routes to the server, so the system check has no Live updates warning.
  • METRICS_ADDR is bound to a private interface, or metrics use METRICS_TOKEN. See Monitoring.
  • On Kubernetes, network policies stay enabled; restrict the server's egress to what it needs (networkPolicy.backendInternetEgress: false plus extraEgress).
  • Outbound calls go through your proxy (Settings → Repositories), and webhooks to private addresses stay off (AUTOMATION_WEBHOOK_ALLOW_PRIVATE=false).

3. Browser security

  • Set CSP_ENFORCE=true on the web app once its log has no [csp] lines for a while.
  • Package links use only known addresses: list them under Settings → General and turn on Package links use only these addresses.

4. Identity and access

  • People sign in through your identity provider: single sign-on (Enterprise) with Require single sign-on, or a synchronized directory. Multi-factor authentication is enforced there.
  • Keep at least two super admins, and a documented break-glass procedure (SSO_ENFORCEMENT_OVERRIDE on one server) for when the identity provider is down.
  • Anonymous access is off unless you mean to serve public packages (Settings → Security → Anonymous access).
  • Sessions: lifetimes and the number of sessions per person fit your policy (Settings → Security → Sessions); AUTH_PASSWORD_MIN_LENGTH is 12 or more.
  • CAPTCHA after failed sign-ins is on if Depotex is reachable from the internet.
  • CI uses workload identity or service accounts with narrowly scoped, expiring tokens; API tokens have IP allowlists where possible (Pro).
  • Token lifetime and blocked permissions are enforced by policies (Token lifetime templates).
  • Space roles follow least privilege: Developer to publish, Maintainer to manage repositories.

5. Supply chain

  • Proxy checksums are strict (Settings → Security → Proxy checksums).
  • Quarantine rules hold new versions from public registries for review or an age (Enterprise); the block list covers known-bad versions. See Quarantine, Block list.
  • Vulnerability data is current (Settings → Vulnerability data), and alerts reach the people who act on them.
  • Plugins: PLUGIN_SIGNING_REQUIRED=true; only plugins you trust are installed, with only the permissions they need.
  • Integrity checks run on schedule (Settings → Integrity).

6. Resilience

  • Backups run daily to a target separate from the installation's storage, and a test restore has succeeded (Enterprise runs one weekly).
  • The artifact storage has its own protection: versioning or replication on S3, snapshots on disk.
  • PostgreSQL has point-in-time recovery from your platform.
  • For a cluster: three or more servers, replicated PostgreSQL and Redis, pod disruption budgets on.
  • The disaster recovery steps were rehearsed on a scratch installation.

7. Monitoring and audit

  • The system check runs (Pro), and its alerts reach on-call through automation (webhook or email).
  • Prometheus scrapes every server; alert on rate-limit refusals and Redis health. See Monitoring.
  • Audit log retention (AUDIT_LOG_RETENTION_DAYS) meets your compliance needs; export to your SIEM if you keep it longer.
  • Log files are collected centrally, with redaction on (LOG_REDACT_ENABLED=true).

8. Licensing and updates