Skip to main content
Every env var the FrankenPress platform reads, grouped by component. None are required at the runtime layer — defaults produce a working config. Site-level vars (WP_*, DB_*, the eight *_KEY / *_SALT) are the consuming site’s responsibility.

runtime (Caddy + FrankenPHP + Souin)

The runtime emits Caddy access logs as JSON on stdout (public server only) and PHP errors on stderr. Shipping setup is in Logging.

mu-plugin: S3UploadsBootstrap

When required vars are missing, the bootstrap registers wp_handle_upload_prefilter to refuse uploads with a clear error message rather than silently fall back to local disk.

mu-plugin: SouinInvalidator

If ext-redis isn’t loaded or the connection fails, the invalidator becomes a silent no-op. Errors are logged via error_log.

WordPress site (site-template)

These are read by config/application.php in the site template. None are FrankenPress-specific — they’re standard WordPress config.

mu-plugin: SMTPMailer

When FP_SMTP_HOST is unset, wp_mail() falls through to PHP’s mail() and fails silently because runtime ships no MTA. The chart sets smtp.enabled=true to wire the env above; see Operations → Email for provider recipes.

mu-plugin: SnapshotExporter

Daily wp-cron + admin-button capture-and-upload to a per-tenant S3 snapshot bucket. Drives the prod-side half of fp pull. Dormant when FP_SNAPSHOT_BUCKET is unset — zero overhead on non-opted-in tenants. The chart’s snapshotExport.* values surface map to these env vars (see components/charts). The K8s Secret is typically projected from AWS Secrets Manager via ExternalSecret.

Build args (runtime)

Set at image build time with --build-arg:

Helm values (site chart)

A condensed reference of the most-used values — see charts/charts/site/values.yaml for every annotated parameter.

Password rotation

Two passwords participate in rotation: the WordPress admin password and the database password. They behave differently because of where WordPress reads each one.

Database password

DB_PASSWORD is read from a secretKeyRef by the Deployment, the wpcron CronJob, and the install Job. When the Secret value changes (manual edit, External Secrets Operator sync, sealed-secret rotation, etc.), restart the Deployment and pods pick up the new value. No chart-side reconciliation is required.
Or wire up Stakater Reloader once cluster-wide and skip the manual restart for every Secret rotation on the platform — the database password, WP keys+salts, S3 credentials, and the SMTP token all benefit. Rotating the password on the DB server itself is the DB’s lifecycle (mariadb-operator, RDS rotation, etc.) — the chart consumes whatever’s in the Secret.

WordPress admin password

WordPress stores a hash of the admin password in wp_users, so simply updating the Secret value won’t change the live login. The chart’s sync-admin-credentials initContainer (default on, chart v0.4.0+) reconciles wp_users against the install Secret on every Pod start. Pair it with Reloader and rotation is self-driving:
Set syncAdminCredentials: false to skip the initContainer (e.g. when an external IdP owns the WP admin user, or when you treat wp-admin as the canonical credential store). Full flow, verification, and failure modes are in Admin credential rotation.