Announcing HAProxy Unified Gateway 1.0

Today at KubeCon Amsterdam, we are announcing the 1.0 release of HAProxy Unified Gateway, incorporating valuable community feedback from our beta users. HAProxy Unified Gateway delivers unified, high-performance, cloud-native application routing backed by an open-source community with 25+ years of experience.

New to HAProxy Unified Gateway?

HAProxy Unified Gateway is a free, open-source project maintained by HAProxy Technologies that enables Kubernetes-native traffic management covering Gateway API specifications 1.3, 1.4, and 1.5.

Organizations are moving more workloads to Kubernetes, which requires routing methods that handle diverse applications and organizational complexity. The Gateway API standard provides a solution through role-based access control, enabling a clear separation of concerns among infrastructure providers, cluster operators, and application developers.

HAProxy Unified Gateway provides flexible protocol support, role-based access control, and a future path for unified Ingress support coming later in 2026. It brings exceptional performance and efficiency to Kubernetes traffic management because it is built on HAProxy, the world’s fastest software load balancer. By adopting HAProxy Unified Gateway, teams have the freedom to scale exceptionally well with class-leading performance and efficiency on any infrastructure.

What's new in HAProxy Unified Gateway 1.0

The 1.0 release focuses on operational simplicity, expanded routing capabilities, and deep integration with HAProxy configuration features.

Feature	Benefit	Impact
HAProxy 3.2 LTS core	Provides a highly efficient, low-resource data plane for high-volume traffic.	Delivers improved performance, security, and reliability to Kubernetes.
Comprehensive HAProxy configuration	Manage Backend, Default, and Global settings natively via CRDs.	Define and maintain advanced traffic policies alongside your application code.
Expanded route and listener support	Route HTTP, HTTPS, and TLS traffic, with multiple listeners per port.	Seamlessly support multiple applications.
Enhanced dynamic scaling	Dynamically updates servers based on Kubernetes API endpoints.	Ensures smooth traffic flow by reducing reloads and eliminating dropped connections during scaling.
Metrics and session persistence	Adds built-in performance monitoring and sticky session routing.	Increases visibility and reliability for stateful, mission-critical services.
Helm chart installation	Automates the deployment and upgrading of the gateway and CRDs.	Accelerates integration into existing continuous integration and delivery pipelines.

Scaling Kubernetes routing (and more) with the HAProxy One platform

As your infrastructure grows, Kubernetes traffic management becomes just one piece of a much larger puzzle. To truly simplify, scale, and secure modern applications in any environment, organizations require a unified approach.

This is where HAProxy One comes in.

While HAProxy Unified Gateway provides developers and cluster operators with the flexibility of the Gateway API, enterprise teams managing mission-critical workloads often require advanced security, global observability, and centralized management. To meet these needs, organizations can seamlessly extend their architecture with our HAProxy One enterprise platform, which includes the following:

• HAProxy Enterprise: Upgrading to our enterprise data plane adds multi-layered security — including an integrated web application firewall (WAF), bot management, and advanced threat intelligence — without sacrificing our signature ultra-low latency.

• HAProxy Fusion Control Plane: HAProxy Fusion provides centralized management, observability, and automation across your entire deployment. Looking ahead, Gateway API support is coming to HAProxy Fusion, which will empower platform engineering teams to manage both traditional infrastructure and Kubernetes-native routing from a single, authoritative control plane.

Core technology built on HAProxy 3.2 LTS

HAProxy Unified Gateway 1.0 is built on the stable and powerful HAProxy 3.2 LTS core. This foundation ensures that your Kubernetes traffic management benefits from the extensive performance enhancements, security updates, and reliability improvements introduced in the 3.2 long-term support release. It provides a highly efficient data plane that minimizes resource consumption while reliably routing high volumes of traffic.

Comprehensive HAProxy configuration support

To give you more control over your traffic routing, this release introduces three new Custom Resource Definitions (CRDs) — Global, Defaults, and Backend — that let you manage HAProxy configuration natively within Kubernetes. The Global CRD lets you override HAProxy's global section, adjusting connection limits, TLS cipher suites, DH parameters, and process-level tuning. The Defaults CRD lets you customize the timeout and connection-handling values that every frontend and backend in the cluster inherits. The Backend CRD lets you configure load balancing behaviour, health checks, and server options for individual services. 

Frontends are generated automatically from your Gateway and Route resources — that's the Gateway API model — so there is no Frontend CRD. Instead, your frontend configuration is expressed declaratively through the Gateway spec. 

In the beta release, operators who needed to override Global or Defaults settings had to inject auxiliary configuration files via ConfigMap volume mounts, a workaround that sat outside Kubernetes' resource model and required modifying the controller Deployment to wire up. With these CRDs, the same overrides are expressed as standard Kubernetes objects, applied with kubectl apply, and picked up by the controller automatically.

Expanded route and listener support

HAProxy Unified Gateway 1.0 expands its routing capabilities to cover the full range of production traffic patterns. It supports HTTPRoute for HTTP and HTTPS traffic with TLS termination, and TLSRoute for TLS passthrough — where HAProxy reads the SNI hostname from the TLS ClientHello to route the connection without decrypting it. 

In the beta release, combining different listener types on the same port was not supported; a Gateway could only host one protocol per port. Version 1.0 removes that restriction, so a single Gateway on port 443 can simultaneously serve an HTTPRoute via HTTPS termination and a TLSRoute via passthrough, distinguished entirely by SNI hostname.

This matters in practice because many production clusters expose a single public IP address with only port 443 open at the firewall.  Organizations need to run modern web services alongside legacy applications that require end-to-end encryption to the backend pod, all through that one port.

Because both listener types attach to the same Gateway definition, platform teams can establish port exposure and TLS policy once, and application teams can add or change routes independently — without modifying the underlying infrastructure.

Enhanced dynamic scaling

Managing dynamic environments is simpler with improved scaling mechanisms in version 1.0. In the beta release, every pod scale event — whether triggered by a Horizontal Pod Autoscaler or a manual kubectl scale — could require a full HAProxy reload to update the backend server pool. HAProxy Unified Gateway 1.0 eliminates this by registering a watch against the Kubernetes Endpoints API for every Service referenced by a route. When pod counts change, the controller detects the updated IP addresses and reconciles server entries in the running HAProxy process directly via the Runtime API, without triggering a reload. 

The result is that active connections are never dropped during scale-out, and scale-in events drain gracefully — connections to departing pods are allowed to complete before those servers are removed from the pool.

New operational features for metrics and session persistence

Observability and traffic consistency are critical for production workloads. This release addsbuilt-in metrics (with a Prometheus-compatible endpoint), allowing operators to monitor gateway performance and application health directly. It also introduces session persistence, ensuring that users maintain a continuous connection to the same backend pod when required by stateful applications. These additions provide the visibility and reliability needed to confidently run mission-critical services in Kubernetes.

Simplified installation and lifecycle management

To help you deploy and manage the gateway with ease, we have introduced support for Helm charts. This streamlines the installation process and enables the automatic deployment and upgrading of Custom Resource Definitions. By standardizing on Helm, infrastructure teams can integrate HAProxy Unified Gateway into their existing continuous integration and delivery pipelines quickly and reliably.

Configuration example

In this example, a platform team is integrating HAProxy Unified Gateway into their GitOps-based delivery pipeline, which uses Flux and ArgoCD with Helm chart manifests stored in version control. Rather than managing a sequence of raw YAML files and re-applying them at upgrade time, they adopt the official HAProxy Unified Gateway Helm chart, which handles CRD installation, namespace creation, RBAC, and controller deployment in a single, repeatable operation. A values.yaml file checked into their repo tracks the configuration.

Step 1 — Add the HAProxy Helm chart repository

Step 2 — Install Gateway API CRDs (prerequisite)

Step 3 — Create a values file

Step 4 — Install HAProxy Unified Gateway

Step 5 — Verify the installation

Step 6 — Upgrade to a new Helm chart version

The Helm chart version (specified with --version) and the HAProxy Unified Gateway application version are independent. The chart's appVersion field tracks the HAProxy Unified Gateway release and is updated automatically by HAProxy Technologies whenever a new version of HAProxy Unified Gateway is published to Docker Hub.

To upgrade the chart, run helm upgrade with the new chart version:

If your values.yaml sets image.tag explicitly (as in Step 3), that value takes precedence over appVersion and will pin the HAProxy Unified Gateway image regardless of chart updates. To upgrade to a new HAProxy Unified Gateway release, update image.tag in values.yaml to the desired version before running helm upgrade. To track appVersion automatically instead, remove the image.tag override from your values.yaml.

The Helm chart automatically applies any updated CRD schemas before rolling out the new controller Deployment, ensuring that CRDs stay in sync with the controller version throughout the upgrade lifecycle.

Summary

The helm install command replaces the multi-step kubectl sequence from the on-premises installation guide. With crds.install: true, the chart installs the Backend, HugConf, and HugGate CRDs as part of the release and tracks them in the Helm release metadata. The gatewayClass.create: true flag creates the haproxy GatewayClass automatically, so the cluster is ready to accept Gateway resources immediately after installation. The values.yaml serves as a declarative record of the deployment's configuration, which can be committed to version control and reconciled by GitOps tooling on every change.

Ready to upgrade or try?

HAProxy Unified Gateway remains a free, open-source product dedicated to the Kubernetes community and the adoption of the Gateway API standard.

You can find the Docker image for HAProxy Unified Gateway on Docker Hub and the Helm Charts on GitHub. We encourage you to participate and contribute to the community project on GitHub.

Subscribe to our blog. Get the latest release updates, tutorials, and deep-dives from HAProxy experts.