Are these CDE case studies real companies?

Yes. Every organization on this page is named in a published source that is linked from its entry, including GitHub, Duolingo, Stripe, Spotify, Block, Ramp, Dropbox, J.B. Hunt, Deloitte, monday.com, DZ BANK and Siemens Healthineers. There are no composite or illustrative examples, and no quotation appears unless it is in quotation marks at the source.

Why is each case study labeled with a source type?

Because who published a figure changes what it is worth. Each entry is marked as a company engineering blog, a vendor case study, or a conference talk. First-party accounts such as GitHub's Codespaces migration and Stripe's devbox architecture carry more weight than vendor marketing, which is usable but is published by the seller and self-reported by its customer.

What do published CDE case studies fail to cover?

No open-source project has published a usable CDE case study. Most regulated-industry evidence is anonymized by the vendor rather than attributed to a named organization. Every metric in the public record is self-reported, with no control group and no published methodology, and onboarding time is heavily over-represented because it is the easiest number to publish.

Published CDE Implementations

Every organization on this page has published something about moving development off laptops and onto shared infrastructure. Each entry names its source, states what type of source it is, and links to it.

No composite examples. No illustrative companies. No quote appears here that is not in quotation marks at the source.

How to Read This Page

Almost everything published about Cloud Development Environments is published by someone selling one. That does not make it false, but it does mean the reader is entitled to know who wrote it before deciding what it is worth. So every entry below carries a source-type label, and no figure appears without a link to the page it came from. Where a company has written about its own infrastructure, that account leads. Where only a vendor has written it up, the vendor is named.

Company engineering blog

Strongest evidence here

The organization describing its own system, usually with a named engineer's byline and enough architectural detail to argue with. Still self-reported, but nobody sold them the story.

Vendor case study

Usable, with the byline attached

Written and published by the platform vendor, generally with customer sign-off. Metrics are supplied by the customer but framed by the seller, and there is no control group behind any of them.

Conference talk

Named engineer, on the record

A practitioner speaking at a public event. Attribution is solid; published numbers are usually thin or absent, so these are cited for what they describe rather than what they measure.

Quotes are quotes. Several vendor pages name an executive without putting any words in their mouth. Where that is the case, this page says what the source reports and attributes the name, but invents no testimonial. Kingland's speaker is published as a first name only, and stays that way here.

Nothing is rounded up. Figures are reproduced as published, including the awkward ones. Publishers and dates for every figure cited across this site are collected on the sources page.

First-Party Engineering Accounts

Six engineering organizations that wrote up their own environment infrastructure, on their own blogs, under named bylines. This is the best material in the corpus and it is where anyone evaluating a CDE should start.

GitHub

Company engineering blog

Platform: GitHub Codespaces (own engineering org)

The most thoroughly documented migration published by anyone. Cory Wilkerson, Senior Director of Engineering at GitHub, describes moving GitHub's own developers onto Codespaces and the work it took to make the main repository usable in one.

The repository is "almost 13 GB on disk" and "simply cloning the repository takes 20 minutes".
Initial codespace bootstrap took "45 minutes". After optimization the clone fell to "90 seconds" and the overall bootstrap to "5 minutes".
With prebuilds, "10 seconds".
Default hardware moved from "8 core, 16 GB RAM VMs" to "32 core, 64 GB RAM VMs".

The post also carries internal developer reactions, but those are chat messages attributed only by GitHub handle, with no names or titles, so they are not reproduced as testimonials here.

Source: GitHub Engineering Blog, published August 2021, updated December 2022.

Duolingo

Company blog + vendor case study

Platform: GitHub Codespaces, 300 seats

Unusually well corroborated: the same engineer who appears in GitHub's customer story also wrote the account on Duolingo's own engineering blog. Duolingo reports serving more than 500 million users.

"1m set-up time for largest repo with Codespaces".
"67% decrease in median code review turnaround time" and "70% increase in pull requests", as published on the customer story.
A separate "25% increase in developer speed" is attributed on that page to GitHub Copilot, not to Codespaces.

"With Codespaces, you don't need to waste a day or a week setting up each individual repository. Instead, you can get started within a few minutes."
Art Chaidarun, Principal Software Engineer, Duolingo

Sources: Duolingo Blog (October 2022) and the GitHub customer story.

Stripe

Company engineering blog

Platform: internal "devbox" environments for coding agents

The clearest published statement of why coding agents do not fit on a laptop. Stripe's agents, which it calls minions, each run in an isolated remote environment rather than on an engineer's machine.

"A minion run starts in an isolated developer environment - or 'devbox'".
"We want it to feel effortless to spin up a new devbox, so we aim for it to be ready within 10 seconds." Note this is a stated target, not a measured result.
"Containerization or git worktrees can help, but they're hard to combine and it's fundamentally difficult to build local agents that have all the power of a developer's shell but are appropriately constrained."
"Over 1,300 Stripe pull requests... merged each week are completely minion-produced, human-reviewed, but containing no human-written code."

Note that Stripe publishes an absolute count of pull requests per week, not a share of its codebase. It should not be restated as a percentage.

Source: Stripe engineering blog.

Spotify

Company engineering blog

Platform: "Honk" agents running in Kubernetes pods

Written by Niklas Gustavsson, Chief Architect and VP of Engineering at Spotify. The architectural detail is the point: the agent is scheduled as cluster workload, not as a process on a developer machine, and it is deliberately confined.

Agents are "deployed in Kubernetes pods so we can schedule many sessions concurrently across our cloud environment".
Each "runs in a container with limited permissions, few binaries, and virtually no access to surrounding systems."
"more than 99% of our engineers use AI coding tools every week"; "76% increase in pull request frequency"; "merged more than 2.5 million automated maintenance PRs".

Source: Spotify Engineering, June 2026.

Block

Company blog

Platform: "BuilderBot", internal AI-native tooling

Block's own announcement of the automation layer it built between AI coding tools and its engineering workflow. Useful for scale: the throughput described is not something a fleet of laptops absorbs.

"executes over 200,000 operations per day".
"merges approximately 1,500 pull requests per week".
"about 15% of all production code changes across Block".

"The best way to think about Builderbot is as the missing layer between AI coding tools and how engineering actually works at scale."
Brad Axen, Head of AI Capabilities, Block

Source: Block, June 2026.

Ramp

Company engineering blog

Platform: "Inspect" background agent on Modal sandboxes

Ramp's engineering team explains why its background coding agent runs in remote sandboxes rather than locally, and how much of its merged work now comes from it.

"~30% of all pull requests merged to our frontend and backend repos are written by Inspect."

Higher figures for Ramp circulate in third-party marketing. Ramp's own number is the one used here.

Source: Ramp Builders blog.

Enterprise and Large-Scale Deployments

Organizations running CDEs across hundreds or thousands of developers. All of these were published by the platform vendor rather than the customer, so the numbers are customer-supplied but vendor-framed. Read them as directional.

Dropbox

Vendor case study (Coder)

Platform: Coder, 1,000 developers

"1000 developers migrated to Coder in 4 months".
"30% reduction in cloud computing costs".
"50% reduction in startup times for some projects"; the body of the page describes startup times dropping "from about an hour to 15 minutes."

The page names Matt Kulka, Infrastructure Software Engineer, but publishes no direct quotation from him.

Source: Coder success story.

J.B. Hunt

Vendor case study (Coder)

Platform: Coder, 700 developers with 150 using Coder

A Fortune 500 transportation and logistics company that migrated off Azure Virtual Desktop. The interesting part is the consolidation ratio, not the headline saving.

"Over 90% drop in developer VDI cloud services, saving hundreds of thousands of dollars/year".
From "over 150 VDI development environments to a handful of environments on Kubernetes".
Prior onboarding "took a while, up to 2 weeks".

Daniel Trimble, Director of SRE, is named on the page but not quoted.

Source: Coder success story.

Deloitte

Vendor case study (vCluster)

Platform: vCluster for development and test environments

Described on the vendor page as an organization with 460,000 employees and more than $67 billion in revenue. The scope here is ephemeral test environments rather than developer desktops, which is worth keeping straight.

"89% Faster testing environments"; provisioning moved from "45-60 minutes per EKS cluster" to "under 3 minutes".
"$90k Reduction in engineering cost per year" and "800+ QA hours saved per year".
"60% Reduction in node usage".

"Developers care about getting their applications up and running fast. With vCluster, they click a few buttons and get a fully working environment with a reachable URL in minutes. That kind of speed was unheard of before vCluster."
Ismail A Mohammedali, Platform Engineer, Deloitte

Source: vCluster case study.

monday.com

Vendor case study (Okteto)

Platform: Okteto, 500+ developers

"Accelerated developer velocity by 50%".
"Reduced scrap and rework by 50%" and "Lowered bug incidents by 50%".
"400+ daily active namespaces".

"The productivity increase is huge - developers almost don't need any extra time handling environment setup and can work on what matters, which is the product itself."
Lior Rabin, Infrastructure Tech Lead, monday.com

Three separate outcomes each reported as exactly 50% is a pattern worth noticing before this is quoted as measurement.

Source: Okteto customer story.

General Motors

Vendor case study (Microsoft)

Platform: Microsoft Dev Box, in use since July 2022

No Dev Box performance metric has been published for GM, and none is invented here. What the page does contain is the sharpest published statement of the endpoint-security argument for moving development off laptops.

"Nothing is on the laptop. So it makes it really secure. We can manage compliance, just because their box is within Intune."
Lakshmi Jagan, Director of Enterprise Technology Services, General Motors

Source: Microsoft customer story.

Dell Technologies

Conference talk

Platform: Red Hat OpenShift Dev Spaces

Presented at OpenShift Commons in Atlanta, November 2025. No metrics were published, so this entry stands only for what it describes: the location of the source code.

"The source code lives on the OpenShift cluster and never lands on the user's local laptop."
Joseph Kanjirathinkal, DevOps Manager, Dell Technologies

Source: OpenShift Commons Atlanta, November 2025. Publisher details are listed on the sources page.

Named adopters with no published metrics

Several large organizations appear on vendor customer lists with no numbers attached at all. Palantir and Discord both appear as Coder customers with zero published metrics. A US Department of Defense software development group is described by Coder as "Thousands of developers" with no figures and no named speaker. L'Oreal appears as a Google Cloud Workstations customer, quoted through Sebastien Morand, Head of Data Engineering, again without metrics. They are listed here for completeness. Logos are not evidence.

Regulated Industries

Banking, healthcare, payments, government and pharma. This is the material most often asked for and the thinnest part of the public record: the named examples below are close to all of it, and the rest is anonymized.

DZ BANK

Vendor blog, co-authored with the customer

Platform: Google Cloud Workstations

Described as Germany's second largest bank and the central institution for around 700 cooperative banks. Before the migration, onboarding took "days or weeks", the bank had no control over developer tooling or vulnerability scanning, and code sat on individual machines. This is the strongest regulated-industry source available because the customer co-authored it.

"Onboarding new developers takes only one day vs. one week, pre Cloud Workstations."

"Developers get a fully standardized, secure, automated, cloud-native development environment and can start contributing to the code base from day one."
Gregor Otto Milenkovic, Product Owner, DZ BANK AG

Source: Google Cloud Blog, May 2024.

Siemens Healthineers China

Vendor case study (Microsoft)

Platform: Microsoft Dev Box, 10,000+ employees

"Android development time has decreased by at least 20 percent".
"Setting up Dev Box only takes one hour", against a prior "It took two or three days".

"We needed an effective, scalable, cost-effective way to switch between different environments. Dev Box gave us the solution."
Echo Qing Shan, Head of Digital Health China, Siemens Healthineers

Source: Microsoft customer story, March 2024.

payabl.

Vendor case study (Coder)

Platform: Coder, 60 developers, financial services

"Onboarding time: Reduced from one week to less than one minute".
"Freed up ~8 hours/week for DevOps and senior engineers".
"Improved resource efficiency by 20%".

"Coder is a centralized developer tool that simplifies onboarding and boosts productivity 10x."
Fazley Chowdhury, Group CTO, payabl.

The "10x" in that quote is the speaker's characterization, not a measurement reported anywhere on the page.

Source: Coder success story. No publication date shown.

Capgemini and ITZBund

Vendor case study (Red Hat)

Platform: Red Hat OpenShift Dev Spaces, air-gapped, German federal government

An air-gapped deployment for a German federal IT authority. Worth reading carefully: the success story itself contains no numbers. A figure of onboarding reduced "from 8 weeks to just 24 hours" appears on Red Hat's product page for OpenShift Dev Spaces, not on the customer story, so that is the page to cite for it.

"Red Hat OpenShift Dev Spaces allowed us to centrally manage permissions, security policies, and resources in one place."
Alexander Hiesinger, Enterprise Architect, Capgemini Cloud Infrastructure Services

Sources: Red Hat success story and the OpenShift Dev Spaces product page.

CytoReason

Vendor case study (Coder)

Platform: Coder, 80 users across 13 teams, pharma AI

"Cloud spend for CDE reduced by 60%".
One-click project start.

"The moment I saw Coder, it felt like exactly what we needed."
Yoni Rabinovitch, Software Infrastructure Team Leader, CytoReason

Source: Coder success story.

Onboarding Speed

Time-to-first-commit is the most commonly published CDE metric, because it is the easiest to observe and the most flattering. Treat these as before-and-after anecdotes from the organizations themselves, not as a benchmark. All six are vendor-published.

PsiQuantum

Vendor case study (Coder)

Platform: Coder, 500+ employees globally, 12-person platform team

One of the few published accounts that names a tool the organization evaluated and rejected: PsiQuantum assessed GitHub Codespaces and did not adopt it.

"Onboarding reduced from one week to instant access".
"Self-hosted deployment achieved automatic security team approval".

"Self-hosted deployment meant we could leverage our existing security processes instead of starting from scratch."
Jim Lesko, Senior Director of Engineering, PsiQuantum

Source: Coder success story.

Skydio

Vendor case study (Coder)

Platform: Coder, drone manufacturer

"90% reduction in cloud computing costs for development environments".
Time to first commit dropped "from a week to just an hour".

Elliot Graebert, Director of Engineering and Infrastructure, is named on the page but is not quoted.

Source: Coder success story.

LaunchDarkly

Vendor case study (Okteto)

Platform: Okteto, 95+ developers

New hires stand up a full stack "in minutes" where it "previously took weeks". No numeric metrics are published beyond that.

"Okteto helps us simplify the process of onboarding new hires and helps them be up and running as soon as possible with the minimum of fuss."
Andy Bold, Senior Platform Engineer, LaunchDarkly

Source: Okteto customer story.

Luminus

Vendor case study (Ona)

Platform: Ona (formerly Gitpod), energy, around 2,000 employees, 50-person data team with 40 Ona users

"$36,000 per year" saved.
Onboarding "Reduced from months to minutes".
"Over one day per week" of platform capacity recovered.

The account is attributed on the page to Jelle De Vleminck, Lead Platform Engineer.

Source: Ona customer story, May 2025.

GSR

Vendor case study (Ona)

Platform: Ona, cryptocurrency investment firm

Onboarding now "a few minutes", against "months previously".
"20% of platform engineering capacity" redirected.

"Our goal was to have the SRE team focused on revenue-generating tasks. Managing developer environments shouldn't be their priority."
Christopher Norman, Head of Engineering, GSR

Source: Ona customer story, July 2025.

Kingland

Vendor case study (Ona)

Platform: Ona, enterprise data management for financial services

The most concrete task-level figure in the corpus, on a "15-year legacy codebase": a Jest v30 migration took "about 15 to 30 minutes of actual engineering interaction" against "what probably would have taken an engineer maybe four to five hours". The page also claims "10x faster migrations".

The speaker is published as "Patrick", Enterprise Architect at Kingland. No surname appears on the source page, so none appears here.

Source: Ona customer story, August 2025.

Link durability warning. Three of the entries above (Luminus, GSR, Kingland) are hosted by Ona, formerly Gitpod. Ona announced on 06-11-2026 that it is being acquired by OpenAI; the transaction has not closed. Gitpod-era case studies already disappeared once during the rebrand, which is why several otherwise usable customer stories could not be cited on this page at all. Assume these three URLs are at elevated risk of link rot and archive anything you intend to rely on.

AI Agent Infrastructure

This is the strongest body of published evidence for centralized development infrastructure, and notably it is almost entirely first-party. The organizations running coding agents at scale did not choose remote environments for onboarding or compliance. They chose them because concurrency, isolation, and pre-warmed startup are not properties a laptop has.

Stripe

Pre-warmed devboxes spin up in 10 seconds. Stripe reports that local approaches such as containerization or git worktrees "are hard to combine" and that constraining a local agent is "fundamentally difficult". Over 1,300 pull requests merged each week are entirely agent-produced and human-reviewed.

Full entry and source above

Spotify

Agents scheduled as Kubernetes pods, each in a container with limited permissions, few binaries, and virtually no access to surrounding systems. More than 2.5 million automated maintenance PRs merged.

Full entry and source above

Block

BuilderBot executes over 200,000 operations per day and merges approximately 1,500 pull requests per week, about 15% of all production code changes across Block.

Full entry and source above

Ramp

The Inspect background agent runs on Modal sandboxes and writes around 30% of all pull requests merged to Ramp's frontend and backend repositories.

Full entry and source above

Laude Institute

Vendor case study (Daytona)

Platform: Daytona sandboxes

The cleanest published statement of the constraint itself, and the reason it belongs on this page even though it is vendor-published: the limit described is a hardware limit, not a preference. The page reports "37k sandboxes created in one week".

"We were bottlenecked by the resource constraints of our local computers. We could only run four to six Docker containers simultaneously."
Alex Shaw, Founding Member of Technical Staff, Laude Institute

Source: Daytona customer story.

Anonymized Customer Reports

These organizations are described only by sector and size. The vendor anonymized them, so there is no way for a reader to verify any of it independently, and no way to check whether the same customer appears twice under different labels. They are included because they are the bulk of what exists for regulated industries, and excluding them would misrepresent how thin the named evidence is. Weight them accordingly.

Described as	Published by	Reported figures
"A global leader in payments and financial technology", 15,000 developers	Coder	"Developer onboarding taking up to 15-30 days before first commit"; "100% user growth in 12 months"
"Fortune 500 Global Financial Services Firm", 300 developers	Coder	"Onboarding: Reduced to hours instead of weeks. One new hire was able to commit and merge changes on the first day."
Defense intelligence organization, air-gapped, 50 engineers	Coder	"Onboarding time reduced from days to 3-5 minutes"; "500% growth in developer adoption"
Fortune 500 global insurance company, "$50B+ Revenue; 40,000+ Employees"	vCluster	"70% Reduction in Kubernetes cost"; "$6M+ In projected annual savings"
Fortune 500 global insurance company, "$4.2 trillion AUM; 200 developers"	Okteto	"we've estimated a $400,000 annual ROI savings, thanks to Okteto"
"Company Y", insurance, "over $1 billion annual policyholder payments"	Ona	Windows VDI used to build Linux applications; updates moved from "days or even weeks" to "applied in minutes"
US government research team, federal agency	Okteto	No metrics published; the quote is from an unnamed "Platform Engineer"

Publisher pages for each row are listed on the sources page. Two rows describe a Fortune 500 global insurance company; they are published by different vendors and are not necessarily the same organization.

What the Evidence Does Not Cover

The gaps below are the honest reason this page is not longer. Anyone building a business case from public CDE material will hit all of them, and it is better to hit them here than in front of a review board.

No usable open-source case study exists

Despite open source being an obvious fit for browser-based contributor environments, no open-source project has published a case study with figures worth citing. This page does not stretch a thin example to cover the gap. There is nothing here.

Regulated-industry evidence is mostly anonymized

Five named regulated organizations are listed above, and DZ BANK is the only one where the customer co-authored the account. Everything else in banking, insurance, defense and government sits behind a vendor's anonymization, which is exactly the material a compliance reviewer will discount.

Every metric here is self-reported

There is no control group anywhere in this corpus, no published methodology, and no independent audit of any figure. Vendor-published metrics come from customers who agreed to be a reference. Nobody publishes the migration that did not work.

Onboarding time is over-represented

It is the easiest metric to publish and the most favorable, so it dominates. Almost nothing is published on the ongoing cost of running the platform, the size of the team needed to maintain it, or what developers gave up. Those are the numbers a business case actually turns on.

Widely circulated figures that are not real

A claim that Palantir cut onboarding from 15 days to one hour circulates widely and does not appear on Coder's Palantir page, which publishes no metrics at all. A "35% of code generated by AI" figure attributed to Valeo is Google's wording on Google's page with no named Valeo speaker. Neither is used here.

Sources disappear

Two real Gitpod-era case studies, for Quizlet and Vizlib, now return 404 after the Ona rebrand and could not be recovered. With Ona's acquisition by OpenAI announced and not yet closed, the three Ona-hosted entries on this page carry the same risk.

How to use this page in a business case. Cite the first-party engineering accounts as evidence of what is technically achievable at scale. Cite the vendor case studies as an indication of direction, with the vendor named. Do not cite any percentage here as a projection of what your organization will get. The right internal number is the one you measure yourself on a pilot team.

Next Steps

The evidence above says what has been done, not what you should do. Compare the platforms directly, work through the readiness questions, or read how agent workloads change the infrastructure requirement.

Compare CDE Tools Readiness Checklist Agentic AI and CDEs All Sources