Feb 25, 2026
ngrok-operator v0.22.0: multiple installs and clean uninstalls
I’m excited to announce the release of version 0.22.0 of the
ngrok-operator Helm chart. This
release brings support for running multiple operator installations in a single
cluster, a standalone CRD chart, and a comprehensive uninstall system that
eliminates the stuck-finalizer issues you may have ran into when iterating on
installations locally.
Standalone CRD chart
By default, the ngrok-operator bundles its
CRDs in the Helm release—one
helm install and you’re up and running. We still default to this for
simplicity.
With this release, you can also install CRDs separately using the new
ngrok-crds chart. This decouples the CRD lifecycle from the operator, which is
required for multiple installations and
gives you more control over upgrades and uninstalls:
If you have an existing installation and want to migrate, see the migration guide.
Multiple operator installations
With CRDs split out, you can now run multiple instances of the operator in a
single cluster. Each installation is scoped to watch a specific namespace using
ingress.watchNamespace, so operators only reconcile resources within their own
namespace.
This unlocks self-service workflows where each team gets their own namespace with its own operator installation, managing their own ngrok resources independently.
Here’s a full example installing two operators, one per team namespace:
Now creating an Ingress or CloudEndpoint in the team-a namespace will only
be reconciled by team A’s operator, and likewise for team-b. Resources in a
namespace without a corresponding operator will not be reconciled.
For the full walkthrough including ingress class scoping and migration from a single installation, see the multiple installations guide.
Clean uninstalls
If you’ve ever had resources stuck in Terminating after a helm uninstall and
found yourself manually patching
finalizers, this one’s for you.
With 0.22.0, we’ve added a pre-delete Helm hook that handles all of that
automatically. It signals the operator to stop reconciling, then removes
finalizers from all custom resources so the uninstall can proceed cleanly.
We’ve also introduced a drainPolicy setting that lets you control what happens
to your ngrok API resources during uninstall:
-
Keep(default): Removes finalizers and lets Kubernetes clean up, but preserves resources in your ngrok account. This is the safe default for production — if you accidentally uninstall the operator, yourCloudEndpoints and other cloud resources continue serving traffic. You can manage them through the ngrok Dashboard or reinstall the operator to resume managing them. -
Delete: Deletes each custom resource and waits for the operator to clean up the corresponding ngrok API resource before proceeding. This is useful when you’re iterating locally and want a clean slate between install/uninstall cycles.
To use the Delete policy, upgrade your release before uninstalling:
For the full details including multi-operator uninstall ordering and troubleshooting, see the uninstall guide.
This release also includes a number of bug fixes and reliability improvements. For the full list of changes, see the Helm chart changelog and controller changelog. If you have feedback about ngrok-operator or hit what you might think is a bug, you’re welcome to create an issue in the ngrok/ngrok-operator repo.