Skip to main content

Secrets

Secrets are referenced, never stored: pagifier.yaml names where a secret lives; the platform materializes it into the pod. Secret values never pass through Pagifier's API, database, or logs.

Environment variables from a secret manager​

secrets:
  provider: aws            # kubernetes | aws | vault | external-secrets
  keys:
    DATABASE_URL: prod/api/database-url
    JWT_SECRET: prod/api/jwt-secret

For every provider except kubernetes, Pagifier renders an ExternalSecret (External Secrets Operator) that materializes the app's Kubernetes Secret and keeps it refreshed:

  • storeRef names the ClusterSecretStore to read from; it defaults to pagifier-<provider>, provisioned by the platform team.
  • refreshInterval controls rotation pickup (default 1h). Rotated values reach pods without a redeploy.

The Deployment references the resulting Secret by key, so each keys entry becomes an environment variable.

With provider: kubernetes, no ExternalSecret is rendered — the Secret named <app>-secrets is expected to exist in the namespace already.

Secret files​

Mount a secret as a file instead of an environment variable:

secretFiles:
  firebase.json:
    source: vault://secret/firebase
    mountPath: /app/firebase.json

Secret files project through the same ExternalSecret and mount read-only at their mountPath.

Basic-auth users​

authentication: basic protects the app with an htpasswd file from a Kubernetes Secret you control:

authentication:
  enabled: true
  type: basic
  usersSecret: admin-basic-auth   # secret with an htpasswd key

What the platform guarantees​

  • Pods run with no service-account token and a read-only root filesystem; secrets are the only sensitive material inside.
  • Secret names and key mappings appear in the resolved config snapshot; secret values never do.
  • Rotation is pull-based via the ExternalSecret refresh interval — no Pagifier involvement in the rotation path.