Configuration changes in the load balancing and security layer are unavoidable. New backends are added, WAAP rules are updated, certificates are renewed, health checks are adjusted, rate-limit policies are tightened, or new blocking rules are written in the middle of an attack. If every change requires a service restart, even small operational tasks turn into user session interruptions.
The classic restart model is especially problematic for TCP and long-lived connections. Active user sessions can be cut, file transfers can be left incomplete, API clients can receive errors, and a firewall rule change can cause a momentary access failure. As a result, teams start deferring necessary changes, and security and operational agility suffer.
The problem is most acute in WAAP and security rule sets. Waiting for a maintenance window to apply a rule update while a new attack pattern is actively being observed is not an acceptable position. Likewise, routine operations such as certificate renewal or backend pool expansion should not unnecessarily affect live traffic.
The right model is to distinguish between change types. Changes that can be applied at runtime — rules, certificates, health checks, backend lists and security profiles — should go through soft reload. Only changes that affect service creation parameters — VIP, port, namespace, resource limits or service type — should require a controlled restart.
TR7 Hot Config Reload makes this distinction: per-pool soft reload, automatic hard fallback, restart reason visibility and parallel operation flow apply configuration changes while minimising the impact on live traffic.
TR7 designs configuration reload not as a single uniform restart operation, but as a layered operation flow that decides based on change type.
Each pool can receive a reload through its own management channel. This model ensures that a change in one pool is applied without affecting other pools.
TR7 uses the soft reload path that preserves live connections by default. If soft reload fails or the change requires a hard restart, the system switches to a controlled restart path.
Config diff analysis determines which fields require a reload and which require a restart. Operators can see in advance whether a change can be applied live or involves a creationConfig modification that mandates a restart.
Load balancing and log container operations can run in parallel when they are independent. This prevents pool edit time from being stretched by unnecessary sequential waits.
Hot Config Reload combines per-pool reload, change-type analysis, fallback, connection drain and parallel operations in a single management flow.
Soft reload activates the new configuration for eligible changes while allowing existing connections to complete naturally. The old worker enters drain mode and continues serving active sessions until they close. New connections are handled by the updated config. This approach removes the need to tie rule and certificate changes to a maintenance window.
TR7 defaults to the soft reload path. If an error occurs during soft reload, the system recovers via hard restart fallback. This model offers operators a single safe flow: reload without downtime where possible, restart in a controlled manner where necessary. Failed reload attempts do not result in an indeterminate half-applied configuration state.
Some changes cannot be applied via live reload because they modify service creation parameters. Fields such as service type, CPU limit, memory limit, VIP, port, network namespace, image or binary version require a hard restart. In these cases, forceHard behavior makes the restart explicit and intentional. Operators can plan the impact of the change in advance.
For each config field, the reason why a change requires a reload or restart can be held in the restartReasons list. This visibility answers the question "why does this change need a restart?" for the operations team. It makes decision-making clearer, particularly during change management and maintenance approval processes. Change impact stops being a black box.
Each pool is handled with its own runtime structure and management channel. While a WAAP profile, certificate or backend list changes in one pool, other pools continue running without interruption. This isolation narrows the blast radius of changes on large platforms. The operations team reloads only the relevant service, not the entire appliance.
Log transport or log container configurations can be handled separately from the load balancing container. Changes on the log side therefore do not unnecessarily affect the traffic routing layer. Equally, a reload on the traffic side does not force the log pipeline to be interrupted. This separation gives more controlled change management across the platform.
If a change affects both the load balancing and log sides, eligible operations can run in parallel. Sequential waiting is reduced and total job time is shortened. This matters especially with large configurations or updates that affect multiple sub-components. The operation window is used more efficiently.
When a soft reload is applied, the old worker is not killed immediately — existing connections are allowed to close naturally. New traffic is directed to the updated configuration while existing traffic completes its natural shutdown. This is critical for long-lived TCP connections and active user sessions. The goal is to avoid producing TCP resets or abrupt disconnections at the moment of the change.
When a specific error threshold is exceeded in pool statistics, an automatic reload can be triggered. This behavior helps transient runtime issues recover without waiting for manual intervention. For operators, this means an automatic health improvement signal for the service. Recurring reload causes should still be evaluated through monitoring and root cause analysis.
WAAP profile, whitelist, rule set and Lua script updates can be treated as live-reloadable changes. This enables rapid security policy updates during an attack and activates new logic without interrupting application traffic. Rule set changes are not tied to a full platform restart. This approach increases the agility of security operations.
Hot config reload operates together with the pool management path, command behavior, timeout, retry logic and the classification of which fields count as soft or hard changes.
Each pool has a dedicated management socket. The reload command is sent to the management channel of the relevant pool. This structure is the foundation of per-pool independent reload behavior.
Soft reload is triggered by a reload command sent to the management channel. If the command succeeds, the new config is activated and existing connections are protected by drain behavior. On failure, smart reload can apply a hard restart fallback.
Pool container names follow a consistent pattern linked to the poolId. This structure ensures that reload, restart, log cleanup and health check operations are applied to the correct container. Operation automation benefits from this deterministic naming.
In the default model, soft reload is attempted once. If an exception or reload failure occurs, the system switches to the hard restart path. This approach avoids stretching operation time by repeatedly retrying a failing reload.
The total timeout for a pool edit job can be held at 5 minutes. This covers the full scope of log cleanup, reload and restart if necessary. Long-running jobs do not remain open in an indeterminate state on the operations screen.
Default waitBefore and waitAfter values can be run optimized at 0. This removes unnecessary fixed waits. Actual wait time is determined by the state of the operation and the system response.
A new WAAP rule set or OWASP-based update can be included in the soft reload scope. Existing user sessions are preserved while the new security logic takes effect for incoming requests. There is no need to wait for a maintenance window during an active attack.
When a certificate approaching expiry is updated, the lbCertificates change can be applied via soft reload. New TLS connections use the updated certificate. Existing connections close naturally through drain behavior.
New backend nodes can be added to the lbBackends list. After soft reload, new connections benefit from the expanded pool. Capacity is increased without affecting other pools or existing connections.
A new DDoS or rate-limit profile can be applied as a live config change. The policy takes effect on incoming requests within a short time. The operations team responds to the attack without creating additional downtime from a restart.
Apply WAAP rules, certificates, backend pools and rate-limit policies without dropping active sessions. Let's walk through a live setup in your own environment.