Skip to main content
An installation deploy lane of content-hashed, version-tagged commits with a pinned upstream version, a promote step 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:
# What changed in the last rollout?
git log -1 --stat

# What changed since last week?
git log --since='1 week ago' --oneline

# What manifests differ between two rollouts?
git diff <old-sha> <new-sha> -- manifests/
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:
git clone https://git.akua.dev/<your-org>/<install-id>.git
cd <install-id>
git revert HEAD
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?”
git diff <yesterday-sha> <today-sha>
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/.

Pin and update upstream versions

The upstream/ directory is the pinned product source for this installation. To update:
1

Bump the pin

Edit akua.toml to point at the new upstream version.
2

Re-vendor

Run akua vendor to refresh the upstream/ directory.
3

Test and commit

Commit the refreshed package state and send it through your normal review path. The next render uses the new upstream. Your edits in package.k and inputs.yaml carry through unchanged.
Different installations can pin to different upstream versions independently. There is no single “current version” of a product; each installation tracks its own.

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.