> ## 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.
# Package generation
> How Akua turns your product configuration into a per-install repository
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:
| 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 vendored copy of the selected Package version's source. | Rare (reviewed version updates) |
| `manifests/` | The rendered Kubernetes resources. Your cluster pulls from here. | Never (regenerated) |
| `akua.toml` | Package metadata: name, version, dependencies. | Rare |
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
| 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. |
| Package version update | Select the new Package version through the dashboard, API, or a repository change request; the next render uses the new version. |
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](/installs/install-repo) guide for end-to-end examples.
## Related topics
Edit inputs, patch resources, and use review paths.
How commit history maps to installations.
Multi-source values editor and overrides.
Author package.k, inputs, dependencies, and UI metadata.