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. Direct installations do not point back to a Product. In API responses,product_id is present only for product-based installations; every installation still includes its selected Package version.
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.
Launch readiness
An installation is ready to launch when the package contract, destination cluster, customer inputs, access path, and operations path are all defined. Check these pieces before you send a customer to an Offer or create a production direct installation:| Area | What to confirm |
|---|---|
| Package version | The selected Package version is immutable, has the expected defaults, and exposes only the inputs customers should edit. |
| Cluster and compute | The target workspace has a healthy cluster with enough compute capacity for the install. |
| Inputs | Required inputs have defaults, locked Offer values, or a clear customer-owned value path. |
| External access | Web ports that should be reachable have an access path defined in Networking. |
| Operations | Your team knows where to check status, logs, render history, and rollback options in Operate an installation. |
API
Create product-based installations or direct 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.
Related topics
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.