Skip to main content
A render that compiles a selected Package version and wizard inputs through package.k composition into a set of Kubernetes manifest resources
When a customer installs your product, Akua generates a self-contained repository for that specific installation. The repository combines your product’s source, the customer’s wizard inputs, and the rendered Kubernetes resources. It is the install 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 repository and evolves independently as customers configure their installs.

​
What gets generated

For every installation, Akua creates a private git repository with this layout: When inputs change through the dashboard wizard, the API, or an accepted repository change request, Akua re-renders manifests/ and commits the result. Your cluster picks up the new commit and converges.

​
Self-contained by design

The repository vendors its upstream source under upstream/. This means:
  • Reproducible. Re-rendering the same inputs.yaml against the same upstream/ 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.
If the upstream source disappears tomorrow, your installations keep working. You can publish a new Package version on your own schedule.

​
When packages are generated

The render is idempotent: if your edit produces byte-identical manifests, no commit is made and no rollout is triggered.

​
Why per-install repositories

A product might have hundreds of installations, each with its own configuration, selected Package version, and ad-hoc tweaks. The per-install repository model means:
  • Customer A can stay on last month’s Package version 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.
You don’t manage this complexity manually. Akua generates the right repository for each installation; you only intervene when you want to.

​
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.k to add or modify fields on rendered resources.
  • Add resources: append to the _extras list in package.k to ship resources the upstream doesn’t include.
  • Roll back: prepare a git revert and send it through the normal review path.
See the Customize an installation via git guide for end-to-end examples.

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.