← Documentation

The gateway

Most of Kaja works the same whether or not your cluster can be reached from the internet. Serving traffic is the exception, because a cluster nothing can reach cannot receive a request.

The gateway is the answer to that, and it is worth understanding because it is the one part of Kaja that sits in the path of your users' traffic.

The problem it solves

To serve a request, something has to accept an inbound connection from the internet. A cluster in a cloud account does this with a load balancer that has a public address. Plenty of real clusters cannot:

  • A machine behind NAT, where inbound connections have nowhere to land.
  • A connection behind carrier-grade NAT, where you cannot forward a port even if you want to.
  • A cluster inside a network whose firewall is not going to be opened for you.
  • Bare metal with no load balancer to provision, because there is no cloud API to ask.

The usual workarounds are a VPN, a port forward, or a jump host. Each is a piece of network engineering, and each ends with an inbound hole you now own.

How it works instead

Your cluster's agent already holds an outbound connection to Kaja. It opened that connection itself, to pull work and report status, and it keeps it open.

The gateway reuses it. A request for your app arrives at the gateway, travels down the connection your cluster already opened, reaches your app, and the response comes back the same way. From your network's point of view nothing has changed: there is still exactly one outbound connection and no inbound ports.

This is why a cluster in a rack behind CGNAT can serve a real domain over HTTPS without any networking work, and it is the same mechanism whether the hostname is one Kaja generated or a custom domain you attached.

What the gateway sees

The gateway terminates HTTPS. It holds the certificate, so it decrypts the request in order to route it and re-encrypts on the leg to your cluster.

That means traffic served through the gateway passes through our infrastructure in the clear at that point. It is the unavoidable cost of terminating TLS for a hostname on a machine we cannot reach, and we would rather state it than let you discover it. If that is unacceptable for a given workload, serve it directly — see below.

When your traffic does not go through it

A cluster with its own public address does not use the gateway. If your cluster can provision a load balancer or you already run an ingress controller with a public IP, requests go straight from your users to your cluster. We never see them, and they are never counted.

The gateway is per-cluster and opt-in. It exists for clusters that need it, not as a mandatory hop.

Allowances and what happens at the limit

Traffic the gateway carries counts toward your organization's gateway allowance, because it is bandwidth we pay for on your behalf. Traffic served directly by your own load balancer never counts.

Go over the allowance and gateway routing pauses until the month rolls over. Your apps keep running, and anything served through your own ingress is unaffected. Current allowances are on the pricing page.

What happens if the gateway is unavailable

Requests that depend on it stop being served for as long as it is down. This is the honest trade of the feature: you get public HTTPS from a machine with no public address, and in exchange that path depends on us.

Everything else keeps running. Your workloads, services and data are ordinary Kubernetes objects on your own hardware and do not need our control plane to keep serving. A cluster serving through its own ingress is unaffected either way.

Next steps