> ## Documentation Index
> Fetch the complete documentation index at: https://docs.akua.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Akua

> The packaging substrate behind every Akua installation

<Frame>
  <img className="block dark:hidden" src="https://mintcdn.com/akua-0b861dc6/o-ywDlh24ZayP_tj/images/heros/akua-index-light.svg?fit=max&auto=format&n=o-ywDlh24ZayP_tj&q=85&s=868d2192db82c0d2aef6fc7874584cd5" alt="A package authoring loop from package files and inputs through render, preview, and installation." width="1536" height="864" data-path="images/heros/akua-index-light.svg" />

  <img className="hidden dark:block" src="https://mintcdn.com/akua-0b861dc6/o-ywDlh24ZayP_tj/images/heros/akua-index-dark.svg?fit=max&auto=format&n=o-ywDlh24ZayP_tj&q=85&s=c6529dc9c2269347b63c374b21c17f28" alt="A package authoring loop from package files and inputs through render, preview, and installation." width="1536" height="864" data-path="images/heros/akua-index-dark.svg" />
</Frame>

[Akua](https://github.com/akua-dev/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 →](/akua/why) has the evidence; [Typed resources →](/akua/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](/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:

```bash theme={null}
brew install akua-dev/tap/akua
akua pkg init hello && cd hello
akua pkg render --inputs inputs.example.yaml
```

`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

| Surface | Purpose |
| - | - |
| **`package.k`** | Install composition: KCL logic that turns inputs into Kubernetes resources |
| **`akua.toml` + `akua.lock`** | Pinned dependencies (Helm charts, other Packages, KCL modules, CRDs), digest-locked and optionally cosign-verified |
| **Typed resources** | The Kubernetes schemas of one pinned version, plus schemas generated from CRDs under `.akua/crds/` |
| **`akua pkg render`** | Executes the Package against inputs and writes deploy-ready manifests |
| **`akua pkg export`** | Emits the Package's input schema as JSON Schema 2020-12 or OpenAPI 3.1 |
| **`akua pkg publish`** | Packs the Package and pushes it to an OCI registry, cosign-signed and attested when a signing key is configured |

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](/installs/repositories).
3. **Version selection**: when an installation moves to a different Package version, Akua renders that installation independently.

## Where to start

<CardGroup cols={2}>
  <Card title="Typed resources" icon="shield-halved" href="/akua/typed-resources">
    Type every resource against a Kubernetes version and your CRDs.
  </Card>

  <Card title="Package format" icon="cube" href="/akua/package-format">
    Authoring `package.k`: the `Input` schema, `@ui` annotations, composition.
  </Card>

  <Card title="akua pkg commands" icon="terminal" href="/akua/cli">
    Every command, its flags, and the exit codes.
  </Card>

  <Card title="Source on GitHub" icon="github" href="https://github.com/akua-dev/akua">
    The toolchain's source, examples, and release notes.
  </Card>
</CardGroup>

## 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.

## Related topics

<CardGroup cols={2}>
  <Card title="Installation repositories" icon="folder-tree" href="/installs/repositories">
    The per-install git repository that materializes a rendered Package.
  </Card>

  <Card title="Offers" icon="link" href="/marketplace/offers">
    How your Package's schema drives the install wizard.
  </Card>

  <Card title="Customizing inputs" icon="sliders" href="/customizing-values">
    Wizard, overrides, and reviewed repository changes.
  </Card>

  <Card title="Products" icon="box" href="/products">
    Wrap a Package into a sellable product with billing.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.