← Back to Blog

The Kaja Team

Serve public traffic from a private server, without opening a port

Keep every inbound port closed and still run a real site on a real domain. How an outbound-only agent and a managed gateway make that work.

Plenty of teams would rather not expose a Kubernetes API server or an ingress controller to the internet. That instinct is correct — every open port is something to scan, and something to patch. The problem is what usually follows: you can no longer easily manage the cluster from outside, or serve traffic from it, so you end up with a VPN, a bastion host, or a set of firewall rules nobody wants to touch.

Kaja takes a different route. The cluster never accepts an inbound connection at all.

The agent dials out

You install an agent, and it opens an outbound connection to Kaja and keeps it. Commands, state, logs, and metrics all travel over that channel. From the outside there is nothing listening: no public API server, no exposed ingress, no port to find. A scanner sweeping your IP range has nothing to talk to.

This is the same reason the install is one command. There's no firewall rule to negotiate with your network team, because there's no inbound path to open.

Public HTTPS from a machine with no public IP

The part teams usually give up on is serving real traffic from a private machine. It's why so many internal tools end up behind a VPN that everyone complains about.

Kaja's gateway solves it from the same direction. Traffic arrives at the gateway, then travels to your app over the connection the agent already holds open. The result is that a server sitting behind NAT with every inbound port closed can still serve a real site, on your own domain, over HTTPS, with certificates issued and renewed automatically.

If your server does have a public load balancer, you don't need any of this — publish through it directly. That traffic never passes through us, and it's never metered.

Who can do what

Network posture is only half of access control. Admin, editor, and viewer roles scope what each person can touch, and changes are recorded, so "who deployed that" has an answer. Because everything goes through one control plane, that's one place to define roles rather than a per-cluster RBAC config that drifts.

The trade-off, stated plainly

An outbound-only design means your servers depend on a connection to us to be managed and, if you use the gateway, to serve gateway traffic. In exchange, you close every inbound port. We think that's the right trade for most teams — and if it isn't for yours, everything Kaja creates is a standard Kubernetes object, so your workloads keep running regardless.