Configuration

Paprika is configured entirely through environment variables — there is no config file format to learn. Both install scripts write these into a .env file next to the application (Docker: alongside compose.yml; standalone: in the install directory), which is read by the systemd unit or the container at startup.

Not every variable is filled in automatically, though. The install scripts generate the internal signing secrets for you, but a few values are either fixed defaults, environment-specific, or intentionally left for you to set — see the Auto-generated column below.

Variable	Description	Auto-generated
APPLICATION_MODE	Set to prod in production, dev for local development.	No — Docker and standalone both set this to prod by default.
APPLICATION_SECRET	64-character secret for internal signing.	Yes, by both install scripts.
CONNECTOR_HTTP_HOST	Bind address. Use 0.0.0.0 to listen on all interfaces, or 127.0.0.1 to only accept connections from a local reverse proxy.	No. Both install methods default to 127.0.0.1, so Paprika only accepts connections from the local machine out of the box. Set it to 0.0.0.0 if Paprika needs to be reachable directly from the network rather than through a local reverse proxy.
CONNECTOR_HTTP_PORT	HTTP port (default 8080).	No — preset default. For Docker, change the externally exposed port via HOST_PORT instead.
TOKEN_SECRET	64-character secret for JWT encryption.	Yes, by both install scripts.
TOKEN_KEY	64-character key for JWT signing.	Yes, by both install scripts.
SESSION_COOKIE_SECRET	64-character secret for session cookies.	Yes, by both install scripts.
SESSION_COOKIE_KEY	64-character key for session cookies.	Yes, by both install scripts.
FLASH_COOKIE_SECRET	64-character secret for flash cookies.	Yes, by both install scripts.
FLASH_COOKIE_KEY	64-character key for flash cookies.	Yes, by both install scripts.
AUTHENTICATION_COOKIE_SECRET	64-character secret for admin auth cookies.	Yes, by both install scripts.
AUTHENTICATION_COOKIE_KEY	64-character key for admin auth cookies.	Yes, by both install scripts.
PAPRIKA_STORAGE	Absolute path to the file storage directory. Must be absolute in production — Paprika refuses to start on a relative path, and on a directory it cannot create or write to.	No — preset by the installer to a sensible path (storage/ under the install directory); only change it if you know you need a different location. If you do, also adjust ReadWritePaths in the systemd unit (standalone) or the volume mount (Docker).
PAPRIKA_LOG_PATH	Directory for the rolling log files. Relative paths resolve against the working directory, which systemd sets to the install directory.	No — preset by the standalone installer to logs/ under the install directory. If you change it, also adjust ReadWritePaths in the systemd unit. Docker leaves it unset: the container logs to stdout and to /app/logs inside the container.
PERSISTENCE_MONGO_HOST	MongoDB hostname.	Docker: preset to the bundled mongodb container. Standalone: no — left as CHANGE_ME, since you bring your own instance.
PERSISTENCE_MONGO_PORT	MongoDB port (default 27017).	Docker: preset. Standalone: no — left as CHANGE_ME.
PERSISTENCE_MONGO_USERNAME	MongoDB username.	Docker: yes, a fixed paprika username is set for a scoped application user — not the MongoDB root account. Standalone: no — left as CHANGE_ME, you must provide credentials for your own instance.
PERSISTENCE_MONGO_PASSWORD	MongoDB password, as it is — not percent-encoded. See Standalone → MongoDB setup.	Docker: yes, a random password is generated for that same scoped application user. Standalone: no — left as CHANGE_ME.
SMTP_HOST	SMTP host for tenant-user recovery emails. Leave empty to disable sending.	No, if applicable — never auto-generated by either installer. Left commented out; SMTP is entirely optional and only needed if you enable password reset or email verification for a tenant.
SMTP_PORT	SMTP port (e.g. 587 or 465).	No, if applicable — same as above.
SMTP_USERNAME	SMTP username (if the server requires auth).	No, if applicable — same as above.
SMTP_PASSWORD	SMTP password (if the server requires auth).	No, if applicable — same as above.
SMTP_AUTHENTICATION	true when the SMTP server requires authentication.	No, if applicable — same as above.
SMTP_PROTOCOL	smtp or smtps.	No, if applicable — same as above.
SMTP_FROM	From address for outgoing emails.	No, if applicable — same as above.
SMTP_FROM_NAME	Sender display name (defaults to Paprika).	No, if applicable — same as above.

What gets auto-generated, and what doesn't

Both install scripts generate the nine internal signing secrets and keys above (APPLICATION_SECRET through AUTHENTICATION_COOKIE_KEY) with openssl rand -hex 32 — 64 hex characters each. These protect JWTs, session cookies, flash cookies, and admin authentication cookies, and there's no reason to ever set them by hand.

Everything else depends on the install method:

• Docker generates two separate MongoDB credentials: a root password (MONGO_ROOT_USERNAME/MONGO_ROOT_PASSWORD) that bootstraps the mongodb container and never leaves it, and the PERSISTENCE_MONGO_USERNAME/PERSISTENCE_MONGO_PASSWORD pair the paprika container actually authenticates with — a scoped user (readWriteAnyDatabase + dbAdminAnyDatabase, created by mongo-init.js on first start) rather than the root account. There's nothing MongoDB-related left for you to configure.
• Standalone does not touch MongoDB configuration at all — the installer pauses and asks you to fill in PERSISTENCE_MONGO_HOST, PERSISTENCE_MONGO_PORT, PERSISTENCE_MONGO_USERNAME, and PERSISTENCE_MONGO_PASSWORD for your own instance before it will start the service. See Standalone → MongoDB setup for the role this user needs.
• SMTP is never generated by either installer, on any install method. It's commented out by default and stays that way until you opt in — SMTP is only needed if a tenant has password reset or email verification enabled, and most tenants won't need either right away.

Applying changes

Both install methods read .env at process startup, not continuously. After editing it:

# Docker
docker compose up -d

# Standalone
systemctl restart paprika

Do not reuse secrets across separate Paprika instances — each installation should have its own independently generated set.