ngrok Kubernetes Operator Network Egress Requirements

The ngrok Kubernetes Operator reaches ngrok over a small number of outbound connections. In most clusters this works without any extra configuration, since outbound connections on port 443 are usually allowed by default. Some environments are more restrictive. If your cluster runs under a default-deny egress policy (common on private EKS clusters and other locked-down networks), outbound traffic is blocked unless you explicitly allow it. This page lists the hostnames and ports you’ll need to allow so the Operator can start, sync your resources, and serve traffic. Every connection the Operator makes to ngrok is outbound over TLS on port 443, so your firewall only needs egress rules, not inbound ones.

ngrok’s cloud service uses a dynamic, rotating set of IP addresses that can change without notice, so you can’t allowlist it by IP. Allow traffic by hostname (FQDN) instead. This means a standard Kubernetes NetworkPolicy, which matches on IP/CIDR, isn’t enough on its own. You’ll need an egress firewall or proxy that supports FQDN-based rules, or a CNI that adds FQDN matching (such as Cilium’s toFQDNs). See ngrok IP addresses for more detail.

Required egress

Every Operator installation needs to reach these hosts:

api.ngrok.com on TCP port 443, so that the Operator can reconcile your Kubernetes resources with the ngrok API.
connect.ngrok-agent.com on TCP port 443, so that the Operator can establish its agent session and serve traffic. ngrok uses latency-based DNS and may route you to a regional connect host, so allow the whole *.ngrok-agent.com family rather than pinning a single address.

If you only expose inbound services (for example, running the Operator as a webhook gateway), these two hosts plus the image registry below are all you need. The section on endpoint bindings applies only if you turn that feature on.

Installation and upgrades

You install and upgrade the Operator with Helm, which pulls two container images from Docker Hub:

docker.io/ngrok/ngrok-operator, the image for the Operator’s deployments: the API manager, the agent, and, when endpoint bindings are enabled, the bindings forwarder.
docker.io/bitnami/kubectl, used only by the pre-delete cleanup job when you uninstall.

To pull these, allow Docker Hub’s registry and content-delivery hosts on TCP port 443:

registry-1.docker.io
auth.docker.io
production.cloudflare.docker.com

If your policy is to avoid Docker Hub entirely, mirror both images to a private registry (such as Amazon ECR) and point the image.registry and cleanupHook.image.repository Helm values at your mirror. In that case you allow your own registry instead of the hosts above.

Bitnami changed how it distributes images on Docker Hub in 2025. If you run in an air-gapped or mirrored environment, plan to mirror bitnami/kubectl (or set cleanupHook.image.repository to a kubectl image you control) rather than relying on it being pulled at uninstall time.

Endpoint bindings

Endpoint bindings are disabled by default (bindings.enabled: false), so skip this section unless you turn them on. When enabled, the bindings forwarder opens an additional connection to carry that traffic. Allow this host on TCP port 443:

kubernetes-binding-ingress.ngrok.io

The forwarder connects to the bound endpoint host your ngrok account returns, which defaults to kubernetes-binding-ingress.ngrok.io. If your account uses a different host, allow that one instead.

Verify connectivity from the cluster

To check connectivity from where your pods actually run, you can run ngrok diagnose as a Job, using the pre-built agent image. This checks name resolution, TCP, and TLS to connect.ngrok-agent.com.

ngrok diagnose only exercises the agent connect host, not api.ngrok.com or the bindings host. To check those, run a shell in the cluster and test them directly, for example curl -sv https://api.ngrok.com. The standalone agent image also checks a certificate revocation list on port 80 that the Operator itself doesn’t use, so ignore a CRL failure when you’re diagnosing the Operator.

Create a manifest file (for example, ngrok-diagnose.yaml):

apiVersion: batch/v1
kind: Job
metadata:
  name: ngrok-diagnose
spec:
  template:
    spec:
      containers:
        - name: ngrok-diagnose
          image: ngrok/ngrok:latest
          command: ["/bin/sh", "-c"]
          args: ["ngrok diagnose"]
      restartPolicy: Never

Apply it to your cluster:

kubectl apply -f ngrok-diagnose.yaml

Then check the logs:

kubectl logs -l "job-name=ngrok-diagnose"

ngrok Connectivity - Region: Auto (lowest latency)
  Name Resolution                           [ OK ]
  TCP                                       [ OK ]
  TLS                                       [ OK ]
  Tunnel Protocol                           [ OK ]
Successfully established ngrok connection! (region: 'auto', latency: 54.895145ms)

If any check fails, the host for that check isn’t reachable from the cluster. Revisit the egress rules above with your network team.

Quickstarts

Manage

Load Balancing

Usage Guides

Custom Resources

ngrok Kubernetes Operator Network Egress Requirements

Required egress

Installation and upgrades

Endpoint bindings

Verify connectivity from the cluster

​Required egress

​Installation and upgrades

​Endpoint bindings

​Verify connectivity from the cluster

Required egress

Installation and upgrades

Endpoint bindings

Verify connectivity from the cluster