← Documentation

The gateway

Most of Anyport 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 Anyport 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 Anyport. 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.

The tunnel exists before any request does, and it was dialled from inside the cluster. A request arrives at the gateway, travels down that same connection, and the response returns along it.

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 Anyport generated or a custom domain you attached.

What the gateway sees

Less than the shape of the feature suggests, and this is worth checking rather than taking on trust.

The gateway does not terminate HTTPS. It reads the server name out of the TLS handshake, which the client sends in the clear before any encryption is negotiated, looks up which cluster owns that hostname, and forwards the remaining bytes untouched. It holds no certificate for your domain, and it cannot read a request or a response.

Your cluster's own ingress terminates HTTPS, exactly as it would without us. The private key never leaves it.

Two exceptions, both structural:

  • Port 80 carries no encryption by definition. The gateway answers it directly and redirects to HTTPS.
  • ACME challenge requests are proxied through to your cluster. A certificate cannot be issued without them, and they carry a challenge token rather than any of your traffic.

What the gateway does record is how many bytes it moved, which is what the allowance below counts.

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