Skip to main content
An installation identity card collecting package version, inputs, history, status, and sync to worker nodes
Installations cover how applications land on your clusters: the per-installation git repositories that make every install auditable, the inputs editor, and the package model that ties it all together. Every installation gets its own private git repository, whether a customer purchased your product or you installed a tool directly. That repository is the source of truth for the install: the customer’s wizard inputs, the composition logic, and the rendered Kubernetes resources your cluster applies.

Installation repositories

The git-backed model behind every installation: what it stores and how to use it.

Package format

Author package.k, inputs, dependencies, and UI metadata.

Customizing inputs

Wizard editor, per-install overrides, and staged rollouts.

Operate an installation

Check health, stream logs, review changes, and roll back.

Packages

Versioned install definitions and input schemas.

Package versioning

How commit history maps to installations and how to roll back.

Two ways to install

Product-based installations

Product-based installations are created when customers purchase through the marketplace or an Offer, or when you install a Product manually from your dashboard. Each installation is customer-scoped and points back to the Product and Package version that created it. Use product-based installations when you are selling software to customers, need marketplace distribution, or want customer installs to inherit product defaults.

Direct installations

Direct installations let you install applications without a Product or Offer. They are ideal for supporting systems (shared databases, monitoring stacks, API gateways) that your products depend on but that are not sold individually. Use direct installations when you are setting up infrastructure, internal tools, or services that do not need per-customer billing. Both installation types follow the same underlying model: a Package version is selected, an installation repository is provisioned, the cluster syncs the rendered manifests, and Akua monitors the installation lifecycle. Most sensitive edits land through repository change requests: an agent’s fix, a partner’s update, an automated version bump, or any change that needs review before it reaches the installation. Routine dashboard edits and accepted change requests both resolve to the same repository-backed lifecycle.

API

Create installations, read their live status, and stream logs over the REST API. Per-endpoint parameters and response shapes live in the auto-generated reference.

Installs API

Create, read, and delete installations and inspect their lifecycle.

Installation lifecycle

States, renders, status, pods, and logs for a live install.

Repositories API

The git repository behind every installation.

Authentication

Mint API tokens for programmatic access.

Products

Turn Packages into sellable catalog items.

Clusters

Set up infrastructure for your installations.

Offers

How customers start guided installs from private offer links.

Akua packaging

The open-source substrate behind every Akua installation.