The Gateway API is the newer method for routing HTTP traffic in Kubernetes. Where `Ingress` consolidates everything into one object and one set of annotations, the Gateway API splits the work across typed resources: a cluster operator owns the `Gateway` (the entry point and its listeners), and application teams own `HTTPRoute` objects (the host and path rules). Use it when you need that role split or richer routing than `Ingress` annotations provide.

Like an ingress controller, a Gateway controller is a reverse proxy pod (Envoy, Cilium's, or Traefik) plus a controller that translates your `Gateway` and `HTTPRoute` objects into that proxy's configuration. The Gateway API changes how you write the routing, not what serves it: a proxy still receives each request and forwards it to your backend.

## Gateway API compared to Ingress

|               | Ingress                                   | Gateway API                                                                   |
| ------------- | ----------------------------------------- | ----------------------------------------------------------------------------- |
| Model         | One object, behavior tuned by annotations | Typed resources: `GatewayClass`, `Gateway`, `HTTPRoute`                       |
| Who owns what | One team owns the whole object            | Operator owns the `Gateway`, app teams own routes                             |
| Traffic rules | Host and path, extras via annotations     | Host, path, header, weight, and cross-namespace routing as first-class fields |

## Not enabled by default

The platform includes no Gateway API controller, just as it includes no ingress controller. You install the Gateway API custom resources and a controller that implements them. Common choices are Cilium's Gateway API support and Envoy Gateway; several ingress controllers, including [Traefik](/docs/hetzner/apalla/network/expose/install-traefik), also implement the Gateway API. As with ingress controllers, running more than one is a supported configuration: each Gateway controller's `type: LoadBalancer` Service is its own load balancer and public IP, so a cluster can have several entry points.

<Steps>
<Step>Install the Gateway API CRDs</Step>

```console
$ kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml
```

<Step>Install a Gateway controller</Step>

Install the controller you selected as a normal workload. Its `type: LoadBalancer` Service receives a Hetzner load balancer from the CCM, the same as any exposed workload.

<Step>Create a Gateway and an HTTPRoute</Step>

The `Gateway` declares the listener; the `HTTPRoute` attaches your application to it.

```yaml title="gateway.yaml"
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web
spec:
  gatewayClassName: cilium
  listeners:
    - name: http
      port: 80
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
spec:
  parentRefs:
    - name: web
  hostnames:
    - my-app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: my-app
          port: 80
```

</Steps>

The application responds on `my-app.example.com` once its DNS `A` record points to the Gateway's load balancer.

## TLS on the listener

You terminate HTTPS by adding an HTTPS listener to the `Gateway` and naming the certificate Secret there, rather than in a `tls` block on the route:

```yaml
listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
        - name: my-app-tls
```

[cert-manager](/docs/hetzner/apalla/network/dns-certs/install-cert-manager) populates that Secret and renews it, the same as it does for `Ingress`. For the Ingress equivalent of this handoff, see [Terminate TLS at the ingress](/docs/hetzner/apalla/network/expose/terminate-tls-at-ingress).

## When to prefer it over Ingress

Use the Gateway API when several teams share one entry point and you want them to own their own routes without editing a shared `Ingress`, or when you need header-based routing, traffic splitting by weight, or cross-namespace routing that `Ingress` cannot express. For a single team exposing a small number of HTTP applications, `Ingress` with a controller such as [Traefik](/docs/hetzner/apalla/network/expose/install-traefik) remains the simpler option.

## Next

- [Terminate TLS at the ingress](/docs/hetzner/apalla/network/expose/terminate-tls-at-ingress) for the Ingress equivalent of the HTTPS listener above.
- [Serve multiple domains and wildcards](/docs/hetzner/apalla/network/expose/multi-domain-and-wildcard) to hold many hosts behind one entry point.
- [Install Traefik](/docs/hetzner/apalla/network/expose/install-traefik) if you prefer to stay on `Ingress`.