Skip to main content
A package authoring loop from package files and inputs through render, preview, and installation.A package authoring loop from package files and inputs through render, preview, and installation.
Akua is the open-source packaging substrate behind Akua’s per-installation renders. Every install on Akua is an akua Package: a typed KCL program, rendered in a sandbox and pinned by digest, that turns customer inputs into Kubernetes manifests.

​
Why akua

  • Typed instead of templated. Helm values are an untyped tree parsed as YAML 1.1, and most popular charts ship no values schema. In akua, inputs, Kubernetes resources, Custom Resources and chart values are schemas, so a typo fails the render with the file and line instead of reaching a cluster.
  • Sandboxed, because charts are programs. Helm and Kustomize can read host files, make network requests and run plugins with the authority of whatever renders them. akua runs both, and the KCL runtime, as WebAssembly with no filesystem, network, environment or process access, under memory and CPU budgets.
  • Locked dependencies. Charts, CRDs and KCL modules are pinned by digest in akua.lock, with optional cosign verification.
Why typed and sandboxed → has the evidence; Typed resources → shows the workflow. You don’t have to author an akua Package by hand to use Akua. The platform can synthesize one from supported sources, such as Helm charts or container images. See Packages for the platform contract around Package versions.

​
Try it

The Package toolchain ships inside the akua CLI as akua pkg, and as the standalone akuapkg executable:
init scaffolds akua.toml, akua.lock, package.k and inputs.example.yaml, typed against Kubernetes 1.35; render writes the resulting manifests to ./deploy. The standalone akuapkg binary (brew install akua-dev/tap/akuapkg) runs the same commands without the pkg prefix.

​
What akua provides

Renders run in a WebAssembly sandbox: no network, no shell, no environment, and only a read-only copy of the Package is visible. The same inputs, lockfile and toolchain version produce byte-identical output, unless a chart asks Helm for randomness. The sandbox protects the machine that renders; what the manifests do in a cluster is still up to your policy.

​
How Akua uses akua

Akua runs akua at three points in the install lifecycle:
  1. Schema for the install wizard: Akua exports the Package’s Input schema as JSON Schema; the wizard renders from it. UI hints from @ui(...) decorators flow through as x-ui extensions.
  2. Per-install rendering: for every customer install, Akua renders the Package against the customer’s inputs.yaml, vendoring upstream deps and writing the rendered manifests into the installation repository.
  3. Version selection: when an installation moves to a different Package version, Akua renders that installation independently.

​
Where to start

Typed resources

Type every resource against a Kubernetes version and your CRDs.

Package format

Authoring package.k: the Input schema, @ui annotations, composition.

akua pkg commands

Every command, its flags, and the exit codes.

Source on GitHub

The toolchain’s source, examples, and release notes.

​
Status

Akua is alpha. The Package format and the command contract (JSON output, error codes, exit codes) are stable enough to build on; the command set still grows. Akua pins a specific toolchain version per release and bumps it deliberately.

Installation repositories

The per-install git repository that materializes a rendered Package.

Offers

How your Package’s schema drives the install wizard.

Customizing inputs

Wizard, overrides, and reviewed repository changes.

Products

Wrap a Package into a sellable product with billing.