Operate an installation

An installation keeps running after the first deploy. This page is for operators who need to answer four questions quickly: what is running, is it healthy, what changed, and how do we safely change it again? Use the dashboard for the common path, or use the API when you need automation. The same underlying installation model powers both.

​

Start with status

The installation status is the fastest way to tell whether the cluster matches the installation repository. Check:

• State: whether the installation is pending, rendering, syncing, healthy, degraded, failed, or deleted.
• Health: whether rendered resources are healthy or still settling.
• Sync: whether the cluster is converged to the latest accepted repository revision.
• Revision: the commit SHA the cluster is currently running.
• Reconciling: whether Akua is actively rendering or applying a change.

For the full state model, see Installation lifecycle.

​

Inspect pods and logs

When status says an installation is degraded, inspect the live workload:

• Use Pods to see the current pods and containers for the installation.
• Use Logs to stream output from all pods, or narrow the stream to one pod when the failing workload is obvious.

Logs come from the running installation. They can include whatever your application writes to stdout or stderr, so avoid logging secrets or customer data.

​

Review what changed

Every installation has a private git-backed repository. That repository stores the package definition, inputs, vendored source, and rendered manifests that explain what the cluster is trying to run. Use the repository history when you need to compare two rollouts, audit a customer-specific change, or understand why a render produced different manifests. See Installation repositories and Package versioning.

​

Make changes safely

Sensitive changes should go through a repository change request. A change request prepares edits in a managed fork, validates them, and applies them only after an authorized reviewer accepts the proposal. Use change requests for:

• Agent-authored fixes.
• Partner or CI-authored updates.
• Customer-specific patches that need approval before rollout.
• Automated version or image updates that should be reviewed first.

After a change request is accepted, Akua applies the change, records the new repository revision, and the installation moves through the normal render and sync lifecycle.

​

Roll back

Rollback is git-history-backed: restore the installation to a previous known-good repository state, then let Akua render and sync that state to the cluster. For reviewed environments, prepare the rollback as a repository change request so the revert is validated and approved before it reaches the installation. The resulting commit stays in history, so the original change and the rollback are both auditable.

​

API

Operate installations programmatically.

​

Related topics