Configuration reference
The full list of environment variables Prelude TE reads at startup, the storage layout, and where runtime settings live.
This page is the canonical reference for how Prelude TE is configured. Two categories matter:
- Startup configuration — environment variables read once when the engine starts. Documented below.
- Runtime settings — peers, outputs, users, tokens, BGP identity, licensing. Managed live through the web UI or the REST API; not covered here.
Environment variables
All variables are optional; sensible defaults are baked in. Override only what matters for your environment.
Server
| Variable | Default | Description |
|---|---|---|
TE_PORT |
4040 |
TCP port for the REST API, web UI, and SSE streams. |
TE_TLS_CERT |
(empty) | Path inside the container to the TLS certificate (or fullchain). When unset, the engine generates a self-signed certificate on first start. |
TE_TLS_KEY |
(empty) | Path inside the container to the matching TLS private key. |
Runtime
| Variable | Default | Description |
|---|---|---|
TE_STORAGE |
./storage |
Root directory for persistent runtime files (SQLite database, logs, certs, license artifacts). Mount as a volume. |
TE_TIMEZONE |
UTC |
IANA timezone used for log timestamps and scheduled tasks. |
TE_DEBUG |
false |
Enable debug-level structured logging across the application. Verbose; leave off in production. |
TE_LOG_LEVEL |
INFO |
Default log level when TE_DEBUG is off. One of DEBUG, INFO, WARN, ERROR. |
TE_LOG_STDOUT_MODULES |
(empty) | Comma-separated list of logging modules to mirror to stdout. Useful when troubleshooting a specific area. |
Storage layout
The path you mount at TE_STORAGE is structured as follows once the
engine has run at least once:
storage/
├── db/
│ └── prelude-te.db # SQLite database (peers, outputs, users, tokens, settings)
├── certs/ # TLS certificate and key (auto-generated or user-supplied)
├── logs/ # Per-module log files (e.g. prelude-te.log, access.log)
└── ... # additional runtime files added as features evolve
The database is created and migrated automatically on first start. Migrations are idempotent — it is safe to run a newer image against an existing storage volume.
Back up storage/ as a single unit
It holds every piece of state that is not rebuilt from BGP-LS at startup: peer configuration, output configuration, users, tokens, application settings. Treat it the way you would treat the database directory of a database server.
What lives elsewhere
Three categories of settings are not environment variables:
- BGP identity (Router ID, Local AS, Passive mode) — managed via Settings in the web UI. Applied immediately, without restart.
- Peers, outputs, users, tokens, licensing — managed live through the UI and the REST API on top of a running instance.
- TLS material — auto-generated under
storage/certs/on first start, or supplied by you viaTE_TLS_CERT/TE_TLS_KEY.
Reloading
Environment-variable changes take effect after a container restart. Database-backed settings and live records (peers, outputs, …) take effect immediately, without restart.