When a customer installs your product, Akua generates a self-contained package for that specific installation. The package combines your product’s source, the customer’s wizard inputs, and the rendered Kubernetes resources into a private git repository. The repository is the deploy target: your cluster reads from it, your team can edit it, and every change ships with a commit history. This is different from a one-time chart build. Each installation has its own package, lives in its own repository, and evolves independently as customers configure their deployments.Documentation Index
Fetch the complete documentation index at: https://akua-1dce587a.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
What gets generated
For every installation, Akua creates a private git repository with this layout:| Path | Contents | Editable? |
|---|---|---|
package.k | Composition logic that turns inputs into Kubernetes resources, applies install-scoped labels, and can patch any field. | Yes (advanced) |
inputs.yaml | The wizard values your customer set. Re-rendering reads from here. | Yes (everyday changes) |
upstream/ | A pinned copy of the product’s source package, the same version used to render every install of this product. | Rare (version pinning) |
manifests/ | The rendered Kubernetes resources. Your cluster pulls from here. | Never (regenerated) |
akua.toml | Package metadata: name, version, dependencies. | Rare |
manifests/ and commits the result. Your cluster picks up the new commit and converges.
Self-contained by design
The package vendors its upstream source underupstream/. This means:
- Reproducible. Re-rendering the same
inputs.yamlagainst the sameupstream/always produces identical manifests. - Offline-capable. No external fetches happen during deployment. Whatever the upstream looked like at provision time is what ships.
- Audit-friendly. Every byte that ends up in your cluster is committed and signed.
When packages are generated
| Event | What happens |
|---|---|
| New installation | A new repository is created, the upstream is vendored, the wizard inputs are written, and the first render is committed. |
| Wizard edit | inputs.yaml is updated, manifests are re-rendered, and a new commit is pushed. |
| Direct git push | Your edits to package.k or inputs.yaml trigger a re-render on the same repository. |
| Upstream version bump | Update akua.toml’s upstream pin and re-vendor; the next render uses the new version. |
Why per-installation packages
A product might have hundreds of installations, each with its own configuration, version pinning, and ad-hoc tweaks. The per-installation model means:- Customer A can pin to last month’s upstream while Customer B runs the latest, with no special handling on your side.
- A patch you make for Customer A stays scoped to their repository, with no risk of affecting other customers.
- Each customer’s deployment history is a normal git log they can audit, branch, or roll back independently.
Working with the generated package
Most of the time you don’t touch it directly. The dashboard wizard handles inputs, and Akua handles rendering. For the cases where the UI doesn’t expose what you need:- Edit inputs in YAML: clone, edit
inputs.yaml, push. Akua re-renders and rolls out. - Patch resources: edit
package.kto add or modify fields on rendered resources. - Add resources: append to the
_extraslist inpackage.kto ship resources the upstream doesn’t include. - Roll back:
git revertand push.
Related topics
Customize an installation via git
Edit inputs, patch resources, push commits.
Package versioning
How commit history maps to deployments.
Customizing values
Multi-source values editor and overrides.
Application sources
Where your packaged source comes from.