v1.0.35 — HTTP backend pools and failover

Adds the backend-pool functionality requested in issue #30.

HTTP sites can now use up to 16 backend origins with ordered failover and automatic failback, or load balancing using round robin, least active requests, weighted round robin, client-IP affinity, or cookie affinity. The site editor includes member ordering, enable/disable controls, weights, active health checks and on-demand health observations.

An optional plain-text maintenance response covers application proxy failures, including when every member is unavailable. WAF denials, authentication responses and HTTP errors returned by the application retain their original behavior. Failed requests are not automatically replayed. Existing single-backend sites continue to work unchanged.

Health observations are advisory and may lag; ambiguous or unavailable metrics appear as unknown. HTTPS members share the site's trust settings and must use the same scheme. Cookie affinity does not replicate application sessions. Cached website fallback, shared pools, TCP/UDP pools and infrastructure high availability are outside this release.

Caddy remains 2.11.4, coraza-caddy 2.6.2, and Coraza 3.8.1.

Images

Production images target linux/amd64:

• ghcr.io/socfortress/waf-caddy:1.0.35
• ghcr.io/socfortress/waf-admin-api:1.0.35
• ghcr.io/socfortress/waf-admin-ui:1.0.35

Upgrade

Back up the database and configuration, set WAF_IMAGE_TAG=1.0.35, pull the images and recreate the services. Preserve existing TCP/UDP port overrides. Once Caddy is ready, restart the admin API so it restores the saved configuration.

The API applies migration 0038_backend_pools, adding nullable pool configuration and cookie-secret columns. Existing sites remain single-backend sites until explicitly changed. In Sites, edit a site and select Backend pool to configure members. Every member must implement the selected health endpoint (default /health, HTTP 200).

Validation

• 491 backend tests and 89 frontend tests passed; production frontend build passed.
• Real Caddy integration verified balancing, failover/recovery, affinity across reload and failure, maintenance boundaries, WAF/auth preservation, TLS trust and hostname checks, and failed POST non-replay.
• PostgreSQL migration upgrade/downgrade and persistence checks passed, including database rollback after a simulated Caddy reload rejection.
• All three local Docker images built successfully, with runtime smoke checks. The production release workflow completed successfully for all three linux/amd64 images; registry metadata confirms version 1.0.35 and the merged source revision.

Rollback

Before rolling back, use v1.0.35 to change pooled sites to the intended single backend. While the v1.0.35 API image is still installed and site edits are paused, downgrade the database to 0037_merge_forwarding_reputation with alembic downgrade 0037_merge_forwarding_reputation in the admin API container. This removes the pool and cookie-secret columns; preserve a backup if those settings are needed later.

Then restore all three images to WAF_IMAGE_TAG=1.0.34, recreate the services and restart the API after Caddy is ready. A pool's legacy URL mirrors its first configured member, even if that member was disabled, so explicitly choosing the rollback backend first is important.