Kusion splits platform work into Day 0 modules and Day 1 apps

One specification, no environment values

The What is Kusion section names the role before describing the software: an intent-driven Platform Orchestrator, sitting at the core of an Internal Developer Platform. Both terms link out to internaldeveloperplatform.org, which tells you the project is positioning itself against a category rather than an incumbent.

The mechanism is one file. Application developers write a single application specification, an AppConfiguration, which defines the workload and all resource dependencies without needing to supply environment-specific values. Kusion's job is to ensure it provides everything needed for the application to run. That is the entire product thesis: the developer writes intent, the platform fills in the environment.

Whether that division works depends on your organization rather than on Kusion. The README is careful to say the two roles, application developers who create applications and platform engineers who maintain the infrastructure those applications run on, may overlap or align differently in your organization, and that Kusion is intended to ease the workload for either. That hedge is fair, since the design assumes the roles are distinct enough that a hand-off exists.

The project is also a CNCF Sandbox project, has a Helm chart on Artifact Hub, and publishes in English, Chinese and Hindi. The Hindi README is an unusual detail and a fair signal about where the contributors are.

Day 0 and Day 1 as two separate jobs

The README names two key workflows, and the naming comes from platform engineering convention rather than from the code.

Day 0 is set up the modules and workspaces. Platform engineers create shared modules for deploying applications and their underlying infrastructure, plus workspace definitions for the target landing zone. These standardized shared modules codify the requirements of stakeholders across the organization including security, compliance and finance, which is the sentence that describes the real job. The hard part of Day 0 is not writing Terraform or writing KCL; it is getting security, compliance and finance to agree on one answer and encoding it once.

Day 1 is set up the application. Application developers leverage the workspaces and modules created by the platform engineers, and the platform team keeps maintaining them, which lets application developers build on standardized infrastructure through a repeatable process.

The module abstraction is what makes the self-service model work. Modules abstract the complexity of underlying infrastructure tooling so app developers deploy using a self-service model, which means the platform team owns the tooling and the developer owns the application. If your platform team has not written the modules, this division collapses into the same problem as any other internal platform that shipped before its consumers were ready.

Kusion Server and the portal

Starting with v0.14.0 the project introduced Kusion Server with a Developer Portal. The README describes it as a long-running service providing the same set of functionalities as the Kusion CLI, with additional capabilities to manage application metadata and visualized application resource graphs. It manages instances of Projects, Stacks, Workspaces and Runs centrally, through the portal and a set of RESTful APIs for other systems to integrate with.

That is a genuine change in shape for the project. Before v0.14.0 the orchestrator was a CLI you ran. After it, there is a server that other things can call. The getting-started path for it is two documentation pages: an installation guide, then a quick start for deploying a first application. The README includes one operational warning that is easy to skim past, which is that you need to configure kubeconfig properly according to the guide, since Kusion Server requires access to a Kubernetes cluster to function properly.

The repository reflects the split in its build. The Dockerfile builds the portal with Node before the Go binary, and the Makefile has an explicit switch for it, with the comment that the flag controls the portal building process:

ifndef SKIP_BUILD_PORTAL
	BUILD_PORTAL = build-portal
else
	BUILD_PORTAL =
endif

There is also a separate `Dockerfile_kusionctl` in the tree, so the CLI and the server are buildable as distinct artifacts. The `ui/` directory is a separate frontend project compiled into the Go binary's output, which is why the build cannot simply be a `go build`.

A dependency list that spans four clouds

The go.mod is the document that most directly answers whether you should try this. The module is `kusionstack.io/kusion` on go 1.22.1, and the require block pulls in Google Cloud's secret manager, Azure's SDK for Go alongside the older autorest packages, the Aliyun OSS SDK, and both generations of the AWS SDK with a config package and a secretsmanager service client. It also pulls chi and its JWT and CORS and logging middleware, a set of Flux packages for sourceignore and tar, and a collection of test helpers including go-sqlmock and bytedance/mockey.

Two SDK generations for AWS at once is the detail that tells you about the project's age and intent. It is not a library that talks to one provider; it is a binary that can provision across several, and the dependency cost of that is real. The same is true of the Dockerfile, which installs python3, python3-pip and git into an Ubuntu 22.04 base, and sets a KCL path in the environment, because KCL is a dependency at build and run time rather than an optional extra.

The Makefile shows the other half of the story. Builds run inside a container image called kusionstack/kclvm-builder, with the host's ssh keys, gitconfig and module cache mounted in, and the file carries a `TODO: fix mirrors` comment next to an empty mirror variable. Formatting and linting are pinned to specific tool versions, gofumpt v0.2.0 and golangci-lint v1.56.2, which is the kind of detail that matters if you plan to contribute and fight with a different linter version.

One release in 2025, commits since

The release record is short and worth stating plainly. v0.14.0 shipped on 2025-01-22 and is where Kusion Server arrived. v0.14.1-rc.0 followed on 2025-06-03, a release candidate whose notes are mostly chores: a cron e2e test, an SDK bump from 1.1.4 to 1.1.5, an npm build fix, and a retry for link checking on 429 responses. v0.15.0 published on 2025-06-30 as the newest release, with the Docker image kusionstack/kusion:0.15.0 listed at the top of the notes.

The v0.15.0 features are small and specific: implement variable, handle empty stack in preview, add an interface called SetSecret in the secrets provider. The bug fixes are more informative about where the sharp edges were, including an apply failure that would cause release state to become completely empty, and a circular dependency in resource handling. A tool that manages state across clouds finding that an apply failure can wipe its own release state is the kind of bug that shapes an operator's trust, and it was fixed in the same release that added a secrets interface.

Meanwhile the repository itself was pushed to on 2026-09-17, so work has continued well after the last tagged release. There are 1,319 stars, 107 forks and 56 open issues. The honest reading is that this is an active project on an infrequent release cadence, not an abandoned one, and if you depend on it, plan for a build from source rather than assuming a recent tag.

Editorial conclusion

Kusion is trying to solve a problem that most orchestrators approach from the other direction, by starting from a fully specified application and pushing environment differences down into overlays. Starting from the platform side instead means the value only appears once your organization has agreed what its modules and workspaces are, and the payoff is proportional to how much your landing zones actually differ. The practical things to weigh are the dependency footprint, which reaches into four cloud providers' secret stores, and the release record: the newest published version, v0.15.0, shipped on 2025-06-30, while commits have continued on the repository since, so the code is moving and the released artifact is a year old. Read the Day 0 quick start on kusionstack.io before the Day 1 one, because a Kusion install without modules is just a longer way to run kubectl.

Frequently asked questions

Official sources

1. KusionStack/kusion on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases