Frequently Asked Questions

A Cloud Development Environment (CDE) is a remote workspace that runs on cloud infrastructure instead of your local laptop. Instead of cloning code to your machine and installing dependencies locally, you connect to a fully configured environment running on AWS, Azure, GCP, or on-premises Kubernetes. Your IDE (like VS Code or JetBrains) connects remotely, but the heavy lifting happens in the cloud. CDEs have also become the default runtime for AI coding agents, providing isolated sandboxes where autonomous tools can safely write and test code without touching production systems.

CDEs are most common in these scenarios:

• Regulated industries - Healthcare (HITRUST), finance (SOC 2), and government (FedRAMP) where source code cannot touch local laptops
• Platform engineering teams - Organizations standardizing developer environments across large engineering teams
• Remote-first companies - Teams where contractors and vendors need secure, temporary access to codebases
• AI/ML teams - Developers working with GPU-intensive workloads that exceed laptop capabilities
• AI agent operators - Teams running autonomous coding agents (like Claude Code, Devin, or Copilot Workspace) that need sandboxed environments for safe code generation and testing

Consider CDEs if you are experiencing any of these pain points:

• New developers take days, not minutes, to get their environment working
• "Works on my machine" issues slow down development velocity
• Compliance audits require proving code never leaves your VPC
• Developers need more CPU/RAM than laptops can provide
• Lost or stolen laptops create data exfiltration risks
• AI coding agents need isolated, reproducible sandboxes to safely generate and test code

No, but they are related. A DevContainer is a configuration file (devcontainer.json) that defines what tools and dependencies should be installed in a development environment. A CDE is the platform that actually runs that container in the cloud.

Think of it this way: A DevContainer is the recipe, a CDE is the kitchen. Most CDE platforms (Codespaces, Ona (formerly Gitpod), Coder) support DevContainers as a way to define environment configurations.

While both involve remote access, CDEs are purpose-built development platforms with key differences: environments are defined as code (Terraform/DevContainers) ensuring reproducibility, they integrate directly with your local IDE for a seamless experience, they include lifecycle management (auto-start, auto-stop, auto-delete), and provide central administration for teams. A plain SSH server requires manual setup and lacks these developer-focused features.

Both - and increasingly, neither. Most CDEs support multiple connection methods: VS Code (via Remote SSH extension) running on your laptop but connected to the cloud workspace, JetBrains Gateway for IntelliJ/PyCharm users, and web-based IDEs (like code-server or VS Code for the Web) accessible directly in the browser. Developers can choose their preferred workflow - the experience feels local, but the code execution happens remotely. A growing number of CDE sessions are also headless - driven by AI agents that connect via CLI or API without a human IDE at all.

Container-based CDEs (like Ona, Codespaces) run workspaces as Docker containers or Kubernetes pods. They are lightweight, start in seconds, and cost less. However, they share a host kernel and may be limited for workloads requiring nested virtualization or full OS access.

VM-based CDEs (like Microsoft Dev Box, some Coder configurations) provide full virtual machines with complete OS flexibility. They can run Windows, Linux, or macOS, support GUI apps, and handle any workload. The tradeoff is higher cost and slower startup times (minutes instead of seconds).

MicroVM-based CDEs are the emerging middle ground in 2026. Technologies like Firecracker and Cloud Hypervisor spin up lightweight VMs in around a second while providing full kernel-level isolation. Ona describes its environments as secure, ephemeral VMs provisioned from a Dev Container configuration, each with its own compute, storage and networking - so the Dev Container file is the input and a virtual machine is the result. Ona does not name a specific hypervisor, so treat "VM" as its own wording rather than as a documented microVM implementation. The same approach is now standard in AI agent sandbox products, which is the market Daytona moved into when it left cloud development environments.

Most CDEs support:

• VS Code - via Remote SSH extension (most popular)
• JetBrains IDEs - via JetBrains Gateway (IntelliJ, PyCharm, WebStorm, etc.)
• Web IDEs - Browser-based VS Code (code-server) for zero-install access
• SSH/Terminal - Standard terminal access for vim, emacs, or command-line workflows
• AI-native editors - Cursor and Zed support remote SSH connections, bringing AI-assisted coding to cloud workspaces. "Windsurf" is no longer a current brand: Codeium became Windsurf, Cognition acquired the remaining Windsurf entity on 07-14-2025, and the product became Devin Desktop on 06-02-2026.

Performance depends on several factors:

• Faster compute - Cloud workspaces can have 32+ CPU cores and 128GB+ RAM, far exceeding typical laptops
• Faster builds - Parallel compilation, large builds, and Docker layer caching benefit from cloud resources
• Network latency - IDE responsiveness depends on internet connection quality
• File operations - Large file transfers to/from workspace can be slower than local disk

CPU-intensive work (builds, tests, Docker) generally benefits from cloud hardware, while typing and editing responsiveness depends on your connection and on how far the workspace region is from the developer. There is no published benchmark that settles this for every team - measure round-trip latency to your candidate region with your own users before committing.

No, CDEs require an internet connection to access your workspace. This is the primary tradeoff compared to local development. However, some platforms offer workarounds:

• Hybrid mode - Tools like DevPod let you switch between cloud and local workspaces
• Local fallback - Keep DevContainer configs that work both remotely and locally
• Mobile hotspot - Many developers use phone tethering as backup connectivity

This depends on your platform's configuration:

• Auto-stop after idle time - Most platforms pause workspaces after 30 minutes to 2 hours of inactivity to save costs
• Persistent storage - Your code and changes are saved; reconnecting resumes where you left off
• Manual stop/start - You can manually stop workspaces to avoid idle charges, restarting when needed

It depends on your organization's policy:

• Open workspaces - You have sudo/admin access and can install anything (like your own laptop)
• Locked templates - Platform teams pre-install approved tools; you cannot modify the base image
• User-layer installs - You can install tools in your home directory without system-wide changes

Most organizations use locked templates for consistency and security, with a process to request new tools be added to the standard image.

Nix is a purely functional package manager that creates reproducible, declarative development environments. Several CDE platforms have adopted Nix as an alternative (or complement) to Docker-based DevContainers:

• Deterministic builds - Nix guarantees the exact same packages and versions every time, eliminating "it worked yesterday" issues
• No Docker overhead - Nix environments run natively without container layers, reducing startup time and resource usage
• Composable stacks - Developers can layer multiple language toolchains (Node.js + Python + Rust) without Dockerfile complexity
• Platform support - Coder supports Nix through custom Terraform templates, and Devbox (by Jetify) is a popular Nix-based tool for defining CDE environments. Support varies by platform and changes often - confirm against the vendor's current documentation rather than a comparison table.

The protocol connecting your local IDE to the remote workspace directly impacts latency, responsiveness, and feature support:

• SSH - The universal standard. VS Code Remote SSH and terminal editors use it. Reliable but basic - no built-in port forwarding UI or workspace awareness.
• JetBrains Gateway (RD Protocol) - A proprietary protocol optimized for IntelliJ-family IDEs. Handles rich IDE features like debugging, refactoring, and indexing with server-side processing.
• VS Code Tunnels - Microsoft's managed tunnel service that works through firewalls without SSH configuration. Used by Codespaces and Dev Box.
• WireGuard/Tailscale - Several CDEs (including Coder) use WireGuard-based mesh networking for encrypted, low-latency peer-to-peer connections between your device and the workspace.

For best results, choose a CDE whose protocol aligns with your IDE. If your team uses mixed editors, SSH provides the broadest compatibility.

MicroVMs are lightweight virtual machines that boot in milliseconds while providing hardware-level isolation. They have become a defining technology for CDEs in 2026:

• Firecracker - Originally built by AWS for Lambda and now used by CDE platforms to spin up isolated workspaces with minimal memory overhead. The Firecracker project itself documents a boot time of roughly 125ms; real-world workspace start times are longer because the image and workload still have to load.
• Cloud Hypervisor - An open-source alternative backed by Intel and Microsoft, optimized for cloud-native workloads
• Security benefit - Unlike containers that share a host kernel, microVMs give each workspace its own kernel, preventing container-escape attacks
• AI agent safety - MicroVMs are ideal for running AI-generated code because a rogue process cannot escape the VM boundary, making them the preferred isolation layer for autonomous development workflows

CDEs provide several security advantages:

• Data exfiltration prevention - Source code never touches local disks, preventing theft via lost/stolen laptops
• VPC isolation - Code stays within your cloud network, never traversing public internet
• Access controls - Centralized authentication (SSO, MFA) and permission management
• Audit logging - Complete visibility into who accessed what code and when
• Instant revocation - When an employee leaves, delete their workspace immediately
• AI agent containment - Sandboxed environments prevent AI coding agents from accessing production systems, leaking secrets, or making unreviewed network calls

CDEs can help achieve compliance, but it depends on your implementation:

• Self-hosted CDEs (like Coder) run in your own AWS/Azure, so YOU control data residency and compliance
• Managed CDEs (like Codespaces, Ona) typically hold their own SOC 2 attestations, but request the current report rather than assuming it covers YOUR requirements
• HITRUST CSF - Healthcare organizations often require self-hosted CDEs in HITRUST-certified infrastructure
• GDPR - Data residency (EU regions) and right-to-deletion are achievable with proper configuration

For regulated industries, genuinely self-hosted CDEs give the most control: Coder (Community edition is open source and self-hosted), Okteto, and Eclipse Che. Microsoft Dev Box is a middle ground - it is a managed Azure service, but the machines run in your own subscription. Ona is a further middle ground: its runners deploy into your own AWS or GCP VPC so code and execution stay in your network, but Ona still operates the control plane, and that option is Enterprise plan only.

Most enterprise CDEs log:

• Authentication events - Every login, logout, and failed authentication attempt
• Workspace lifecycle - Creation, start, stop, deletion timestamps
• Code access - Which repositories were cloned and when
• Resource usage - CPU, RAM, disk consumption for cost attribution
• Admin actions - Template changes, permission grants, and policy updates

Logs typically integrate with SIEM systems like Splunk, Datadog, or CloudWatch for compliance reporting.

Yes, this is a common use case. CDEs provide:

• Time-limited access - Workspaces auto-delete after contract end date
• Scoped permissions - Contractors only see repositories they need
• No code download - They can edit code but cannot clone to their personal machines
• Session recording - Some platforms can record terminal sessions for audit trails

This is why architecture matters:

• Self-hosted CDEs - Your code never leaves your AWS/Azure account. A breach of the CDE software does not expose your code.
• Managed CDEs - Your code is stored on the vendor's infrastructure. Evaluate their SOC 2 reports and incident response history.
• Mitigation - Use VPN or private networking, encrypt data at rest and in transit, and regularly rotate credentials.

High-security organizations (government, finance, healthcare) generally favor options where they own the infrastructure - Coder, Okteto, or Eclipse Che self-hosted, or Microsoft Dev Box running in their own Azure subscription. Verify the architecture claim rather than the marketing label: several platforms described online as "self-hosted" in fact keep a vendor-operated control plane.

Yes, enterprise CDE platforms support:

• SSO providers - Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, Auth0
• SAML 2.0 - Standard enterprise authentication protocol
• OIDC (OpenID Connect) - Modern OAuth-based authentication
• MFA enforcement - Require TOTP, SMS, or hardware keys for all logins

Pricing varies by platform and usage:

• Managed CDEs - GitHub Codespaces lists $0.18/hour for a 2-core machine and $0.36/hour for 4-core as of July 2026 (GitHub billing docs). Ona prices usage-based compute on its own published plans - check its pricing page directly, and note that Gitpod Classic pay-as-you-go was sunset on 10-15-2025.
• Codespaces free tier (read the units carefully) - GitHub Free accounts include 120 core-hours plus 15 GB-month of storage per month; GitHub Pro includes 180 core-hours plus 20 GB-month (GitHub billing docs, July 2026). Core-hours are not wall-clock hours: 120 core-hours is 60 hours of use on a 2-core machine, or 30 hours on a 4-core one. Most comparison articles get this wrong.
• Self-hosted CDEs - You pay cloud compute costs (AWS EC2, Azure VMs) plus any platform license. Coder has exactly two editions: Community, which is free, open source, and self-hosted, and Premium, an annual per-user contract sold through sales. Coder does not publish a Premium price, so treat any per-seat figure quoted elsewhere as unverified. DevPod (MPL-2.0) and Okteto are open source with no license fee.
• Local development - Appears free, but factor in high-spec laptop purchase and refresh costs, setup time, security risk, and the compute cost of running AI agents on local hardware

Savings come from faster onboarding, auto-stop optimization (workspaces only bill when running), and avoiding high-spec laptop purchases. Payback depends entirely on your team size, loaded salary costs, and how aggressively you configure auto-stop, so build the model with your own numbers - the "typical payback" ranges circulating online are vendor marketing, not research. See our sources page for the figures we do cite.

Consider these often-overlooked costs:

• Platform engineering time - Building and maintaining Terraform templates requires dedicated staff
• Network bandwidth - If developers frequently transfer large files, egress costs can add up
• Storage costs - Persistent volumes for each developer (100GB-1TB) accumulate quickly
• Training and adoption - Developers need time to adapt to remote workflows
• Zombie workspaces - Developers forgetting to delete old workspaces incurs unnecessary costs
• AI agent compute - Autonomous coding agents can run workspaces for hours unattended, generating unexpected compute bills if not governed by quotas

Auto-stop (also called TTL - Time To Live) automatically shuts down idle workspaces to save compute costs. Common configurations:

• Idle detection - After 30-120 minutes of no keyboard/mouse activity, workspace pauses
• Daily shutdown - Workspaces stop at 6pm and restart when developer logs in next morning
• Weekend cleanup - All workspaces stop Friday evening, saving 48 hours of compute

The saving is arithmetic, not a survey result: a workspace actually used 40 hours a week but left running around the clock bills for roughly four times the compute it needs. Measure your own idle ratio and size the saving from that rather than assuming a headline percentage.

ROI comes from several areas:

• Onboarding speed - Environment setup drops from repeated manual installation to a single templated provision. Time the current process for your own team and multiply by headcount - that number is defensible in a business case, a borrowed one is not.
• Laptop savings - Thin clients and lower-spec laptops become viable once compute lives in the cloud. Price the difference against your own hardware refresh cycle.
• Reduced environment drift - Fewer "works on my machine" investigations, because every workspace is built from the same template.
• Security incident avoidance - Preventing a single source-code leak can offset years of platform cost, though the value is inherently hard to quantify in advance.
• AI agent capacity - CDEs let AI-assisted workflows run in parallel, isolated sandboxes without extra developer hardware. Treat this as added capacity, not a guaranteed output multiplier.

There is no credible published figure for "typical" CDE ROI, so treat any dollar range you see - including on vendor sites - as marketing. What has actually been measured is adoption, not savings: DORA's State of AI-assisted Software Development (September 2025, nearly 5,000 respondents) found 90% of developers use AI in daily work, a median of roughly two hours per day, and concluded that AI acts as an amplifier of an organization's existing strengths and dysfunctions rather than a uniform productivity multiplier. Build the business case on your own baseline metrics. Full citations are on our sources page.

Choose managed CDEs if:

• You want zero maintenance and instant setup
• You have a small team (less than 50 developers)
• Your compliance requirements are minimal

Choose self-hosted CDEs if:

• You need HITRUST, FedRAMP, or strict data residency
• You have a large team (100+ developers) where per-user costs matter
• You want full control over infrastructure and customization

Most platforms support cost attribution through:

• Workspace tagging - Tag workspaces by team, project, or cost center for AWS/Azure billing reports
• Usage metrics - Track CPU-hours, storage GB, and network egress per team
• Quotas - Set team-level budgets and automatically stop workspaces when exceeded
• Integration with FinOps tools - Export to Cloudability, CloudHealth, or Kubecost for chargeback

Timeline varies by platform and complexity:

• Managed CDEs (Codespaces, Ona) - 1-2 weeks for basic setup, 1-2 months for enterprise configuration
• Self-hosted CDEs (Coder) - 2-4 weeks for pilot, 2-3 months for full production deployment
• Template development - 1-2 weeks per major stack (Node.js, Python, Java, .NET)
• SSO/compliance integration - Add 2-4 weeks for SAML, audit logging, and VPN setup

Typical staffing for self-hosted CDEs:

• Small team (less than 50 devs) - 1 platform engineer (part-time, 20-40% capacity)
• Medium team (50-200 devs) - 1-2 platform engineers (full-time)
• Large team (200+ devs) - 2-4 platform engineers plus 1 SRE for production support

Responsibilities include: maintaining Terraform templates, onboarding new teams, troubleshooting workspace issues, and monitoring cost/performance.

Phased rollout is strongly recommended:

• Phase 1 - Pilot (2-4 weeks) - 5-10 volunteer developers from a single team
• Phase 2 - Early adopters (1-2 months) - Expand to 25-50 developers across 2-3 teams
• Phase 3 - General availability (3-6 months) - Open to all developers, optional usage
• Phase 4 - Mandatory (6-12 months) - Require CDEs for new hires, contractors, or high-security projects

This approach lets you refine templates, gather feedback, and build internal champions before wide adoption.

Top failure modes:

• Poor network connectivity - Developers on slow/unreliable internet have a terrible experience
• Incomplete templates - Missing tools force developers to hack around limitations
• Lack of training - Developers resist change when they don't understand benefits
• Cost surprises - No auto-stop policies lead to budget overruns and executive backlash
• Forcing immediate migration - Requiring all developers to switch on day one causes revolt

Resistance is natural. Effective strategies:

• Start with volunteers - Find early champions who love it and evangelize internally
• Hybrid approach - Allow CDEs for heavy workloads, local dev for quick edits
• Showcase benefits - Demo faster onboarding, more powerful builds, zero setup time
• Mandatory for new hires only - Let existing devs continue locally, but new employees start with CDEs
• Compliance mandate - If security/audit requires it, it becomes non-negotiable

Yes, migration is straightforward:

• Git-based workflows - Push local commits, then clone into CDE workspace. No data loss.
• DevContainer configs - If you already use DevContainers, they work identically in CDEs
• Dotfiles sync - CDEs support dotfile repositories to preserve shell aliases, vim configs, etc.
• IDE settings - VS Code settings sync and JetBrains Settings Repository carry over automatically

GitHub Codespaces:

• Managed SaaS by GitHub, runs on their infrastructure
• Container-based only (no VMs)
• Deeply integrated with GitHub repositories
• Zero setup, instant start

Coder:

• Self-hosted in YOUR AWS/Azure/GCP account
• Supports containers, VMs, and bare metal via Terraform
• Works with any Git provider (GitHub, GitLab, Bitbucket, etc.)
• Requires platform team to manage infrastructure

The accurate answer is more nuanced than either "yes, it is open source and self-hostable" or "no, it is SaaS only" - and most write-ups pick one of those two wrong answers. There is no customer-managed self-hosted Ona today, but your source code does not have to leave your network:

• Runners in your own VPC - Ona deploys managed "runners" into your own AWS or GCP VPC. Source code and code execution stay inside your network. This is an Enterprise plan feature only.
• But the control plane is still Ona's - You do not install, upgrade, or operate the platform yourself, and you cannot air-gap it. If your requirement is that no vendor-operated control plane exists at all, this model does not satisfy it. Call it bring-your-own-cloud, not self-hosted.
• The open-source repo still exists - gitpod-io/gitpod remains public and is not archived, under AGPL-3.0. Its README now steers users to Ona's hosted product rather than to self-hosting. The separate gitpod-io/self-hosted repo is a red herring: it has been deprecated since Gitpod 0.5.0 and has been dead for years.
• Gitpod Classic pay-as-you-go sunset on 10-15-2025 - If you are working from older pricing or documentation, it no longer applies.
• Acquisition risk - read this before you commit - OpenAI announced on 06-11-2026 that it is acquiring Ona. The deal has not closed; regulatory approval is pending. Neither OpenAI nor Ona has commented on the future of the open-source repository, the Core plan, or the bring-your-own-cloud runner model. Weight that uncertainty in any multi-year platform decision, and make sure your contract covers it.
• If you need true self-hosting - Coder (Community edition is open source and self-hosted) and Okteto (open source, independent, and genuinely self-hostable) are the realistic options, with Eclipse Che as a Kubernetes-native alternative. Daytona is no longer one - see the Daytona question above.

Microsoft Dev Box is Windows-first but supports Linux:

• Windows 11 VMs - Native support, optimized for .NET, Visual Studio, and desktop apps
• WSL2 - Run Linux distributions inside Windows VMs via Windows Subsystem for Linux
• Linux VMs - Limited preview support for Ubuntu and other distributions (check Azure docs for current status)

For pure Linux workflows, Coder or Ona are better choices.

No. Daytona is still widely listed as a leading open-source CDE, and that description is now wrong on both counts:

• It left the CDE market - Daytona publicly announced it had pivoted away from cloud development environments entirely and repositioned as sandbox infrastructure for AI agents. It is no longer competing for the developer-workspace use case.
• It is no longer effectively open source - As of June 2026 the public repository is unmaintained, with core development moved to a private codebase. Do not plan a self-hosted deployment around it.
• What it is genuinely good at now - Short-lived, programmatically created sandboxes that an AI agent spins up and destroys through an SDK. That is a real product, just not a CDE.
• If you came here for open-source self-hosting - Look at Coder (Community edition), Okteto (open source, with self-hosted, SaaS, and bring-your-own-cloud options), or Eclipse Che instead.

This is a good illustration of why CDE comparison articles age badly. Check a project's commit history and its own product pages before shortlisting it.

Yes, many organizations run hybrid CDE strategies:

• Codespaces for open source - Public repos and quick experiments
• Coder for production - Proprietary code requiring strict compliance
• Dev Box for Windows teams - .NET developers needing Visual Studio
• Ona for frontend - React/Vue teams preferring browser-based IDEs

The key is standardizing on DevContainer configs so workspaces are portable across platforms.

Google Cloud Workstations is GCP's managed CDE offering:

• Managed by Google - Runs on GCP infrastructure, fully integrated with Cloud Console
• Container-based - Uses Cloud Shell-like environments with pre-installed gcloud CLI, kubectl, etc.
• IDE support - VS Code, JetBrains Gateway, or Cloud Code for VS Code

Best for: Teams already on GCP who want minimal setup and native integration with BigQuery, Kubernetes Engine, and other Google services.

AI coding agents are autonomous software tools powered by large language models (LLMs) that can write, test, debug, and refactor code with minimal human supervision. Examples in 2026 include Claude Code, Devin, GitHub Copilot Workspace, Cursor Agent, and AWS Kiro Developer Agent. They need CDEs because:

• Isolation - Agents execute arbitrary code. Running them on a developer's laptop or in production is dangerous. CDEs provide throwaway sandboxes.
• Reproducibility - Agents need consistent environments with the right toolchains pre-installed to reliably build and test code.
• Parallelism - You can spin up 10 or 50 CDE workspaces simultaneously, letting agents work on multiple tasks or branches in parallel.
• Cost control - CDE auto-stop policies prevent runaway agents from burning compute budget indefinitely.

There is a spectrum of AI involvement in software development:

• AI-assisted (copilot mode) - A human writes code with AI autocomplete suggestions. The developer stays in control. Examples: GitHub Copilot, Tabnine, and Cursor's completion mode. Codeium is often still listed here but no longer exists as a brand - it became Windsurf, and Windsurf became Devin Desktop on 06-02-2026.
• AI-directed (agent mode) - A human describes a task, and an AI agent writes, tests, and iterates on the code autonomously. The human reviews the output. Examples: Claude Code, Devin, Copilot Workspace.
• Fully autonomous - AI agents receive tasks from CI/CD pipelines, issue trackers, or other agents with no human in the loop. This is emerging in 2026 for well-scoped tasks like dependency updates, test generation, and bug triage.

CDEs become increasingly critical as you move toward autonomous development because the AI needs a safe, ephemeral environment to operate in - not a developer's laptop or a shared staging server.

LLMOps (Large Language Model Operations) is the practice of deploying, monitoring, and governing LLM-powered tools in production workflows. For CDE teams, LLMOps concerns include:

• Prompt and context governance - Controlling what code and secrets AI agents can access within a workspace. CDEs with scoped permissions prevent agents from reading repositories they should not see.
• Token and cost tracking - Monitoring LLM API spend per workspace, per team, and per project. CDE tagging and cost attribution integrate with LLMOps dashboards.
• Audit trails - Logging what an AI agent did inside a CDE workspace (commands run, files modified, tests executed) for compliance and debugging.
• Model versioning - Pinning agent behavior to specific model versions so workspace outcomes are reproducible across runs.

AI agent integration has become a key differentiator for CDE platforms:

• GitHub Codespaces - Deep integration with Copilot Workspace. Agents can create, modify, and test code in Codespaces directly from GitHub issues and pull requests.
• Coder - API-first architecture with Terraform templates lets teams define agent-specific workspace configurations, plus strong headless workspace support for CI/CD-triggered agent runs. Watch the naming churn when reading older docs: "AI Bridge" was renamed AI Gateway and "Agent Boundaries" was renamed Agent Firewall in April 2026, and Coder Tasks is being removed from new releases starting with v2.37 on 09-01-2026, superseded by Coder Agents (in beta since 05-06-2026).
• Ona - Offers ephemeral workspace APIs and microVM isolation that align well with agent workloads requiring fast spin-up and strong security boundaries. Note the pending OpenAI acquisition announced 06-11-2026 and not yet closed.
• Daytona - commonly recommended here, but not a CDE - Daytona's agent SDK is real, but the company left the CDE market and its public repository has been unmaintained since June 2026. Use it as agent sandbox infrastructure if that is what you need; do not shortlist it as a developer workspace platform.

Securing AI agent access within CDEs requires multiple layers:

• Scoped credentials - Inject only the minimum secrets needed for the task. Use short-lived tokens that expire when the workspace stops.
• Network policies - Restrict outbound network access from agent workspaces. Block internet access or allow only approved registries and API endpoints.
• Read-only source mounts - Let agents read code but require changes to go through pull requests, preventing direct commits to protected branches.
• Workspace-level isolation - Use microVM-backed workspaces so a compromised agent process cannot escape to other workspaces or the host system.
• Human-in-the-loop gates - Require human approval before agent-generated code is merged, deployed, or promoted beyond the sandbox.

Yes, and this is one of the most powerful patterns in 2026. Modern CDE platforms expose APIs that let AI agents programmatically:

• Create workspaces - Spin up a fresh environment for a specific task, branch, or pull request
• Execute commands - Install dependencies, run tests, execute builds, and analyze results
• Read and write files - Modify source code, create new files, and commit changes
• Destroy workspaces - Clean up after the task completes, leaving no lingering compute costs

This enables patterns like: an AI agent receives a GitHub issue, creates a CDE workspace, writes a fix, runs tests, opens a pull request, and tears down the workspace - all without human intervention. Coder's API is the most mature CDE-side option for this. Purpose-built agent sandbox services cover the same pattern when you only need a throwaway execution environment rather than a full developer workspace.

The AI-augmented SDLC uses CDEs at multiple stages:

• Planning - AI agents analyze codebases in CDE workspaces to estimate effort, identify dependencies, and suggest implementation approaches
• Development - Human developers and AI agents work in parallel CDE workspaces, with agents handling routine tasks (boilerplate, tests, migrations) while humans focus on architecture and business logic
• Code review - AI reviewers spin up CDE workspaces to actually build and test pull requests, going beyond static analysis to catch runtime issues
• Maintenance - Autonomous agents handle dependency updates, security patches, and technical debt reduction in isolated CDE workspaces, submitting PRs for human approval

This category churns faster than any comparison article can track. As of 07-25-2026:

• Codeium / Windsurf -> Devin Desktop - Codeium rebranded to Windsurf. OpenAI's acquisition collapsed; Google took a technology license plus an acqui-hire of the CEO and some staff, which was not an acquisition of the company. Cognition acquired the remaining Windsurf entity on 07-14-2025, and on 06-02-2026 it became Devin Desktop. Devin is also no longer $500/month - the current tiers are Free, Pro at $20, Max at $200, and Teams at $80 plus $40 per seat.
• Gemini CLI - Retired on 06-18-2026 for consumer and Pro/Ultra users and replaced by Antigravity CLI. It is still supported for Gemini Code Assist enterprise license holders, so check which of those you are before assuming it is gone.
• Amazon Q Developer - The IDE and coding product is sunsetting: new signups were blocked on 05-15-2026 and full end of support is 04-30-2027, with Kiro as the replacement. Amazon Q in the AWS Console and in Slack is not being sunset.
• MCP is no longer an Anthropic project - Anthropic donated the Model Context Protocol to the Linux Foundation's Agentic AI Foundation in December 2025. A major spec revision ships 07-28-2026 that removes protocol-level sessions entirely, so any design or documentation describing MCP as session-based needs revisiting.
• Ona - OpenAI announced an acquisition on 06-11-2026. The deal has not closed and regulatory approval is pending.
• Coder renames - "AI Bridge" is now AI Gateway and "Agent Boundaries" is now Agent Firewall, both since April 2026. Coder Tasks is being removed from new releases starting with v2.37 on 09-01-2026, superseded by Coder Agents.

The practical lesson: verify a tool's status against its own release notes and repository activity before you build a platform decision on a blog post. Our sources page lists the research we cite.