Google Cloud Workstations

Cloud Workstations is Google's managed cloud development environment. You define a workstation configuration - machine type, container image, disk, timeouts - and developers get workstations provisioned from it, reachable through a browser IDE, local VS Code, or a JetBrains IDE. The workstations run on Compute Engine instances with Persistent Disks attached, inside your own project, which is the architectural detail that drives everything else about the product.

That placement is the pitch. Because workstations are ordinary Google Cloud resources, they inherit the governance you have already built: IAM for who can create and reach what, VPC Service Controls for keeping data inside a perimeter, private clusters for removing public endpoints, organization policy, Cloud Audit Logs, and CMEK for disk encryption. For a security team that has spent two years building a Google Cloud perimeter, a development environment that sits inside it rather than beside it is a materially easier approval than any external SaaS.

The counterpart is equally clear. This is a Google Cloud service, available in Google Cloud regions, administered with Google Cloud tooling, and it is not self-hostable in any form. If your organization is not already on Google Cloud, adopting Cloud Workstations means adopting Google Cloud, which is a far larger decision than choosing a development environment.

The hierarchy is worth learning before reading the price list, because the billing follows it exactly. A workstation cluster is the control plane, associated with a region and a VPC network. Inside it, workstation configurations define machine type, container image, disk, and timeout policy. From a configuration you create workstations, which are the per-developer instances that start and stop.

Note that "managed" here does not mean "someone else worries about the bill". Google removes the burden of running the platform, and leaves you every decision that determines what it costs. The cluster count in particular is a design choice with a standing monthly consequence, covered in the next section.

All rates above are from Google's own pricing page as of July 2026: cloud.google.com/workstations/pricing. Note that the figures on that page render client-side, so a simple page fetch will not show them. No free tier is offered for this service.

The saving grace is that the timeout defaults are on your side. Workstations stop automatically after a default idle period of 20 minutes, and a default maximum running time of 12 hours forces a restart so security updates apply. Both are configurable, and both are worth tightening rather than loosening. See cost analysis and FinOps for development environments.

Cloud Workstations reached general availability with an SLA in May 2023 and continues to receive product updates, with release notes entries through July 2026. The service carries no deprecation or shutdown notice. What does get deprecated is individual base images - older JDK, Node, and Ubuntu images have been retired on the normal schedule - which is routine image lifecycle rather than a signal about the product.

That is a healthier picture than most of this category can claim. It deserves one honest qualification, though, and it is the same one that applies to every cloud provider service: AWS closed Cloud9 to new customers and then closed CodeCatalyst, both of which also looked healthy and generally available shortly before. Being run by a hyperscaler makes abandonment less likely than at a startup, not impossible, and developer tooling is not usually the strategic core of a cloud business.

The proportionate approach is to keep the image and infrastructure definitions portable, avoid inventing Google-only workflows where a standard one exists, and revisit the pricing page each budgeting cycle since all three charges are published and can move. Vendor evaluation covers scoring this systematically, and the CDE market guide covers who else has entered and left the category.