Hot reload and runtime ops
Most operational changes to the proxy take effect without restarting the daemon. This guide spells out exactly what's hot-reloadable, what isn't, and the runtime ops you can perform — drain a producer, change log level, validate a config — without a redeploy.
The mechanism
The proxy holds the request and response filter chains behind atomic pointers. When the control-plane-store watcher detects a change (default poll interval 5s), the proxy builds a fresh chain off the request path and atomically swaps it in. No per-request lock, no draining of in-flight requests, no dropped connections.
Hot-reloadable (no restart)
| Change | How it lands |
|---|---|
| Policy rules — add / update / delete / rollback | admin API mutation → store → next watcher tick → atomic swap |
| Rate-limit rules | same |
| Transformation rules | same |
| Routing rules | same |
| Producer pool — drain / restore / weight | direct admin endpoint; takes effect on next request |
| Producer configs (persistent) | store → next watcher tick |
| Log level | d3x-edgectl log-level set; immediate, node-local |
default_action | d3x-edgectl default-action set|flip; live, no restart |
| NRF profile definitions | store → registrar reload; the leader re-registers with the NRF |
| Diameter peers / routes / settings | store watcher reloads the live relay when the Diameter subset actually changes |
| Active policy version (rollback) | snapshot restore; atomic swap to the captured document |
Requires restart
| Change | Why a restart |
|---|---|
| Listen addresses (SBI / admin / Diameter / metrics) | Listeners bind at startup |
| TLS material on the listeners | Reloaded on certificate file change via the cert reloader; full TLS block swaps require restart |
| Diameter transport, origin host/realm, listen address | Identity and bind of the Diameter node; peer and route rows in the store still hot-reload |
| Storage drivers / DSNs | Connection pools open at startup |
| pprof, tracing endpoint, server timeouts | Bound to long-lived components |
Certificate reload
The certificate reloader watches the configured cert_file and key_file paths and reloads on change. The standard ops pattern:
- Drop the new cert + key alongside the old, or rename atomically.
- The reloader picks up the change on the next file-watch tick.
- New TLS handshakes use the new material; established connections keep their existing TLS state.
This applies to both SBI and admin listeners (and Diameter TCP TLS).
Runtime ops cheat sheet
Drain and restore a producer
Take a single SBI producer out of rotation without removing it from config — useful for targeted ops on a flapping instance.
Shift producer weight
Both take effect on the next request. No restart.
Change log level live
Validate before apply
validate config checks a bootstrap YAML/JSON file without starting the daemon. apply --dry-run resolves create / update / unchanged for PolicyRule, RateLimit, Transformation, RoutingRule, ProducerConfig, and ProfileConfig manifests without writing. There is no validate policy subcommand — rules validate inline on write.
Tune watcher cadence
The store-watcher polls at process.store_watch_interval (default 5s). Tighter means faster propagation in multi-instance deployments; looser means fewer DB round-trips. Restart required to change.
Multi-instance propagation
When two or more d3x-edge instances share a Postgres control-plane store, a hot-reloadable change applied to one instance propagates to the others within the watcher window. For coordinated rollouts (e.g. a policy change you want to land everywhere simultaneously), drop the watcher interval temporarily, apply, then restore.
Where to go next
- Architecture — the atomic-swap mechanism.
- Policy versioning and rollback — atomic rollback flow.
- Admin API → Producers and profiles.