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 repository 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 install rendering. 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. |
| Accepted repository change | Reviewed 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-install repositories
A product might have hundreds of installations, each with its own configuration, version pinning, and ad-hoc tweaks. The per-install repository 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 installation 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 the repository, edit
inputs.yaml, and send the change through the normal review path. Akua re-renders and rolls out after the change is accepted. - 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: prepare a
git revertand send it through the normal review path.
Related topics
Customize an installation via git
Edit inputs, patch resources, and use review paths.
Package versioning
How commit history maps to installations.
Customizing values
Multi-source values editor and overrides.
Package format
Author package.k, inputs, dependencies, and UI metadata.