Helm chart is stuck on v0.46.0 — 20 minor versions behind latest (v0.66.1)

[yordis]

Problem

The Helm chart (1.9.0, latest) ships Netbird 0.46.0. The latest Netbird release is 0.66.1 — the chart is 20 minor versions behind.

This means users deploying via Helm are missing a large number of features and fixes that have shipped since 0.46.0, including:

• Embedded IdP (0.62+) — built-in identity provider, removes the need to run a separate Zitadel/Keycloak instance for small deployments
• External IdP registration via Management Dashboard (0.62+) — ability to add OIDC providers like Zitadel, Keycloak, Authentik directly from the UI
• netbird-mgmt token create CLI (0.62+) — allows generating proxy access tokens directly against the store without needing an existing authenticated session, which is essential for GitOps bootstrap automation
• Various bug fixes and performance improvements across 20 releases

Impact

Users deploying self-hosted Netbird via Helm cannot use any of the above features. The embedded IdP and external IdP management are now the recommended approach per the Netbird docs, but they are unavailable to Helm users.

Specifically, the missing token create CLI makes it impossible to fully automate the GitOps bootstrap of an external IdP registration. Without it, registering an OIDC provider (e.g. Zitadel) via POST /api/identity-providers requires a manually generated PAT — a manual step that breaks reproducibility in GitOps environments (ArgoCD, Flux, etc.).

Request

Please update the Helm chart to ship a recent Netbird release (0.66.x). If there are blockers preventing an update, it would be helpful to know what they are so the community can assist.

Environment

• Helm chart: 1.9.0
• Netbird bundled: 0.46.0
• Netbird latest: 0.66.1
• Deployment: Kubernetes (ArgoCD)

[EvantAiI]

Additional Feedback

1. Documentation / Examples mismatch (External IdP – Zitadel)

While configuring an external IdP (Zitadel) using the Helm chart, I noticed that the provided examples are not aligned with the current NetBird documentation:

• https://docs.netbird.io/selfhosted/identity-providers
• https://docs.netbird.io/selfhosted/identity-providers/zitadel
• https://docs.netbird.io/selfhosted/identity-providers/advanced/zitadel

In particular, the Helm chart examples (values.yaml) differ from what is described in the official documentation for Zitadel configuration.

This mismatch caused significant confusion and required several hours of trial and error. I was ultimately unable to achieve a working NetBird + Zitadel configuration following the current Helm examples.

The Zitadel application type, OIDC configuration model, and expected parameters appear to have diverged from what the Helm chart assumes, making the setup unclear and difficult to reconcile with the documentation.

It would be very helpful if:

• The Helm chart examples for external IdPs (Zitadel, Keycloak, Authentik, etc.) were updated
• The examples strictly matched the current documentation
• The recommended configuration approach was clearly reflected in values.yaml
• A tested, end-to-end working example for Zitadel was provided

Keeping Helm examples in sync with the documentation would significantly improve the self-hosted experience and reduce friction for new deployments.

---

2. Management service scalability & configuration model

It appears that the management service relies on a management.json file mounted via a ConfigMap and persistent volume.

This raises a few architectural concerns:

• The service depends on file-based configuration/state
• A volume is required to manage management.json
• This may limit horizontal scalability of the management component
• It complicates GitOps workflows (ArgoCD / Flux), since part of the configuration is file-driven rather than fully declarative via Kubernetes-native resources

Are there plans to:

• Remove the dependency on management.json?
• Make the management service fully stateless and database-backed?
• Improve scalability of the management component?

If this is outside the scope of the Helm chart repository, clarification on the intended architecture would still be appreciated.

---

Happy to help test changes or contribute if needed.

[EvantAiI]

One small additional note regarding the management Deployment:

Since it mounts a persistent volume (e.g. for management.json), using the default RollingUpdate strategy can cause multi-attach errors with ReadWriteOnce storage backends like Longhorn during upgrades (the new pod starts before the old one terminates, both trying to mount the same volume).

It would be helpful if the deployment strategy (RollingUpdate vs Recreate) was configurable via values.yaml, so users running RWO storage can avoid blocked rollouts. In the case of the management still need a volume.

[yordis]

There is a PR for it #32

[EvantAiI]

Bump
I Found this repo, but can figure out how to configure with zitadel.
But it might be useful to update netbird helm.

https://github.com/KitStream/helms

[yordis]

@bcmmbaga what can I do to help y'all?

[EvantAiI]

I’d love to contribute too but from what i’ve seen the architecture changed in 0.60.
And oidc configuration changed too netbird has now an embeded idp.
Update the chart means rework it from scratch i guess.

[marghidanu]

Hopefully, they will update the images soon. For now, adding these to the values file is working for me:

management:
  image:
    tag: "0.66.4"
...
dashboard:
  image:
    tag: "v2.34.1"

[mlsmaycon]

The current configuration should work by updating the images, but if you want to reduce the number of deployed services, you would need to move things to the Netbird-server mode.

Or maybe supporting both modes would reach more users. What do you guys think?

[EvantAiI]

I managed to get it working by updating the management and dashboard versions, thanks to @marghidanu who suggested it.

I'll also share my configuration for using ZITADEL as an IDP.

Next, I'll work on updating the chart to support the new netbird-proxy service. My plan is to first implement and validate a custom configuration on my cluster, and then port it to the chart.

It might also be worth working on the netbird-server implementation as suggested by @mlsmaycon . The chart could potentially support both modes: microservices and monolithic deployment.