Our CLI and Terraform Provider Reach v1

Today we are releasing ZCP CLI v1.0.1 and the ZCP Terraform and OpenTofu provider v1.0.0.

This release marks a milestone for teams building on ZCP through terminals, pull requests, and automation.

The provider uses the v1.0.1 CLI SDK, which keeps its API integration aligned with the current CLI release.

A milestone in numbers

As of October 11, 2026, the provider has passed 5,000 downloads across all versions on the Terraform Registry. Over the preceding 14 days, GitHub recorded 315 clones from 92 unique cloners for the CLI repository and 147 clones from 47 unique cloners for the provider repository. These activity counts include repeat installs and automation.

Source: GitHub repository traffic snapshots, fetched October 11, 2026. GitHub counts each cloner once within each repository’s full window, giving 92 CLI and 47 provider unique cloners. Daily counts can include the same cloner on multiple days and do not establish a combined unique audience.

What v1 means for your infrastructure

New VM configurations now choose compute and root storage separately. Use a named compute plan, a named root-storage tier, and a root-disk size. This matches Pricing V2: CPU and memory no longer determine the root disk you buy.

New Kubernetes clusters also use separate choices for control-plane compute, worker compute, and root-volume storage, plus an explicit root-disk size. This lets teams size those roles for their workload instead of treating a cluster as one fixed node shape.

After authenticating and selecting a profile, use the following shape for a new cluster. Replace the quoted placeholder values with plans and storage categories available to your account:

zcp kubernetes create \
  --name "my-cluster" \
  --version "<kubernetes-version>" \
  --control-plane-plan "<control-plane-plan>" \
  --worker-plan "<worker-plan>" \
  --storage-plan "<root-storage-plan>" \
  --root-disk-size 100 \
  --storage-category "<storage-category>" \
  --region "yul-1" \
  --project "<project-slug>" \
  --billing-cycle "hourly" \
  --workers 3 \
  --enable-csi \
  --ssh-key "<ssh-key-name>"

--enable-csi requests Cloud Storage Integration for a supported cluster. It does not promise that a workload will successfully provision storage. Kubernetes autoscaling records the requested minimum and maximum worker bounds, but automatic scale-out remains unverified. Treat a requested configuration as distinct from observed worker count and billing.

Backup schedules that fit operations

The CLI now manages scheduler-backed VM backup policies. Policies support hourly, daily, weekly, and monthly intervals, IANA time zones, and retention counts. You can set names and descriptions, request immediate runs, and pause or resume a policy. The provider adds the zcp_vm_backup_schedule resource, including policy scope and import support.

Use the CLI for one-off backup runs and restores. A VM restore overwrites the VM’s current disks. It requires a stopped VM and a ready backup from that VM in the selected region and project. The CLI prompts before the restore, unless you pass --yes. The response confirms acceptance, not completion. Check the VM state and activity logs before treating a restore as finished.

The platform can persist an everyOtherDay schedule and then return an error. The provider rejects that interval before writing. With the CLI, list policies after such an error before retrying and remove an unintended policy if one was created.

Reliability work included in v1

The v1 releases add the CLI v1.0.0 features and v1.0.1 compatibility fixes. They also retain earlier reliability work, including CLI v0.0.31 ACL-rule pagination. ACL listings now return every reported page or return an error rather than a partial rule set.

• CLI v1.0.0 adds safe VM-backup restore checks, split Kubernetes role and root-storage inputs, backup policies, complete DNS listings, and cancellation responses that reject API error envelopes even when the HTTP response is successful.
• CLI v1.0.1 moves instance deletion to the service-cancellation workflow, restores the supported hostname-change operation, retrieves every VM snapshot page, and accepts a named storage tier with capacity for zcp volume create.
• Provider v1.0.0 adds VM backup schedules, fixes DNS-domain lookup through paginated results, exposes a decoded plan tag, and handles an already-detached load-balancer attachment as a successful destroy only for the documented API response.

Changing an instance name through the provider changes its hostname. The operation can restart a running instance or start a stopped one, so plan it as an operational change.

Upgrade carefully

This is a breaking release for new and replacement VMs and Kubernetes clusters. Review their compute and storage settings before upgrading. Existing provider state remains readable and destroyable, but configurations need review before they create or replace infrastructure.

1. Upgrade the CLI to v1.0.1 from its release page. For new instances, supply --plan, --blockstorage-plan, and --root-disk-size.

2. Pin the provider to the v1 line, then refresh provider plugins and inspect the plan:

   terraform init -upgrade
   terraform plan

   For OpenTofu:

   tofu init -upgrade
   tofu plan

3. For a new or replacement zcp_instance, set plan, blockstorage_plan, and root_disk_size. Custom CPU, memory, and disk inputs are no longer accepted for new instances.

4. For a replacement Kubernetes cluster, set control_plane_plan, worker_plan, storage_plan, and root_disk_size. Those shape fields force replacement because the platform has no role-specific plan update operation. Existing clusters keep their legacy plan state until replaced.

5. Apply only after the reviewed plan matches your intended replacement and service window.

Provider configuration remains familiar:

terraform {
  required_providers {
    zcp = {
      source  = "zsoftly/zcp"
      version = "~> 1.0.0"
    }
  }
}

Cluster cancellation can leave a network that needs separate deletion. Review the plan and the resources that remain after a cluster is removed.

Start here

Read the CLI v1.0.1 release, the provider v1.0.0 release, and the Terraform and OpenTofu guide for complete changes and reference material. If you are moving an existing Terraform or OpenTofu configuration to v1, review terraform plan or tofu plan before applying the migration.

Acknowledgements

Special thanks to Chester Ndifor for development and Fru Clintino for QA. Thank you to Richard Coker, Godson Tendongze, our community contributors, and everyone on ZSoftly’s engineering team, past and present, for helping us reach v1.