Documentation Index
Fetch the complete documentation index at: https://docs.akua.dev/llms.txt
Use this file to discover all available pages before exploring further.
configure for a long time is a customer stuck on a form, and a draft in payment is one who reached checkout but has not paid yet.
The customer flow
The branches matter: the worker-join step only appears when the chosen destination is a brand-new managed cluster with no worker yet, and the checkout step only appears when the offer’s commercial terms require payment. A free or private offer on an existing cluster runs the short path straight from configure to install.The states
Each order draft reports astatus that names its current state. The states run in order, and done and the cancelled state are terminal.
| State | What is happening |
|---|---|
| Resolve the offer | The customer opens akua.dev/i/<hash>. Akua resolves the offer and creates an order draft against it, still anonymous. |
| Claim | The customer signs in (or signs up with email verification) and claims the draft with a one-time token, binding it to their account. |
| Workspace | The customer picks an existing workspace or creates a new one as the install destination. |
| Compute | Akua allocates the cluster the installation will run on. |
| Worker bootstrap | Only when the destination is a new managed cluster with no worker: the customer adds a worker node using a short-lived join command, and the draft waits until the node is ready. |
| Configure | The customer fills the generated install form. Fields come from the Package version’s input schema, with any offer pre-fills and locked fields already applied. |
| Payment | Only when the offer requires payment: the customer completes a hosted checkout. See payments. |
| Install | Akua creates the installation, provisions the customer’s private repository, and deploys the selected Package version. |
| Live | The installation is running and the order is delivered. |
Where payment fits
The payment state is a branch, not a fixed step. When an offer carries paid commercial terms, the draft cannot reach the install state until a checkout session is completed and confirmed. Akua opens a Stripe-hosted checkout, and the customer returns to the wizard once payment succeeds. If a checkout fails or is abandoned, the draft stays in the payment state and the customer can start a new checkout session. When an offer is free or settles outside checkout (a private sale, or a non-billable test offer from an offer channel), the draft skips payment entirely and moves straight to install. The full payment lifecycle, platform fees, and Stripe Connect setup live in Marketplace payments.Adding a worker when needed
If the customer routes the install to a freshly created managed cluster that has no compute yet, the draft pauses so they can attach one. Akua issues a short-lived bootstrap command and cloud-init that join a worker node to that cluster. Once the node is ready, the draft continues to the configure state. Installs that target an existing cluster with available capacity never see this step.What happens after the draft
The order draft is not the whole lifecycle. It owns the purchase and configure flow up to the point where the install can begin. Once payment is complete, or once a no-charge offer skips payment, Akua records the order, starts delivery, and links the draft to the installation it creates. From that point, the installation becomes the long-lived resource. Use the draft to understand where a buyer is in the purchase flow. Use the installation lifecycle to monitor the running software: render history, health, pods, logs, and deletion.Seller visibility
The order draft is the same record behind the offer’s support-visibility view. Watching a customer’s drafts tells you where each buyer is in the flow and where they drop off, without exposing their secret configuration values. Sensitive inputs are write-only and are never returned to anyone but the customer who entered them. This is how you support a customer mid-purchase: confirm they reached checkout, see that delivery has started, or spot a draft that ended early.API
Track and manage customer order drafts and their checkout sessions programmatically.Order Drafts API
Inspect, claim, configure, and cancel order drafts through the flow.
Checkout sessions API
Create and read the checkout sessions attached to a paid order draft.
Offers API
Create and resolve the offers that start an order draft.
Authentication
Mint API tokens for seller-side automation.
Related topics
Offers
The shareable links that start every order draft.
Payments
The checkout and billing flow behind the payment state.
Add workers
Attach a worker node when an install needs new compute.
Installations
What the order draft produces once it goes live.