Erda: a Kubernetes application platform with DevOps, APM and multi-cloud management
An enterprise-grade Cloud-Native application platform for Kubernetes.
At a glance
- What is it?
- Erda bundles CI/CD pipelines, service governance, monitoring and cluster management into one Kubernetes platform. The repository is a Go monorepo with a React UI split into a separate repo, and the README points elsewhere for installation.
- Who is it for?
- Erda fits teams that want pipelines, APM, log analysis and multi-cloud cluster management behind one Kubernetes-native control plane and are willing to run several stateful dependencies alongside it. It is a poor fit if you only need a CI runner or a single-cluster deploy tool, because the platform assumes you want the whole set.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 24, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem Erda targets: one control plane for build, deploy and diagnose
Most Kubernetes teams end up assembling the same stack by hand: a CI system, an image registry, a deployment tool, a metrics backend, a log store, an APM agent and a gateway. Each one has its own configuration model and its own notion of an environment. Erda's pitch is that these are one product. The README describes it as an "enterprise-grade Cloud-Native application platform" providing DevOps, microservice governance and multi-cloud management, and the functional architecture lists DevOps, microservice governance (APM, monitoring, log analysis, API gateway), multi-cloud management, edge computing and FastData management as the parts.
The intended user is a platform team at a company running microservices across more than one Kubernetes cluster, where developers need a self-service path from commit to running service. Erda is not a library you import. It is a set of backend services you operate, plus a separate web portal. The README points at erda-ui as the graphical portal, built in React, talking to the backend over RESTful APIs. If you do not want to run and upgrade a platform, the project has nothing for you.
Repository layout: one Go monorepo plus six sibling repos
The core repository is the backend. The README states it implements all the RESTful and gRPC interfaces of the Erda platform through multiple components in a microservice architecture. The top-level directories match that: cmd/ holds the service entry points, internal/ and pkg/ hold implementation and shared code, api/ and apistructs/ hold interface definitions, conf/ holds configuration, and bundle/ holds packaging.
The rest of the platform lives in separate repositories, and this matters when you plan an upgrade. erda-ui is the portal. erda-proto defines part of the inter-service protocol using Protocol Buffers, with the README noting that other protocols will be migrated there "in the near future", which tells you the protocol layer is still partly ad hoc. erda-infra is a Go microservices framework providing middleware providers such as Redis, Kafka and etcd, and the README says it is integrated into almost all backend components. erda-actions holds the definitions behind the official Pipeline Actions, where an action is the minimal runnable unit in an Erda pipeline, such as checking out source or building an image. erda-addons holds middleware and third-party service configurations that can be shared across application environments.
There is a second tier of repositories the README calls customized third-party independent components: erda-proto-go for generated protobuf code, erda-analyzer for streaming aggregation of metrics and alert data, erda-java-agent for APM, a telegraf fork, kubeprober for large-scale cluster diagnostics, a beats fork, remotedialer for reverse tunneling, and erda-bot for GitHub webhooks. A deployment therefore spans code from many repositories, not one.
Installing Erda: releases, Helm and the local Docker path
The README does not contain install commands. It gives two routes. For a local trial, Quick Start links to the Local installation page at docs.erda.cloud, specifically the docker-install guide. For anything real, the Installation section says Erda can be deployed in a single node or multi-node setup, and directs you to download binaries from the Erda release page and follow the Installation & Configuration Guide, which is a Helm-based guide. The repository itself carries a VERSION file and a Makefile, so building from source is possible, but the README does not present that as the supported path for operators.
Because the README gives no commands, the only addresses it supplies are the documentation pages themselves:
# Quick Start -> Local installation (docker-install)
# https://docs.erda.cloud/latest/manual/install/docker-install.html
# Installation -> Installation & Configuration Guide (helm-install)
# https://docs.erda.cloud/latest/manual/install/helm-install/introduction.htmlFollow the Helm guide for a single node or multi-node cluster, and treat the version of the guide and the version of the release as a matched pair. Use the Docker page if you want to see the portal before committing a cluster.
The Makefile is where a source build is defined. It derives APP_NAME from BUILD_PATH under cmd/ and injects version metadata through ldflags into the package github.com/erda-project/erda-infra/base/version, and it defines ERDA_VERSION by truncating the full version to MAJOR.MINOR. The comment in the file explains that this is done because buildpack and other things break otherwise, which is a useful signal: the platform version and the component version are deliberately not the same string. The Makefile's own variables are the ones to set when building a component, and it is the file to read before attempting a build, since the README does not document one.
Where Erda is the wrong tool
The first limitation is that Erda is a platform, not a component. If your need is a pipeline runner for one repository, or a Helm wrapper for one cluster, you are adopting a large surface area to solve a small problem. The README's own framing, DevOps plus governance plus multi-cloud plus edge plus FastData, is the honest description of the scope you are signing up for.
The second is version drift between the tagged releases and the default branch. The most recent release in the repository is v2.2.0, published on 2022-06-30, following v2.1.0 on 2022-05-13 and v2.0.0 on 2022-03-09. The default branch was last pushed on 2026-09-09. Anyone installing from the release page is installing code from 2022, while the repository continues to move. The README does not document an upgrade path between these, and it does not document rollback at all.
The third is operational cost. The go.mod file lists clients for ClickHouse, Kafka via IBM/sarama, Redis, etcd and Alibaba Cloud services including SLS, OSS, MNS and MSE, plus a RocketMQ client under erda.cloud/rocketmq. Those are not incidental imports. A functioning installation has stateful dependencies to run, back up and size. The README does not publish minimum resource requirements, so you cannot budget from the repository alone.
Finally, there is a licensing wrinkle worth noticing before you plan a fork. The repository is Apache-2.0 per the README and the LICENSE file, but the Makefile header carries the GNU Affero General Public License, version 3 or later. Header text and repository licence disagree, and a file-level header is not the same as the project licence. If you intend to redistribute modified builds, read the LICENSE file and the individual file headers rather than assuming one of them wins.
How Erda differs from Backstage and from plain Argo CD plus Prometheus
The closest comparison in kind is Backstage, the developer portal. Backstage is a framework: you assemble a catalogue, and plugins for CI, deployment or observability are things you wire in yourself, often against APIs you already run. Erda ships the capabilities as backend services with their own storage and their own UI, and the README describes the portal as talking to those services over RESTful APIs. The practical difference is where the integration work sits. With Backstage you write the glue and choose every backend. With Erda the glue is in the repository, but you inherit its choices, including the middleware clients in go.mod and the multi-repository release cadence.
Against a hand-rolled Argo CD plus Prometheus plus Loki stack, the difference is the application model. Erda is application-centric: erda-addons exists so that a middleware configuration such as MySQL or Redis can be shared across the environments of an application, and the README says this is so developers do not import the same configuration again and again. That is a genuine convenience the raw Kubernetes tooling does not give you, because Argo CD tracks manifests and Prometheus tracks time series, and neither has a concept of an application with environments and shared addons. The cost is that you now run Erda's own services on top of the cluster you are managing.
Maintenance and upgrade cost
The repository is not archived, and the last push to the default branch was on 2026-09-09. That is recent, so the codebase is receiving changes. It does not follow that there are releases: the newest tag is v2.2.0 from 2022-06-30. For an operator, that gap is the central maintenance fact. Either you run the 2022 release and accept that fixes since then are unreleased, or you build from the default branch and accept that you are running untagged code with no documented rollback.
Upgrade cost also scales with the repository split. A version of the platform spans erda, erda-ui, erda-proto, erda-infra, erda-actions and erda-addons, plus the tier of independent components. There is no single artefact in the README that pins all of them together. The CHANGELOG directory exists in the repository, and it is the place to check what changed between versions, but the README does not describe a supported upgrade procedure.
On licensing, the README states Erda is under the Apache 2.0 license and points to the LICENSE file. The Makefile header states AGPL v3 or later. Those are materially different terms, particularly for anyone offering the software as a network service. This is not legal advice, and the resolution depends on which files carry which header, so read LICENSE and the file headers in the components you actually redistribute before you commit to a redistribution model.
Editorial conclusion
Erda fits teams that want pipelines, APM, log analysis and multi-cloud cluster management behind one Kubernetes-native control plane and are willing to run several stateful dependencies alongside it. It is a poor fit if you only need a CI runner or a single-cluster deploy tool, because the platform assumes you want the whole set. Before adopting, verify the version you intend to run: the newest tagged release in the repository is v2.2.0 from 2022-06-30, while the default branch was pushed on 2026-09-09, so the tagged artefacts and the current code are years apart.
Frequently asked questions
What does Erda stand for?
The repository does not expand the name into an acronym. The README presents Erda as the project name and describes it as an enterprise-grade cloud-native application platform created by Terminus.
What is Erda used for?
According to the README, Erda provides DevOps, microservice governance and multi-cloud management on Kubernetes, with functions covering pipelines, application performance management, monitoring, log analysis, an API gateway, edge computing and FastData management.
How much does Erda cost?
The repository does not state a price. Erda is distributed under the Apache 2.0 license per the README, so the software itself is obtained from the release page or the documentation site rather than purchased.
What does the name Erda mean?
The repository does not give a meaning or etymology for the name. The README uses Erda only as the project name for the platform created by Terminus.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/erda-project-erda)