All configuration for the single-server install lives in /opt/3b/.env. The installer writes it for you, but you can edit it directly and re-run sudo bash /opt/3b/setup.sh to apply changes. (On Kubernetes with Helm, the equivalent settings live in your values file — see the Helm values reference.)
Core (required)
Variable | Description |
| Release version to run, e.g. |
| Stable unique identifier for this install. Do not change after first start. |
| Address users open in the browser. |
| Address of the API. On new installs this is the same as the UI URL. |
| Address 3B uses for links it shares externally (webhooks and public links). Its own hostname. |
| Real-time sync (“Zero”) address that keeps the UI live. On new installs this is the same as the UI URL. |
| Parent domain shared by the URLs, for sign-in cookies. No scheme or port. |
|
|
| The signed 3B license token ( |
Each external URL must use http:// or https://. The UI, API, and Zero sync URLs may share a hostname; the public URL needs its own.
Registry
Persisted by bootstrap.sh so a re-run of setup.sh works without re-running the bootstrap.
Variable | Description |
| The registry to pull images from — |
| Your Tines tenant name. |
| Your Tines OCI registry API key. |
TLS (optional)
Variable | Description |
| Path on the server to the full-chain certificate (PEM). |
| Path on the server to the private key (PEM). |
Set both when nginx terminates TLS with a certificate you provide; leave unset when an upstream load balancer handles TLS. When set, all external URLs must use https://. The installer records your interactive choice in NGINX_TLS_MODE so re-runs don’t re-ask. See TLS termination.
Email (optional)
Variable | Description |
| SMTP connection string for outbound email. |
| The “from” address on emails 3B sends. |
Other optional settings
Variable | Description |
| Wildcard domain for public-facing pages, if used. Your certificate must also cover |
| Outbound proxy settings, if your network requires a proxy for internet access. |
| Comma-separated CIDR blocks that workflow code may reach on internal networks (see below). |
| Path to an additional Helm values file merged on top of the generated one, for advanced chart settings. |
ALLOWED_CIDR_BLOCKS and internal networks
Outbound requests from workflow code are blocked from reaching private and internal address ranges by default (an SSRF guard). ALLOWED_CIDR_BLOCKS lists ranges that bypass that block, letting steps and connectors reach internal networks.
Warning: This takes precedence over every block, including loopback, link-local, and cloud metadata (IMDS) — so listing a metadata range, or a broad range that contains one (e.g. 0.0.0.0/0), exposes cloud instance credentials to workflow code. Prefer the tightest range that covers the target.
Examples:
a single internal host: 10.20.30.40/32 one subnet: 10.20.0.0/16 a few subnets: 10.20.0.0/16,192.168.50.0/24 IPv6 unique-local: fd00:1234::/48
Generated secrets
Secrets such as the database password and encryption keys are generated automatically on first install and stored in this same file (and as Kubernetes secrets). Do not edit or delete them, and keep the file secure — it is root-only (chmod 600) by default, and it belongs in your backups.
