Configuration reference
The environment variables an operator sets to configure Bonita Process Designer, with their purpose, defaults, and security notes.
Bonita Process Designer is configured through environment variables, set either in your deployment’s environment, in the Docker Compose .env file, or in the config.env file of the standalone distribution. This page lists the variables you are most likely to set, then explains the CORS and TLS security settings in more detail.
|
Only |
Environment variable reference
| Variable | Purpose | Default |
|---|---|---|
|
JDBC URL of the PostgreSQL instance, in the form |
(none) |
|
PostgreSQL user. Required. |
(none) |
|
PostgreSQL password. Required. |
(none) |
|
Front-end HTTP port (the editor UI). |
|
|
Back-end API port. The same value must be visible to both the front-end and back-end processes. |
|
|
Comma-separated list of exact origins allowed to call the API. Overrides the automatic same-host derivation. Wildcards are not supported. See CORS security. |
auto-derived from the request host on port 8080 |
|
Set to |
|
|
Proxy URL for outbound HTTP traffic (license validation, AI generation) on hosts without direct internet access. |
(none) |
|
Proxy URL for outbound HTTPS traffic. |
(none) |
|
Comma-separated hosts that bypass the proxy (for example |
(none) |
|
Authentication mode: |
|
|
The standalone distribution accepts the optional |
AI configuration
AI diagram generation is configured by an administrator in the application, not through environment variables. After registration, an Admin enters one or more LLM provider keys under Admin → Settings. Bonita Process Designer does not store these provider keys in its own database — it persists only a per-provider "configured" flag so the admin UI can show which providers have a key. Use a dedicated, scoped key per provider and rotate keys periodically.
|
Set spend caps and usage limits in each provider’s own dashboard. The application’s per-group AI quota is a complementary control, not a substitute for a provider-side spend cap. |
Secrets and the encryption key
There is no shared session-signing secret to configure on Bonita Process Designer. Session identifiers are random and stored server-side in PostgreSQL, so the security of session data depends on protecting the database and serving over HTTPS — not on a secret you set.
Likewise, LLM provider keys are never persisted locally (see AI configuration), so there is no application-level key-encryption secret to manage. Keep your PostgreSQL credentials strong and unique, and keep the database on a private network segment reachable only by the back-end.
CORS security
By default the back-end derives the allowed origin from the request host on port 8080, so a single-host deployment needs no CORS configuration. For any multi-host, reverse-proxy, or custom-domain deployment, set CORS_ORIGIN to the exact front-end origins:
# Single explicit origin
CORS_ORIGIN=http://custom-domain.com:8080
# Multiple origins (comma-separated)
CORS_ORIGIN=http://192.168.1.100:8080,http://app.example.com:8080
|
Never use a wildcard origin with credentials. Wildcard CORS is a CSRF vector and is intentionally unsupported. Always list exact origins. |
TLS hardening
Bonita Process Designer serves HTTP; terminate TLS in front of it with a reverse proxy (such as nginx, Traefik, or Caddy) or a load balancer rather than exposing the application directly. When served over HTTPS:
-
Set
USE_HTTPS=trueso the session cookie is issued with theSecureflag. Enabling HTTPS also sets the cookie attributeSameSite=None(in addition toSecure), which is required for cross-host HTTPS access. Leaving itfalsebehind HTTPS would emit a non-Secure cookie. -
Forward
X-Forwarded-ProtoandX-Forwarded-Hostfrom the proxy so origin derivation and the Secure flag behave correctly.
USE_HTTPS=true
For the full operator hardening checklist — TLS, CORS, account and database hardening, proxy configuration, and Bonita Runtime mode — see First-time setup and review the deployment-mode guidance in Run with Bonita Runtime.