We're announcing HAProxy Unified Gateway 1.1, bringing Ingress and Gateway API resources together in a free and open-source solution.
This release delivers a milestone in the migration path we introduced with the public beta and the version 1.0 release. You can simultaneously serve supported Ingress resources and adopt Gateway API, without converting Ingress rules into Gateway API manifests. Backend custom resources let you configure the traffic policies your applications need.
Version 1.1 also adds Gateway API TCPRoute support for port-based routing of TCP services. Gateway API ListenerSet enables shared-Gateway delegation, Gateway API 1.7.0 is supported at launch, and this release reduces the container image size by 40%.
HAProxy Unified Gateway remains the free, in-cluster option. For organizations that need centralized management and enterprise-grade security, HAProxy One provides a separate operating model.
What is HAProxy Unified Gateway?
HAProxy Unified Gateway is a free, open-source project maintained by HAProxy Technologies that enables Kubernetes-native traffic management using the Gateway API specification.
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 (RBAC), enabling a clear separation of concerns among infrastructure providers, cluster operators, and application developers.
HAProxy Unified Gateway provides flexible protocol support, RBAC, and integrated Ingress support. It brings exceptional performance and efficiency to Kubernetes traffic management because it's built on HAProxy, the world's fastest software load balancer. By adopting HAProxy Unified Gateway, teams can scale reliably across any Kubernetes infrastructure.
New in HAProxy Unified Gateway 1.1
Feature | Benefit |
|---|---|
Ingress API support | Serve supported Ingress resources alongside Gateway API resources. |
TCPRoute support | Expose TCP services through Gateway API listeners. |
Gateway API ListenerSet | Delegate listeners without giving application teams write access to the shared Gateway. |
Gateway API 1.7.0 support at launch | Support existing specification baselines while adopting newer API capabilities. |
HAProxy 3.4 core | Improved performance and reliability, with greater configuration flexibility. |
Gradual path from Ingress to Gateway API
Version 1.1 lets you adopt Gateway API alongside supported Ingress workloads, with Kubernetes-native controls for routing and backend configuration.
Serve both Kubernetes objects with one controller
HAProxy Unified Gateway 1.1 adds Ingress and IngressClass support alongside Gateway API resources. You can keep supported Ingress rules in use while introducing Gateway API resources for new or migrated applications.
Internally, the controller translates Ingress resources into virtual Gateway and HTTPRoute representations; these exist in memory, rather than as additional objects in the Kubernetes API. Application teams continue working with their Ingress resources until they choose to migrate those rules.
Teams planning their next step after the Ingress NGINX retirement can introduce Gateway API alongside supported Ingress workloads.
Bring existing Ingress workloads forward
Ingress support includes exact and prefix path matching, with host-based routing for multiple domains and wildcard hosts. TLS termination uses the certificates declared in your Ingress resources.
Backend custom resources let you define load balancing policies and health checks alongside your applications. This gives you a Kubernetes-native way to configure traffic handling while retaining supported Ingress rules. The process is as follows:
Enable Ingress support through
--enable-ingress.Configure IngressClass matching and RBAC for the resources managed by the controller.
Expose the dedicated Ingress ports, which default to 8080 for HTTP and 8443 for HTTPS.
Direct incoming traffic from the previous controller to HAProxy Unified Gateway.
Our documentation covers supported configuration and deployment requirements.
Route TCP services with Gateway API
HAProxy Unified Gateway 1.1 adds TCPRoute support, bringing port-based TCP routing into the Gateway API configuration model. A TCPRoute attaches to a TCP listener on a Gateway and forwards connections to backend Services.
Weighted backend references distribute new connections between Services, so you can gradually shift traffic as you roll out a new backend. Service-level Backend custom resources let you tune timeouts and load balancing policies while managing TCP and HTTP routing through Kubernetes.
Try the TCPRoute configuration examples for basic forwarding and weighted backend distribution.
Share a Gateway with ListenerSet
A shared Gateway can become a coordination problem when every listener change requires the platform team to edit the same object.
Gateway API ListenerSet support lets application teams contribute listeners without taking ownership of the Gateway. The Gateway owner controls admission through allowedListeners, preserving the platform's authority over what can attach.
For example, a platform team can own a shared Gateway while an application team defines the listeners needed for its service. The application team's routes attach to its ListenerSet. Changes stay with the team responsible for the application, within the Gateway owner's admission policy.
This extends the Gateway API's separation of responsibilities to listener management; platform engineers can delegate routine changes rather than handling each one themselves.
Built on the latest core technology
Updated Gateway API support broadens routing options, while the newer HAProxy core brings improvements in performance and reliability.
Gateway API specification and HTTP routing
HAProxy Unified Gateway 1.1 supports Gateway API specifications from 1.6 onwards, with 1.7.0 support included at launch. Match your routing resources to the features documented for the controller.
HAProxy Unified Gateway 1.1 passes all Gateway API Core conformance tests for HTTP, TCP, and TLS. For practical routing examples, see the HTTPRoute documentation.
HAProxy Unified Gateway 1.1 expands HTTPRoute support with more request-matching options and filters, giving you greater control through standard Gateway API resources.
A newer HAProxy core
Version 1.1 upgrades the HAProxy core from 3.2 to 3.4. This brings improvements in performance and reliability, with greater configuration flexibility for Kubernetes traffic management.
Read the HAProxy 3.4 release announcement for the underlying changes.
Scale centralized operations with HAProxy One
HAProxy Unified Gateway serves the free, in-cluster use case. Enterprises that need centralized control and application security across a larger deployment have a separate path through HAProxy One.
Coming with HAProxy Fusion 2.1, enterprises will be able to centrally manage Ingress and Gateway API resources using HAProxy Enterprise as the data plane. In that model, HAProxy Fusion reads those Kubernetes resources and configures a managed HAProxy Enterprise fleet from a central control plane.
HAProxy Enterprise adds an integrated web application firewall (WAF), bot management, and global rate limiting.
HAProxy Fusion provides fleet-wide load balancer management and observability. Together, HAProxy Fusion and HAProxy Enterprise support external load balancing for Kubernetes and multi-cluster routing.
HAProxy Edge supplies the platform's secure edge network.
This enterprise operating model combines Kubernetes routing with centralized security and management across your deployment.
Try HAProxy Unified Gateway
Choose the installation method that fits your environment:
Docker: Get the HAProxy Unified Gateway image and select the release version you intend to deploy.
Helm: Use the official Helm chart for Kubernetes deployment.
We highly recommend starting with our installation documentation. Gateway API Custom Resource Definitions (CRDs) are required even when serving Ingress resources.
The Helm chart version and application version are separate: check the chart's appVersion and any image.tag override before upgrading.
Next steps
Start with a supported Ingress workload, or define a new Gateway API route for HTTP or TCP traffic. Then, check the result in your environment before moving more traffic.
We welcome feedback and contributions through the community project on GitHub.
Looking to simplify your Kubernetes traffic management while boosting performance? Download our free e-book, Unified Kubernetes, to explore a consistent model for high-speed routing, edge security, and fleet-wide observability.
