# Devtron: a Kubernetes dashboard that also manages Helm and GitOps apps

> Devtron is an Apache-2.0 Kubernetes dashboard written in Go. It puts Helm app management, a multi-cluster resource browser, SSO and RBAC behind one interface, and it installs from a Helm chart into its own namespace.

**devtron-labs/devtron** — The only Kubernetes dashboard you need

- Repository: https://github.com/devtron-labs/devtron
- Website: https://devtron.ai
- Stars: 5,610 · Forks: 596
- Language: Go
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/devtron-labs-devtron

## What Devtron solves, and for whom

Kubernetes gives you primitives, not an operating surface. Once a team runs Helm releases in three clusters and a GitOps controller reconciles them, the questions that come up daily are not about pods. They are about which release is out of sync, what changed between staging and production, and who is allowed to roll it back. Devtron's answer is a single dashboard that reads Helm, ArgoCD and FluxCD state side by side. The README describes it as an extensible Kubernetes dashboard with "clear visibility into your Kubernetes clusters" and Helm app management "through a single, intuitive interface".

The intended user is a platform or DevOps engineer who owns the delivery path for other teams. The README lists Helm application management with rollback, drift comparison and reconciliation across environments, a resource browser for Nodes, Pods, ConfigMaps and CRDs, SSO, and fine-grained RBAC. That is a cluster-operations audience, not an application developer who only needs logs. The dashboard is one half of a larger product: the README splits the repository into a Dashboard section and a Devtron Platform section covering CI/CD, and points readers of the CI/CD material to a separate part of the page.

## How the dashboard reads your clusters

Two things in the repository make the architecture legible. The first is go.mod: Devtron depends on github.com/argoproj/argo-cd/v2, github.com/argoproj/argo-workflows/v3 and github.com/argoproj/gitops-engine. Devtron is not reimplementing GitOps reconciliation. It embeds Argo CD's libraries and renders what they report, which is why the README can claim a single pane of glass for "Helm, ArgoCD, and FluxCD applications across multiple clusters".

The second is the build. The Makefile runs wire before go build, and the repository carries Wire.go, wire_gen.go and authWire.go at its top level. Dependency injection is generated, not hand-written. The Dockerfile then copies argocd-assets into the Argo CD vendor path and copies scripts/devtron-reference-helm-charts, scripts/sql and scripts/casbin into the image. Authorization is Casbin-based, with auth_model.conf shipped alongside the binary. The practical consequence: Devtron's own state lives in a database whose schema is applied from scripts/sql, and permissions are evaluated against a Casbin model rather than being delegated entirely to the Kubernetes API server.

## Install Devtron with Helm and log in

The README's installation path assumes a Kubernetes cluster (it suggests 1.16 or higher) and a working Helm client. Devtron is installed as an operator chart into a namespace of its own, devtroncd. The README gives exactly this pair of commands:

```bash
helm repo add devtron https://helm.devtron.ai

helm install devtron devtron/devtron-operator \
--create-namespace --namespace devtroncd
```

The first command registers the chart repository. The second installs the devtron-operator chart, creating the devtroncd namespace if it does not exist. Expect a multi-component install rather than a single pod.

Once the install settles, the README retrieves the dashboard address from the LoadBalancer ingress on the devtron-service service:

```bash
kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
```

If that returns nothing, the service has no external address yet, which usually means your cluster has no load balancer implementation. The README does not document a port-forward fallback.

The login is admin, and the password is read out of the devtron-secret secret. The README distinguishes two cases by version:

```bash
kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
```

For versions below v0.6.0 the README gives the same command with the key ACD_PASSWORD instead. After logging in, the first useful action is adding a cluster and browsing its resources, then pointing the dashboard at an existing Helm release. The README does not describe a dry-run or read-only first-run mode, so the initial install is the real thing.

## Where Devtron's scope becomes a cost

Devtron is not a thin client over the Kubernetes API. It ships a database, a Casbin authorization model, generated dependency wiring and an operator chart that installs several components. The Makefile's integration target spins up docker:dind and runs a wire nil-checker script, which tells you the project itself treats wiring correctness as a build-time concern. For an operator, the trade-off is direct: you gain rollback, drift comparison and cross-cluster views, and you take on the upgrade and backup obligations of a stateful platform.

The README is silent on several things a prospective adopter would want. It does not document rollback of the Devtron installation itself, nor a backup or restore procedure for its database, nor an uninstall path. It also does not document a port-forward alternative when no LoadBalancer address is assigned, which is the common case on bare-metal clusters. None of these are disqualifying, but they are gaps you should plan around rather than discover during an incident.

The wrong-tool case is a single cluster with a handful of Helm charts and one team. There, Devtron's RBAC layer and database are overhead you maintain without gaining cross-cluster visibility. The README's own framing is multi-cluster: it repeatedly refers to applications "across multiple clusters".

## Devtron versus Argo CD on its own

The most common comparison is Devtron against Argo CD, and the repository makes the relationship unusually clear. Devtron imports argo-cd/v2 and gitops-engine as libraries. So the difference is not reconciliation behaviour, since that logic comes from Argo CD either way. The difference is the surface above it.

Argo CD presents applications it manages, with its own UI and its own RBAC model tied to AppProject and cluster scoping. Devtron presents the same underlying state plus Helm releases, a resource browser over Nodes, Pods, ConfigMaps and CRDs, and its own Casbin-backed authorization. If your fleet is already entirely Argo CD and your team is comfortable with its project model, adding Devtron means running a second control plane that reads the first. If your fleet is mixed, with plain Helm releases next to Argo CD and FluxCD applications, Devtron's premise is that one interface over all three is worth the extra component. That premise is the thing to evaluate, not the reconciliation engine.

## Licence, upgrades and what maintenance looks like

Devtron is Apache-2.0, and the README links the LICENSE file from its badge. Apache-2.0 permits commercial use and modification and includes an explicit patent grant. It does not require you to publish modifications. This is a statement about the licence text, not legal advice; if you redistribute Devtron inside a product, have counsel read the NOTICE and attribution requirements.

The repository is not archived, and its last push was on 2026-09-22. Releases in the supplied history are v2.2.0 on 2026-07-21, v2.1.1 on 2026-03-24 and v2.1.0 on 2026-03-03. That cadence suggests a minor release roughly quarterly, so budget an upgrade window at that interval rather than assuming continuous small updates.

Upgrade cost is the part the README does not cover. The Dockerfile pins its runtime base to a specific ubuntu:24.04 digest and copies scripts/sql into the image, which implies schema migrations run as part of the deployment. There is no documented rollback procedure and no documented database backup step. Before upgrading in production, capture the database yourself and read releasenotes.md and the CHANGELOG directory in the repository, which are the project's own record of what changed.

## Conclusion

Adopt Devtron if you already run Helm releases or ArgoCD and FluxCD applications across several clusters and want one RBAC-controlled interface over them. Skip it if you only need read-only inspection of a single cluster, where a plain kubectl-based view is enough. Before committing, verify that the devtron-operator chart's default components fit your cluster's capacity and that your SSO provider is one the authorization documentation covers.

## FAQ

### Is Devtron open source?

Yes. The repository is licensed Apache-2.0 and the README links the LICENSE file from its licence badge.

### Is Devtron free?

The self-hosted repository is Apache-2.0, so the software itself carries no licence fee. The README also links a separate hosted offering at license.devtron.ai/dashboard, whose terms are not described in the repository material.

### What is Devtron?

The README describes it as an extensible Kubernetes dashboard that provides visibility into clusters and manages Helm applications through one interface, with built-in RBAC and insight into workloads deployed by ArgoCD and FluxCD.

### What does Devtron do?

It manages Helm applications including rollback, compares and reconciles configuration drift across environments, and gives a single view of Helm, ArgoCD and FluxCD applications across multiple clusters, according to the README.

### How does Devtron compare with Argo CD?

Devtron depends on argo-cd/v2 and gitops-engine in go.mod, so reconciliation comes from Argo CD's libraries. Devtron adds a resource browser, Helm release management and its own Casbin-based authorization on top of that state.

## Sources

- [devtron-labs/devtron on GitHub](https://github.com/devtron-labs/devtron)
- [License: Apache-2.0](https://github.com/devtron-labs/devtron/blob/main/LICENSE)
- [Project website](https://devtron.ai)
- [README](https://github.com/devtron-labs/devtron/blob/main/README.md)
- [Releases](https://github.com/devtron-labs/devtron/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/devtron-labs-devtron