The kontract
The kontract is the contract underneath Konduit: a small set of cloud-native, GitOps-friendly concepts that define where apps live, what they cost, and how the experience is presented. Konduit is the primary, always-demoable implementation of the kontract. Games and custom skins are add-ons over the same contract.
The kontract is under active development on the 0.7 line. This page describes the settled model; the CRDs land incrementally and are dormant until their controllers ship.
The model
Zones — the payment unit
A zone is where apps live. It replaces the environment concept: the zone is the isolation boundary, and the theme you use expresses what that boundary feels like (an environment in Konduit, a planet in a game, a neighborhood in another).
- Every organization gets its first zone free
- More zones are purchased in bands — fixed capacity sizes from the platform catalog
- A zone materializes as a quota-capped workload namespace, enforced by a
ResourceQuotaandLimitRangecommitted through GitOps
| Band | CPU | Memory |
|---|---|---|
small | 10 | 10Gi |
medium | 20 | 20Gi |
large | 30 | 30Gi |
upgrade (increment) | +10 | +10Gi |
Bands are defined in code, not configuration: a rate card prices them, administrators re-price them for chargeback, but nobody redefines what small means. Underneath the band, the stored quota values remain fluid Kubernetes quantities — the band constrains what is offered and priced, not what the machinery can express.
Apps — the resource unit
Apps always ship to a zone. An app has a size (s = 1 CPU/1Gi, m = 2/2Gi, l = 4/4Gi, per replica) and either fits the zone or doesn't: the sum of size × replicas across the zone's apps must stay within the band (plus upgrades). Fit is checked at registration, re-checked by the operator before every GitOps commit, and backstopped by the zone's ResourceQuota at admission time.
App sizes and usage are recorded for historical purposes only — zones are what you pay for; apps are what consumes them. App metadata may inform billing in a later phase.
The shop
Zones, upgrades, and add-ons are bought in the shop. Prices come from a RateCard — a platform resource administrators edit to distribute costs to downstream departments, with no external billing integration required. Themes customize the shop's presentation (vocabulary, imagery, which items are featured), never its price math.
Themes — presentation only
A theme renders the same kontract under a different metaphor: Konduit's business language, or a game where zones are planets and deploys are launches. Themes carry vocabulary, copy, colors, assets, and optional progression rules. The backend never branches on the active theme.
Character — a separate section
Progression (appearance, XP, levels, quests, unlocks, inventory) lives on a per-user Character, entirely separate from zones and payment. XP is global across themes; a hero leveled in one skin keeps their level in another. Business themes simply ignore it.
Custom resources
All kinds live in konstruct.civo.com/v1alpha1, namespaced per organization (platform-level kinds in the platform namespace):
| Kind | Owns |
|---|---|
Zone | band, upgrades, placement, free flag, cost center → materializes the quota-capped namespace |
RateCard | SKU price lines (zone.small, zone.upgrade, …) for chargeback |
Theme | theme registration: repository to build, capabilities, vocabulary, progression rules — see Themes |
Character | appearance, xp, level, quests, unlocks, inventory, equipped |
As everywhere in Konstruct: the API writes CRs, operators reconcile them through GitOps commits, and CR status is the source of truth.
What's next
- Themes — how frontends implement the kontract, including your own
- How Konduit works — the delivery pipeline the kontract governs
- Platform requirements — enabling Konduit on your control plane