Hardening

TLS, headers, reverse proxies, file permissions, dependencies and the production checklist.

Vaultigen supplies the application controls. The host, transport, key files, backups and update process are yours. This page lists what to get right.

TLS and HSTS

Serve Vaultigen only over HTTPS with a current TLS configuration. Redirect HTTP to HTTPS.
HSTS is sent on secure requests and configured with VAULTIGEN_HSTS_MAX_AGE (default one year), VAULTIGEN_HSTS_INCLUDE_SUBDOMAINS and VAULTIGEN_HSTS_PRELOAD. Set the max age to 0 while you are still testing a new host name.

Security headers

Vaultigen sets these on every response:

Header	Value
`Cache-Control`	`no-store, private`
`X-Content-Type-Options`	`nosniff`
`Referrer-Policy`	`no-referrer`
`X-Frame-Options`	`DENY`
`Content-Security-Policy`	`frame-ancestors 'none'; base-uri 'self'; form-action 'self'; object-src 'none'`
`Permissions-Policy`	`camera=(), geolocation=(), microphone=(), payment=()`

If you add a stricter policy at the proxy, test the admin panel and the sign-in flow carefully first.

Reverse proxies and host names

Behind a TLS-terminating proxy or load balancer, list the proxy addresses so Vaultigen sees the real scheme and client IP:

VAULTIGEN_TRUSTED_PROXIES=10.0.0.0/8,192.168.1.10

Use * only when you genuinely cannot know the proxy addresses; trusting a proxy you do not control lets clients forge their address.

If your web server does not restrict the Host header, restrict it in Vaultigen:

VAULTIGEN_TRUSTED_HOSTS=^vault\.example\.com$

Never log request bodies in proxies, WAFs, APM, tracing or error reporting.

Files and permissions

For a manual installation:

Run PHP as a dedicated, unprivileged user. It needs write access to storage/ and bootstrap/cache/ only.
Only public/ may be served. storage/, .env and the key files must never be reachable over HTTP.
Key files in storage/app/private are created with mode 0600. Keep it that way.
Use a private temporary directory for PHP uploads and clean it regularly.

Docker Compose specifics

The Compose stack applies most of this page for you: HTTPS with automatic certificates and an HTTP redirect, production settings, secure cookies, non-root processes (UID 10001), dropped Linux capabilities, no-new-privileges, no Docker socket in any container, an immutable application directory and a database without a published port. Your part:

Keep .env and the installation directory readable only by administrators (umask 077 before download). Anyone with Docker access on the host is effectively root and can read every key: limit membership of the docker group.
Never publish the internal ports 8081 (health check) or 5432 (database). With the proxy override, Vaultigen listens on 127.0.0.1 only.
Do not mount data/keys/ or .env into other containers, and do not change the owners of data/ and backups/.
Pin VAULTIGEN_IMAGE_TAG to an exact release. Patch the host and Docker Engine yourself; security fixes for PHP, the web server and the database tools arrive as new Vaultigen releases.
The archive from Copy the whole installation contains keys and data together. Encrypt it before it leaves the server.

SQLite specifics

On SQLite everything lives in one file next to the application, so file permissions and host hardening carry more weight. Run one queue worker, keep the file on a local disk, and run backups and rotations off-hours.

Dependencies and patching

Manual installations: install with the committed lockfiles (composer install --no-dev, npm ci). Docker images are built from them.
Patch PHP, the database, the web server and the OS under a documented policy. On Docker Compose, update the image and patch the host and Docker Engine.
Follow the changelog for security releases.