Skip to main content
An installation deploy lane of content-hashed, version-tagged commits with a selected Package version, a rollout advancing HEAD, an identical render that produces no commit, and a revert that restores an earlier version
Every installation on Akua has its own package repository, and every change to that package is a git commit. Versioning isn’t a separate concept: it’s the same commit history you already understand. Each commit has a SHA, an author, a timestamp, and a parent. Rolling back restores a previous repository state, usually through a reviewed change request. Comparing versions is git diff.

​
How versioning works

When Akua renders an installation (for example, after a customer changes a wizard value), it computes a content hash over the rendered manifests. If the hash matches the previous render, no commit is made. If it differs, Akua commits the new manifests and updates the installation to the new SHA. This means:
  • Every rollout is a commit. The commit SHA is what your cluster syncs to.
  • Equivalent edits don’t churn history. Changing whitespace in inputs.yaml produces no commit if the rendered manifests don’t change.
  • Identical inputs always render identically. The render is a pure function of package.k + inputs.yaml + the vendored upstream/.
The dashboard and API both expose the latest applied SHA on every installation. The dashboard’s install detail page links to the commit; the GET /v1/repositories/{id} endpoint returns it as last_deploy_sha. Every render that changes the manifests is also kept in the installation’s render history.

​
Track changes

Because the package is a normal git repository, any tool that works with git history works on it:
You can clone an installation’s repository and inspect, diff, or branch it the same way you would any other git repo.

​
Rollbacks

Roll back an installation by restoring a previous known-good repository state. In reviewed environments, prepare the rollback as a repository change request so the revert is validated and accepted before it reaches the installation. The underlying git operation is still a revert:
After the rollback change is accepted, Akua renders the new commit and converges the cluster to the reverted state. The original commit stays in history: git revert adds an inverse commit rather than rewriting the past. You can also revert by checking out an older commit, generating a fresh commit on top, and sending it through the normal review path. This is useful when reverting through a chain of changes.

​
Compare two rollouts

A common operation: “what changed between yesterday’s rollout and today’s?”
This shows the diff over package.k, inputs.yaml, and manifests/ together, covering every change that affected the installation. For just the cluster-visible diff, scope to manifests/.

​
Move to a new Package version

The selected Package version is the release unit for an installation. To move an existing installation to a newer version, create a repository change request or use the dashboard/API update path for that installation.
1

Select the version

Choose the immutable Package version you want the installation to run.
2

Review the inputs

Compare the new version’s defaults with the installation’s existing overrides.
3

Review and apply

Send the change through your normal review path. The next render uses the new Package version, and your installation-specific inputs carry through unless the change request modifies them.
Different installations can select different Package versions independently. A Product or Offer can point at a newer version, while existing installations continue tracking their selected version and repository history until you update them.

Package generation

How Akua generates packages from your sources.

Customize an installation via git

Understand direct repository edits and review paths.

Installation repositories

The git-backed model behind every installation.

Repositories API

Endpoints, parameters, and try-it playground.