-
Notifications
You must be signed in to change notification settings - Fork 0
Configuration Workflow
Jul.IA uses one TOML document. This page describes how to work with it safely without duplicating the fast-changing field reference.
Most installations combine:
- process-wide settings;
- one or more HTTP servers and locations;
- named upstream pools;
- optional cache, compression, rate-limit, egress, observability, admin, WAF, plugin, or stream sections.
The configuration reference is the only source for exact keys, defaults, allowed values, activation conditions, and examples.
-
Make the smallest coherent change.
-
Run a full preflight:
jul check -config server.toml
-
Review advisory findings:
jul lint -config server.toml
-
Optionally enforce canonical TOML:
jul fmt -config server.toml -diff
-
Apply through the Console or admin API when you need managed persistence, correlation, history, and rollback.
-
Confirm the serving version and health after the change.
- Unknown fields are rejected.
- Invalid explicit values are rejected instead of silently replaced by defaults.
- A location has one primary action; ambiguous route blocks are rejected.
- A feature configured without its required build capability is rejected at preflight.
- Secret references should be used for credentials and tokens rather than literal values.
Use for a candidate whose changed fields are live-reloadable. The managed path validates before persistence and reports the correlated runtime result.
Use for valid changes that affect startup-bound subsystems. The new configuration is persisted for the next restart while the current process keeps serving the previous version.
Do not assume a field is hot-reloadable. Consult the reload semantics and the machine-readable lifecycle registry.