Kvindo™ Cloud Docs
The Kvindo Terraform provider lets you manage cloud resources declaratively, against the same API as the console and the CLI. Resources use the familiar metadata / spec shape.
Declare it in your configuration, then run terraform init:
On an air-gapped or egress-restricted network, on a CI runner without internet, or during a Registry outage, install the provider from a mirror instead. The source above does not change — only the location the package is downloaded from. Point provider_installation at a filesystem mirror in ~/.terraformrc (or ~/.tofurc for OpenTofu):
The helper script from the provider repository downloads the release, verifies its checksum and lays the mirror out:
Delete .terraform.lock.hcl once when switching away from the Registry — mirror packages carry different h1: hashes — then commit the refreshed file. A network_mirror block works too if you serve the archives from an HTTPS host.
Authenticate with a bearer token — create one in the console under IAM → Tokens → Create token. Pass it via a variable (or the KVINDO_TOKEN environment variable). The endpoint is optional and defaults to https://cloud-api.kvindo.com (the https://cloud-api.kvindo.ru mirror can be used instead).
Already using the kc CLI? Set cli_profile instead of token to reuse the endpoint/token from a named kc login profile (~/.kc/config/<name>.yaml) — see the Registry docs below.
Each resource has a metadata block and a spec block, mirroring the API. Resources are placed in a folder via metadata.folder_id; the easiest way is to look up the organization's default folder with a datasource and reference its id. The provider has no name resolution, so hosting_provider_id is likewise resolved from a kvindo_hosting_provider datasource — g-ru-msk-1 here (run kc get provider for others):
• Provider documentation (Terraform Registry)
More in this section
Reference