[Back to blog](https://zcp.zsoftly.ca/blog) [Announcements](https://zcp.zsoftly.ca/blog/category/announcements) # Our CLI and Terraform Provider Reach v1 ZCP CLI v1.0.1 and the Terraform and OpenTofu provider v1.0.0 are available today, bringing Pricing V2 configuration, Kubernetes role sizing, VM backup schedules, and lifecycle fixes to automation workflows. Ditah Kumbong October 11, 2026 5 min read Share ![Our CLI and Terraform provider reach v1](https://zcp.zsoftly.ca/images/blog/2026/zcp-cli-terraform-v1.webp) Today we are releasing [ZCP CLI v1.0.1](https://github.com/zsoftly/zcp-cli/releases/tag/v1.0.1) and the [ZCP Terraform and OpenTofu provider v1.0.0](https://github.com/zsoftly/terraform-provider-zcp/releases/tag/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](https://registry.terraform.io/providers/zsoftly/zcp/latest). 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. ZCP CLI and Terraform provider repository activity, daily GitHub repository traffic, September 27 to October 10, 2026, UTC. Snapshot fetched October 11. Show the data | Time (UTC) | Provider daily clones | CLI daily clones | Provider daily unique cloners | CLI daily unique cloners | | --- | --- | --- | --- | --- | | Sep 27, 00:00 UTC | 5.00 | 6.00 | 3.00 | 4.00 | | Sep 28, 00:00 UTC | 2.00 | 1.00 | 1.00 | 1.00 | | Sep 29, 00:00 UTC | 0.00 | 0.00 | 0.00 | 0.00 | | Sep 30, 00:00 UTC | 1.00 | 18.00 | 1.00 | 4.00 | | Oct 1, 00:00 UTC | 1.00 | 0.00 | 1.00 | 0.00 | | Oct 2, 00:00 UTC | 1.00 | 21.00 | 1.00 | 9.00 | | Oct 3, 00:00 UTC | 0.00 | 72.00 | 0.00 | 16.00 | | Oct 4, 00:00 UTC | 1.00 | 16.00 | 1.00 | 5.00 | | Oct 5, 00:00 UTC | 2.00 | 3.00 | 2.00 | 3.00 | | Oct 6, 00:00 UTC | 2.00 | 5.00 | 1.00 | 3.00 | | Oct 7, 00:00 UTC | 52.00 | 12.00 | 12.00 | 7.00 | | Oct 8, 00:00 UTC | 25.00 | 0.00 | 12.00 | 0.00 | | Oct 9, 00:00 UTC | 54.00 | 133 | 12.00 | 35.00 | | Oct 10, 00:00 UTC | 1.00 | 28.00 | 1.00 | 14.00 | 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](https://zcp.zsoftly.ca/blog/zcp-pricing-v2-compute-and-storage-sold-separately): 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: ```bash zcp kubernetes create \ --name "my-cluster" \ --version "" \ --control-plane-plan "" \ --worker-plan "" \ --storage-plan "" \ --root-disk-size 100 \ --storage-category "" \ --region "yul-1" \ --project "" \ --billing-cycle "hourly" \ --workers 3 \ --enable-csi \ --ssh-key "" ``` `--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](https://github.com/zsoftly/zcp-cli/releases/tag/v1.0.1). 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: ```bash terraform init -upgrade terraform plan ``` For OpenTofu: ```bash 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: ```hcl 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](https://github.com/zsoftly/zcp-cli/releases/tag/v1.0.1), the [provider v1.0.0 release](https://github.com/zsoftly/terraform-provider-zcp/releases/tag/v1.0.0), and the [Terraform and OpenTofu guide](https://docs.zcp.zsoftly.ca/public-cloud/api/terraform-opentofu/) 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](https://www.linkedin.com/in/chester-chenwie-ndifor-96109b39b/) for development and [Fru Clintino](https://www.linkedin.com/in/fru-clintino-558283275/) for QA. Thank you to [Richard Coker](https://www.linkedin.com/in/cokerrd/), [Godson Tendongze](https://www.linkedin.com/in/godsontendongze/), our community contributors, and everyone on ZSoftly’s engineering team, past and present, for helping us reach v1. ## Related articles Announcements October 11, 2026 ### [ZCP Store: Buy Services and Licences From Your Console](https://zcp.zsoftly.ca/blog/zcp-store-buy-services-and-licences-from-your-console) The Store is a new tab in the ZCP console. Buy support, professional services, dedicated servers and licences there, and they bill on the same invoice as your instances. Announcements October 11, 2026 ### [ZCP Pricing V2: Compute and Storage Sold Separately](https://zcp.zsoftly.ca/blog/zcp-pricing-v2-compute-and-storage-sold-separately) ZCP plans are now CPU and memory only. You choose the root disk size in GB when you create a server and pay the per-GB rate of the storage tier. Existing servers keep their plan and price. Announcements October 3, 2026 ### [ZCP in Q3 2026: What Shipped, and What Is in Progress](https://zcp.zsoftly.ca/blog/zcp-q3-2026-update) A Q3 review of ZCP, followed by an October update on backup billing, Kubernetes billing, the Store, Marketplace emails, and account security.