KubeVela turns a deployment plan into a workflow you can edit
The Modern Application Platform.
At a glance
- What is it?
- The platform's bet is that a delivery pipeline should be a first-class object you declare, render, and re-program, rather than a folder of shell scripts that only run in one CI system.
- Who is it for?
- KubeVela is at its strongest when a team has more than one cluster and more than one way to promote a release, because the value of a portable workflow shows up exactly there and almost nowhere else.
- 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 received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 7, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Render, orchestrate, deploy
The Highlights section names the workflow in three verbs, and the order matters. KubeVela calls itself a set of practices around rendering, orchestration, and deployment, and the claim underneath that is that a deployment plan should be a workflow object rather than a script. The README's phrasing is direct about the alternative it is displacing: no ad-hoc scripts, no dirty glue code, just deploy.
The workflow itself is powered by the Open Application Model, hosted at oam.dev. That is the oldest part of the design and the part with the most baggage. OAM describes an application as a set of components and traits, and KubeVela's application model grew out of it. Reading the current docs without that background can feel like a lot of vocabulary for what is, underneath, a typed intermediate representation between a user's intent and the Kubernetes manifests that get created.
The extendability claim is about CUE specifically. The README says you can extend or re-program workflow steps with CUE, which is a meaningful thing to offer because CUE is a configuration language with real constraints, not a templating language with string substitution. A plan that the language can check is a plan that fails before it reaches the cluster. That is the strongest argument for the design and also the one most likely to be undersold by the README, which does not explain what validation you actually get.
What pinning CUE costs and what it bought
The go.mod file is the most honest document in the repository, and it is where the real weight sits. The module line reads `github.com/oam-dev/kubevela`, and the require block includes `cuelang.org/go v0.14.1`, `github.com/crossplane/crossplane-runtime v1.16.0`, Flux's helm-controller and source-controller APIs, `github.com/chartmuseum/helm-push`, and a long tail of CLI-oriented dependencies such as survey, spinner, tcell and uitable. This is not a thin controller. It is a CLI and a controller in one binary.
CUE specifically has a history of breaking language changes between versions, and the 1.11 alpha line shows the project treating that as a real operational risk. Three separate pull requests across v1.11.0-alpha.5 and v1.11.0-alpha.6 deal with it: wiring a CUE version-compatibility engine, supporting extraEnvs on vela-core to control CUE_EXPERIMENT, and adding configurable CUE compatibility upgrade controls. Three changes, one dependency, all in the same two weeks.
That is not criticism so much as a map. If you are evaluating KubeVela, the CUE version and the compatibility flags are the knobs you will be touching, and they are exposed deliberately rather than hidden. Read them before you write the first application definition that uses anything from the CUE standard library.
One pod, half a core, a thousand applications
The README makes a specific capacity claim: minimize your control plane deployment with only one pod and 0.5c1g resources to handle thousands of application delivery. Half a CPU and a gigabyte of memory is a small number for a controller that reconciles multi-cluster state, and it is worth reading that sentence as a design target rather than a benchmark.
What the number implies is a thin control plane. Instead of running a large operator or an entire CI system in the cluster, KubeVela's core is a renderer and an orchestrator that hands off to whatever already manages the manifests. That is why the multi-cloud section can talk about progressive rollout across test, staging and production, automatic canary, blue-green and continuous verification without describing a scheduler: the platform's job is deciding what should be deployed where, not maintaining a fleet of deployment controllers.
The multi-tenancy and security section is the other half of the same story. It claims a range of LDAP integrations out of the box, enhanced multi-tenancy and multi-cluster authorization and authentication, fine-grained RBAC modules that can be customized per supply chain, and fully automated observability dashboards for the delivery process. That is a broad set of claims and the README links each to a separate documentation page on kubevela.io. The platform is not self-describing here; the docs are doing the load-bearing work.
An alpha tag published after the final release
The release list contains a detail worth pausing on. v1.11.0 shipped on 2026-07-20. v1.11.0-alpha.6 shipped on 2026-07-09, eleven days earlier. And the pull request numbers tell you why that ordering is strange: v1.11.0's notes list changes in the 6900s, while v1.11.0-alpha.6's notes list changes in the 7200s.
So work with a much higher pull request number was merged and shipped as an alpha before work with a lower number was shipped as the final release. The straightforward explanation is that the 7200-series work targeted the next cycle and was published under a 1.11.0 alpha tag, which is a naming choice rather than a mistake in release mechanics. The practical consequence is that the alpha tag is not necessarily older than the final tag, and if you are pinning versions by tag date you can end up with a build that predates or postdates what you think.
The content of the two releases also tells you something about where the project is spending attention. v1.11.0 is mostly fixes and chores: a KinD setup step in the sync-sdk workflow, a namespace check and Terraform output parsing fix in the appfile references, a GitLab reader path calculation fix, unit test coverage additions for `references/common`, `pkg/addon` and the appfile packages, a codeowners file, and a homebrew bump action. v1.11.0-alpha.5 and alpha.6 are features: a new deploy-components workflow step, the CUE compatibility engine, extraEnvs on vela-core, and a fix preserving the existing caBundle when upgrading the cluster-gateway API.
The caBundle detail is the one to remember. Preserving a certificate bundle across an upgrade of a gateway API is exactly the class of bug that only shows up in someone else's cluster, and it was fixed in an alpha.
Community plumbing and a misspelled file
The repository root is mostly process documents, and for a CNCF project that is not filler. There is a `GOVERNANCE.md`, an `ISSUE_TRIAGE.md`, a `COMMUNITY.md` pointing at Slack, DingTalk, WeChat and a meeting schedule, an `OWNERS_ALIASES` file, a `CODE_OF_CONDUCT.md`, and an `SECURITY.md` giving both a private report path and a direct address at [email protected]. The code of conduct document is a misspelled filename, `CODE_OF_CONDUCT.md` instead of conduct, which is a small thing but the kind of small thing that makes a reader wonder how carefully the rest is maintained.
The build layout is more informative. There are two Dockerfiles, `Dockerfile` and `Dockerfile.cli`, plus `Dockerfile.e2e` and a separate `entrypoint.sh`, which maps to the split between the controller image and the command line client. The Makefile lives in a `makefiles/` directory, and there is a `.goreleaser.yaml` for release artifacts and a `design/` directory for proposals.
Vela templates sit in their own top-level directory, `vela-templates/`, which is a hint about where the extensibility story lives: the default definitions are part of the repository, not fetched at install time. Addons live separately on kubevela.io as a catalog, and the tree also carries `.krew.yaml`, so KubeVela installs itself as a kubectl plugin the same way Krew installs other tools. That is a nice touch for a CLI this heavy: once installed, `vela` is available through the same mechanism as the rest of your cluster tooling.
Editorial conclusion
KubeVela is at its strongest when a team has more than one cluster and more than one way to promote a release, because the value of a portable workflow shows up exactly there and almost nowhere else. The parts worth knowing before you commit are unglamorous: the Go module still answers to the oam-dev path, the CUE engine is versioned separately enough to have its own compatibility controls added in the 1.11 alpha line, and an alpha tagged after the final release is the normal shape of their process rather than an accident. Start with the quick start on kubevela.io, install one addon, and see whether the render step earns its place in your own pipeline before designing around it.
Frequently asked questions
What problem does KubeVela solve that a CI pipeline does not?
KubeVela's argument is about portability rather than automation. A delivery plan is declared as a workflow object and powered by the Open Application Model, with steps reprogrammable in CUE, so the same plan can run under different CI or GitOps systems instead of living in one vendor's script directory. The README frames this as replacing ad-hoc scripts and glue code.
How much capacity does the KubeVela control plane need?
The README states that a single pod with 0.5 CPU and 1 gigabyte of memory can handle thousands of application deliveries. Treat that as a design target for a thin control plane rather than a measured result, since the repository does not publish a benchmark behind the number.
Which version should I install, and what does the CUE dependency imply?
v1.11.0 shipped on 2026-07-20, and the go.mod pins cuelang.org/go v0.14.1. Because CUE has changed language behavior across releases, the 1.11 alpha line added a CUE version-compatibility engine, configurable compatibility upgrade controls, and extraEnvs on vela-core for controlling CUE_EXPERIMENT. Check those settings for your version before relying on CUE library behavior.
How does KubeVela compare with Argo CD or Crossplane?
The go.mod file is the clearest hint: KubeVela depends on crossplane-runtime and on Flux's helm-controller and source-controller APIs, so it composes with the GitOps and cloud-resource ecosystem rather than replacing it. Argo CD style reconciliation is what KubeVela hands manifests off to, while Crossplane runtime is what its cluster management builds on.
Can KubeVela be installed as a kubectl plugin?
The repository root contains a `.krew.yaml` file, the same manifest format Krew uses to publish plugins, so the KubeVela CLI can be installed through the kubectl plugin mechanism. The CLI and the controller ship from separate Dockerfiles, so installing the plugin does not deploy the control plane.
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/kubevela-kubevela)