A few ideas explain how everything in Kvindo Cloud fits together. They apply whether you use the console, the CLI, Terraform, or the raw API.

Products and resources

A product is a family of functionality (Compute, Networking, S3, Kubernetes, …). A resource is a single thing you create inside a product — a VM, a VPC, a bucket. Every resource has the same envelope shape: apiVersion, kind, metadata (id, name, description, folder, labels), and spec (its desired configuration). Read-only state lives under status. Resource names are not required to be unique — even within a single folder two resources of the same type may share a name; the id (a ULID) is the true identifier.

Folders

Every resource lives in a folder — the platform's unit of grouping (much like a Kubernetes namespace), a purely conceptual way to organize resources by team, project, or environment. Folders do not by themselves grant or restrict access; access is controlled by IAM Access Policies, which can reference a resource's folder in a when expression when you want folder-scoped rules.

Transactions

A Transaction creates a whole set of resources atomically — either the entire bundle is accepted or none of it is. It carries one array per resource kind, so an entire environment (folder + VPC + subnet + VMs …) can be described and submitted as a single declarative document. Applying a multi-document manifest with the CLI builds on the same idea.

Asynchronous reconciliation

Creating or changing a resource is asynchronous. When you submit a desired spec, the API records it and returns immediately; the resource starts in a pending state. A background reconciler for that resource type then runs in a continuous loop, comparing the desired state in the database with the actual state on the underlying hosting provider and taking whatever steps move the real resource toward what you asked for.

A resource therefore moves through states like Scheduled → Reconciling → Reconciled (or UnableToReconcile on error). This is why tools offer a wait option (e.g. kc apply --wait): it blocks until the reconciler reports the resource has reached its desired state. The same loop keeps resources converged over time, not just at creation.

Resource states

Two fields track progress. status.state is the overall state of the resource:

Each change you submit also has its own progress, reported on status.lastChangeRequest.state — useful for watching a single create/update/delete:

Fields every resource has

Beyond each resource's own spec, every resource shares the same metadata and status fields. (On a specific resource page, switch the dropdown to All fields to see these alongside that resource's spec.)

---

Related pages

Resource docs

• Folder resource docs
• Transaction resource docs

Guides

• API design ideas

More in this section

• CLI
• Terraform
• API