June was a build month, and the build paid off on the first of July. Today we shipped the largest coordinated release we have put out: a single release that lands on the console, the CLI, the Terraform provider, and the API at the same time. It brings release channels for control plane upgrades, self-service GPU sharing, custom cluster networking, and a fully redesigned CLI to every surface at once, and it marks the moment the CLI and Terraform provider both reach 1.0.0 under a shared version scheme. Here’s the tour.
One release, every surface
The headline of today’s release is not any single feature. It’s that all of them arrived together, on every surface, at the same version.
If you have run infrastructure for any length of time, you know the specific frustration we set out to kill here. You read about a capability, you go to turn it on in Terraform, and it isn’t there yet, only in the console. So you click through the console instead, and now that one setting lives outside your infrastructure-as-code, a manual step nobody will remember in six months. Or the flag exists in the API but the CLI hasn’t caught up, so you drop down to raw curl. Or the feature is there but gated, and the only way to enable it is to open a ticket, wait for a reply, and explain what you want to someone who then flips a flag you cannot see. Each of these is small on its own. Together they are the reason platform work feels like it’s held together with exceptions.
The CLI and Terraform provider now share a single, synchronized version number, starting at 1.0.0. From this release on they are versioned together and track the same Cloudfleet API surface. A given CLI version and Terraform provider version always target a consistent API, so you no longer have to reason about which combination is compatible. The Terraform provider moves from 0.1.11 to 1.0.0 to adopt the scheme, the CLI moves to 1.0.0 alongside it, and both continue in lockstep from here.
This is a direct expression of a positioning bet we keep returning to: owning the full experience is what lets the whole path stay consistent and programmable. Every handoff between vendors in your workflow is a place where versions drift, capabilities lag behind each other, and automation breaks. When the same team ships the API, the CLI, the Terraform provider, and the console, a new cluster capability can appear on all four at once instead of trickling out over months. Release channels, custom networking, and self-service GPU sharing are all in this release because that is how we want every capability to land from now on: everywhere, or not yet.
A CLI built for automation and AI
The CLI reaching 1.0.0 is more than a version bump. It ships a redesigned input and output model built for scripting and, just as deliberately, for AI agents. This is the audience we keep designing for across the platform, and it’s worth being explicit about the bet.
We already ship an MCP server inside the CLI, and MCP is the cleanest way we know to let an AI assistant reason about Cloudfleet as structured resources. But the ecosystem has not settled on a single way for agents to act on the world. A large and growing share of them, coding agents in particular, drive plain command-line tools directly rather than speaking MCP. The market is still swinging between the two, and we are not interested in betting your experience on a guess about which one wins. So we support both: MCP for the assistants that speak it, and a CLI that is structured, predictable, and pleasant to drive for everything else. Whichever way an agent prefers to work, it reaches Cloudfleet through the same account, the same permissions, and the same resources.
That is why the redesign looks the way it does. Every change to the input and output model makes the CLI more predictable for a non-human caller, and more comfortable for a human at the same time.
In practice that means write commands take a full YAML or JSON body from a file or stdin, or accept common fields as named flags, and updates use predictable full-replace semantics so nothing changes behind your back. On the way out, you get structured, filterable output in whatever format you ask for, so a script or an agent can pull exactly the field it needs. The mechanics, including the read-modify-write workflow and a query language for projecting fields, are in the docs on providing input to write commands, full-replace updates, and output formats.
Release channels: control how fast your clusters change
Release channels are now generally available, and they are the clearest productization yet of how we manage change across the platform.
It’s easy to picture control plane updates as “Kubernetes version upgrades,” but that’s a small slice of what actually changes. Beyond Kubernetes minors and patches, we are continuously improving the CFKE control plane stack itself: the components that run your control plane, their configuration, their defaults, and the operational tuning behind them. That work ships on an ongoing basis, not on a fixed quarterly clock. Release channels give you a say in how eagerly each cluster picks all of it up.
You can now choose how quickly a cluster’s control plane adopts new Kubernetes and CFKE releases:
rapid(the default) receives updates first.stablebalances freshness with stability and is available on the Pro and Enterprise tiers.extendedstays on a release the longest and is available on the Enterprise tier.
Channels are not a brand-new mechanism. We already had specific enterprise customers running mission-critical workloads on Cloudfleet who valued stability over the latest features, and we had kept those clusters on the extended channel, the slowest and most conservative rollout track, well before today. What’s new today is that channels become generally available and self-service for everyone on Pro and above, configurable in the console, through the CLI and API, and in Terraform, rather than arranged through support.
The judgment behind the channels is the one we have always applied to change. Even rapid, our fastest channel, never gets a new Kubernetes minor the day it lands upstream: every minor goes through substantial internal testing in our pipeline, and we watch its early patch versions stabilize, before it reaches any customer. The slower channels simply extend that caution further out. We apply comparable care to the rest of the control plane stack. Different workloads have different appetites for that change, though. A platform team validating against the leading edge wants updates first. A regulated production workload with a long change-control process wants the opposite. Channels let each cluster follow the pace its workload actually needs, across everything we ship, not just the Kubernetes version.
Self-service GPU sharing, Fleet constraints, and profiles
In May we said the near-term work was expanding the self-service surface area for the Fleet and provisioning features that had launched in private preview. This release delivers on that.
GPU sharing is now generally available and fully self-service. Multiple pods can share a single GPU using time-slicing or MPS, with a configurable maximum number of clients per GPU. The important change is where that setting lives: you now configure it through the cluster’s feature settings in the console, the CLI and API, or Terraform, rather than by contacting support. For AI and ML teams packing more work onto expensive accelerators, GPU sharing goes from a support conversation to a field you set yourself. See GPU sharing with time slicing and MPS.
Fleet constraints and auto-provisioning profiles move onto the same self-service footing. Fleet constraints, which launched in preview on May 3, let you pin a Fleet to a specific cloud, region, or instance family so node auto-provisioning only considers matching infrastructure, and your pod specs stop repeating the same selectors. The Terraform provider now surfaces both constraints and a scaling_profile directly on the Fleet resource, alongside the new features and networking blocks and the enterprise tier, so these decisions live in the same code that manages the rest of your infrastructure. The provider also exposes read-only ready, status_message, created_at, and updated_at attributes, which makes it far easier to build reliable automation around cluster and Fleet lifecycle. See the resources and data sources reference.
Fleet constraints came from sustained customer demand, and moving them to self-service is the second half of that story: you asked for the control, and now you can apply it yourself, in the console or in code, without a ticket in the loop.
Custom networking: your own CIDRs and dual-stack
Custom pod and service CIDRs and IPv4/IPv6 dual-stack networking are now generally available. You can set your own IPv4 pod and service ranges when creating a cluster, and enable dual-stack with dedicated IPv6 ranges alongside them.
This matters most when a cluster does not live in isolation. If your pods and services need to route to on-premises networks, peered VPCs, or other clusters, non-overlapping address ranges are the difference between clean routing and a painful renumbering later. Picking your own CIDRs up front removes that class of conflict. Dual-stack, meanwhile, is increasingly a requirement rather than a nice-to-have as IPv6 adoption grows across cloud and on-premises networks.
An enterprise customer had been using this throughout the private preview and helped us polish the feature before general availability. They run a multi-cloud cluster and added a machine in their own datacenter as a self-managed node so workloads could reach internal resources privately, using egress gateways to route the relevant outbound traffic through it. For that to work cleanly, the cluster’s pod and service ranges had to stay clear of the network ranges already in use on their on-premises network. Custom CIDRs let them choose ranges that sit alongside their existing topology instead of colliding with it.
Set your address plan up front and a Cloudfleet cluster slots into your existing network like it was always there, matching your routing and topology instead of forcing you to design around it.
Cilium 1.19.4 and a load balancer fix
Two changes reached clusters on June 30, ahead of the July 1 release.
CFKE’s Cilium version was upgraded from 1.18.5 to 1.19.4, a minor version upgrade of the CNI that powers cluster networking. We validate CNI upgrades through our internal pipeline before rolling them, on the same deliberate cadence we apply to Kubernetes itself. If you use BGP for on-premises load balancing, validate your BGP configuration once the upgrade reaches your cluster. Details are in the on-premises load balancing with BGP documentation.
We also shipped a fix for LoadBalancer services that use the PROXY protocol: they now report their ingress with IPMode: Proxy, so kube-proxy no longer short-circuits traffic destined for the load balancer IP. This restores correct routing for services that rely on the PROXY protocol to preserve client source IPs. See the load balancing documentation.
Both changes roll out gradually across all Cloudfleet regions and reach every cluster automatically over the coming days.
Looking ahead
The through-line of the first half of 2026 has held steady: finer-grained control where you need it, more of the platform reachable by API, CLI, Terraform, and AI assistants, and fewer surprises from the layer underneath. With the CLI and Terraform provider now versioned together at 1.0.0, that consistency becomes something you can depend on release to release.
For the rest of the summer we are aiming to keep moving the newer cloud provider integrations from private preview toward general availability, to keep widening the self-service surface for Fleet and provisioning controls, and to exercise the new release-channel machinery as control plane and Kubernetes updates move through it. As always, dates and scope can move.
If there’s a specific topic you’d like to see in a future recap, open a ticket through the support center, now reachable from the console, the CLI, and the MCP server, or reach out via your account manager.
