Understand the git repository behind an installation: change inputs, override resources, and roll out reviewed updates
Every installation you create on Akua gets its own private git repository. Cloning it gives you version-controlled access to the install configuration: the inputs your customer set in the wizard, the rendered Kubernetes resources, and the upstream package source. A repository change becomes live after it passes through the install’s normal review and render path.Most customers never need to touch this. The dashboard wizard and the values editor cover the common cases. The git repository is the escape hatch for the moments where you need to do something the UI doesn’t expose: patch a resource, add a sidecar, swap an image registry, or pin a version.This page covers what to edit and how those edits affect the install. When a change should be reviewed before it lands — an agent’s fix, a partner’s update, or an automated bump — prepare it through a repository change request.
Open your installation in the dashboard. The Source tab shows the clone URL and the latest applied commit.
# The URL has the form https://git.akua.dev/<workspace-org>/<install-id>.gitgit clone https://git.akua.dev/your-org/your-install-id.gitcd your-install-id
The repository requires authentication. Your dashboard token works as the password; use any string for the username.
The repository is private and isolated to your workspace. Only authorized workspace members can clone it or submit changes.
You’ll edit inputs.yaml (the wizard values) for everyday changes and package.k (composition logic) for advanced ones. manifests/ is rendered output; never edit it. akua.toml and the vendored upstream/ copy round out the layout. For the full file-by-file breakdown and who owns each file, see Installation repositories.
Edit inputs.yaml, commit, and send the change through your normal review path.
# Bump the replica count$EDITOR inputs.yamlgit commit -am "scale replicas to 5"
After the change is accepted, Akua re-renders manifests/ from the new inputs and rolls out the change to your cluster. The installation status updates as the cluster converges.
When inputs.yaml doesn’t expose what you need, edit package.k. The composition layer lets you patch any field on any resource without forking the upstream package.
# package.k — example: add a node selector to every Deployment_patched = [r | { if r.kind == "Deployment": spec.template.spec.nodeSelector: { "node-pool": "high-memory" }} for r in _upstream]
Commit the patch and send it through your normal review path. The change rolls out after it is accepted.
The repository is a normal git history. Roll back by reverting:
# Roll back to the previous applied commitgit revert HEAD
Send the revert through the same review path you use for other installation changes. Akua re-renders after the rollback is accepted, and the cluster converges to the reverted state.
manifests/ is regenerated whenever Akua accepts and renders a repository change; never edit it by hand. inputs.yaml can be rewritten when a customer changes wizard values from the dashboard, so put changes that must survive customer edits in package.k. package.k, akua.toml, and upstream/ are never overwritten. See how the repository stays in sync for the full model.