Environment variable reference

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
`VERSION`	Requested release version, e.g. `v2.0.0`.
`STACK_NAME`	Stable unique identifier for this install. Do not change after first start.
`EXTERNAL_UI_URL`	Address users open in the browser. The app hostname.
`EXTERNAL_API_URL`	Copied from `EXTERNAL_UI_URL` when unset. The API is served by path on the app hostname.
`EXTERNAL_EDGE_URL`	Edge address 3B uses for links it shares externally (webhooks and edge links). Its own hostname.
`ZERO_SYNC_URL`	Copied from `EXTERNAL_UI_URL` when unset. Real-time sync (“Zero”) is served by path on the app hostname.
`COOKIE_DOMAIN`	Domain for sign-in cookies. Set to the `EXTERNAL_UI_URL` hostname when unset. No scheme or port.
`USE_SECURE_COOKIES`	`true` with HTTPS; `false` only for plain HTTP. Set from the `EXTERNAL_UI_URL` scheme when unset.
`LICENSE`	The signed 3B license token (`3bl_v1_…`) from Tines. See applying a license.

Each external URL must use http:// or https://. You need two hostnames: the app (UI, API, and Zero sync) and edge.

On plain HTTP, put both hostnames under the same parent domain, such as 3b.example.internal and 3b-edge.example.internal. Browsers send cookies between different sites only over HTTPS, so custom OAuth consent screens served from edge routes fail when the app and edge hostnames are on different sites.

Registry

Persisted by bootstrap.sh so a re-run of setup.sh works without re-running the bootstrap.

Variable	Description
`REGISTRY`	The registry to pull images from — `oci.tines.com`.
`REGISTRY_USERNAME`	Your Tines tenant name.
`REGISTRY_PASSWORD`	Your Tines OCI registry API key.

TLS (optional)

Variable	Description
`NGINX_TLS_CERT_PATH`	Path on the server to the full-chain certificate (PEM).
`NGINX_TLS_KEY_PATH`	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_URL`	SMTP connection string for outbound email.
`EMAIL_FROM_ADDRESS`	The “from” address on emails 3B sends.

Other optional settings

Variable	Description
`EDGE_WILDCARD_DOMAIN`	Enables space-specific edge hosts. Set it to the parent of the `EXTERNAL_EDGE_URL` hostname, such as `corp.example` for `apps.corp.example`. Edge URLs and inbound email use `<space>--apps.corp.example`. For an existing install, the previous value remains a legacy custom domain, so keep its DNS and certificate coverage.
`HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`	Outbound proxy settings, if your network requires a proxy for internet access.
`ALLOWED_CIDR_BLOCKS`	Comma-separated CIDR blocks that workflow code may reach on internal networks (see below).
`EXTRA_VALUES_FILE`	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.