HAProxy 3.4 LTS: Upgrade Checklist for Load Balancers

HAProxy 3.4 is a new LTS branch with dynamic backends, OpenTelemetry, TLS updates, ACME improvements, and reliability changes. Plan upgrades safely.
HAProxy 3.4 LTS upgrade checklist for load balancer validation, TLS checks, health checks, and observability

HAProxy 3.4 was released on June 3, 2026 and is now listed by HAProxy.org as an LTS branch. HAProxy.org lists version 3.4.0 with an end-of-life target of 2031-Q2, which makes this more than a feature release for web hosts, SaaS teams, agencies, and infrastructure admins. It is a good moment to plan the next load-balancer maintenance path.

The release adds dynamic backend management, performance and memory improvements, native cryptographic operations at the proxy layer, ACME and TLS updates, broader glitch detection, stream elasticity, and OpenTelemetry support as the forward path for tracing. HAProxy also notes that OpenTracing is deprecated in 3.4 and planned for removal in 3.5.

This is an operations guide. It is not telling every production site to jump immediately. The right path is to inventory the current branch, test the configuration, confirm package support, drain traffic carefully, and verify real application behavior after the change.

What changed in HAProxy 3.4

  • Dynamic backends: operators can add, publish, and delete backend sections at runtime without a full reload when the deployment is designed for that model.
  • HTTP/3 and QUIC experiments: QMux support is available for environments where carrying QUIC over TCP is useful, but it should be treated as a lab or controlled rollout feature.
  • Performance: HAProxy reports smarter buffer allocation and efficiency improvements on large-core-count systems.
  • TLS and API security: HAProxy 3.4 adds native cryptographic building blocks and enhanced ACME handling for certificate workflows.
  • Reliability: glitch detection now covers HTTP/1 as well as HTTP/2 and QUIC, and stream elasticity helps moderate concurrent H2/H3 streams under load.
  • Observability: OpenTelemetry support arrives as an add-on, while OpenTracing is deprecated and should be migrated before HAProxy 3.5.

Who should plan this upgrade

HAProxy 3.4 is most interesting for teams running their own edge, reverse proxy, API gateway, high-traffic WordPress or WooCommerce stack, SaaS ingress tier, Kubernetes ingress layer, or CDN/origin routing system. It is also relevant if you depend on HAProxy for TLS termination, ACME automation, HTTP/2 or HTTP/3 behavior, health checks, backend draining, or detailed request logging.

If your server gets HAProxy from an operating-system vendor, cPanel/WHM extension, Plesk extension, appliance vendor, or managed hosting image, do not replace it blindly. Vendor packages may lag or backport fixes. Confirm the supported path before changing a production package source.

Pre-upgrade checklist

  1. Record the current branch and package source. Note whether you are on HAProxy 2.8, 3.0, 3.2, 3.3, a distro build, a container image, or a vendor appliance package.
  2. Back up configuration and maps. Include HAProxy config files, map files, certificate paths, systemd overrides, runtime API socket permissions, WAF/rate-limit files, and deployment manifests.
  3. Check deprecated features. Look for OpenTracing usage and older compression-direction settings before testing 3.4.
  4. Validate the configuration in staging. Run HAProxy’s built-in configuration check against the exact files you plan to ship.
  5. Test TLS and ACME behavior. Confirm certificates, chains, OCSP behavior, ALPN, HTTP/2, HTTP/3, and automated renewal paths before production reloads.
  6. Plan backend draining. Keep health checks green, drain one load balancer or node at a time, and verify that sticky sessions, WebSockets, long polling, and uploads survive the maintenance plan.
  7. Confirm observability changes. If you use OpenTracing, plan the OpenTelemetry migration now instead of waiting for the 3.5 removal window.

Production rollout notes

For a pair of load balancers, update the standby node first, validate config, start HAProxy, confirm health checks, then move a small slice of traffic before making it primary. For containerized or Kubernetes deployments, pin the intended image tag or digest, roll a small replica set first, and watch both application metrics and HAProxy logs.

Dynamic backends are powerful, but they also change the operational model. If a control plane can create or publish backends at runtime, review who can access that control plane, how changes are audited, and what happens when a backend is unpublished or removed during live traffic.

Post-upgrade verification

  • HAProxy reports the intended 3.4 build and package source.
  • Configuration validation passes for every frontend, backend, map, certificate, and include file.
  • Health checks show expected backend status before and after traffic is restored.
  • HTTP, HTTPS, HTTP/2, HTTP/3, WebSocket, upload, and long-running request paths behave normally.
  • TLS certificates, ACME automation, redirects, HSTS, and CDN/proxy-chain headers still match policy.
  • Rate limits, WAF rules, bot controls, stick tables, and failover behavior still work.
  • Logs, metrics, alerting, and tracing are visible in the expected monitoring stack.
  • OpenTracing users have a migration plan toward OpenTelemetry before HAProxy 3.5.

Hosting and site-owner notes

Business site owners may never log into HAProxy directly, but they can still feel a bad load-balancer upgrade as checkout failures, login loops, broken uploads, missing WebSocket connections, certificate warnings, or random 502/503 errors. If HAProxy sits in front of WordPress, WooCommerce, WHMCS, cPanel, Plesk, or a customer portal, test those flows instead of checking only the home page.

For providers, tell customers when a maintenance window may affect edge routing, TLS, redirects, or portal sessions. Keep rollback simple: known-good package, known-good config, and a cache/CDN purge plan if headers or redirects changed.

Related Fix I.T. Phill reading

Sources

Need help planning a load-balancer upgrade window? Fix I.T. Phill can help inventory the current HAProxy branch, test the config, stage a safe reload, verify TLS and health checks, and document the rollback path.

Picture of admin

admin

Leave a Reply

Sign up for our Newsletter

Get the latest information on what is going on in the I.T. World.