Bartek Gatz

Staff Product Manager at Coder

<p><em>This post is part of Coder Launch Week (Dec 9–11, 2025). Each day, we’re sharing innovations that make secure, scalable cloud development easier. Follow along <a href="https://launch.coder.com/">here</a>.</em></p>

<p>Have you ever found yourself working on a product filled with small bugs, paper cuts, and minor imperfections? None of them are catastrophic on their own, but together they quietly drain your team’s time and energy. Before long, your development team is buried under the weight of constant maintenance work, leaving less room for creativity, innovation, and progress on what truly matters. This is especially true in products with large codebases.</p>

<p>As a product manager, I’ve found myself in this situation many times throughout my career.</p>

<p>And when that happens, the same question always comes up:</p>

<blockquote>
<p>How can I make the team setup more efficient and improve productivity without hiring more people, without lowering quality, and without putting extra pressure on the team?</p>
</blockquote>

<p>Today, I want to share a solution that’s already making a meaningful difference for us at Coder.</p>

<h2>Choose your character: Background vs. foreground agents</h2>

<p>Before we look at the solution, it’s worth understanding how coding agents can operate in foreground and background modes. Each has a distinct purpose and level of human interaction.</p>

<h3>Foreground agents</h3>

<p><strong>Foreground agents work directly alongside humans</strong>, handling short, focused tasks where quick collaboration matters. Think of them as a paired-programming partner — you write a line of code, the agent helps with the next. The interaction is continuous and conversational, unfolding within the same environment, usually an IDE.</p>

<p>Foreground agents shine when you need real-time assistance such as code completion, debugging, or quick refactoring.</p>

<h3>Background agents</h3>

<p><strong>Background agents take a more independent role</strong>. Instead of working directly alongside humans, they handle larger, multi-step tasks on their own. They still operate within a cloud development environment, but without direct management or oversight from the user. To the human, the agent behaves like a black box – it takes an input, processes it, and returns the output. </p>

<p>The communication pattern is different as well: rather than a live dialog, it unfolds as a sequence of prompts, updates, and completion notifications. This makes background agents ideal for long-running or automated workflows where independence and consistency matter more than interactivity.  </p>

<h2>Automating the full development loop with Coder Tasks</h2>

<p>At its core, the distinction between foreground and background agents comes down to autonomy: foreground agents collaborate with you, while background agents operate independently. </p>

<p>If you&#39;re a product manager like me, chances are you spend less time writing code in an IDE and more time managing backlogs, sprint boards, and issue trackers in tools like GitHub. So we asked ourselves:</p>

<blockquote>
<p>What if a GitHub issue could trigger a fully automated implementation?</p>
</blockquote>

<p>With Coder Tasks and background agents, now it is all possible. Here&#39;s how it works:</p>

<ol>
<li>Label a Github issue with “coder”. </li>
<li>That single label triggers a GitHub action.</li>
<li>The action launches a Coder Task running Claude Code as a background agent. </li>
<li>Once the workspace is ready, the agent picks up the issue and begins working on it.</li>
<li>It reads the description, comments, links and context directly from GitHub.</li>
<li>When it finishes, it opens a pull request linked back to the original issue.</li>
<li>If it gets stuck, Coder notifies you so you can intervene.</li>
</ol>

<p>That&#39;s it! A simple label in GitHub can now start the entire process, taking an issue all the way to a pull request with minimal human involvement.</p>


<h3>Why this works so well</h3>

<p>All the context needed for the agent to succeed is already in GitHub. Your team’s usual process already provides the structured input the agent depends on:</p>

<ul>
<li>Proper documentation in your codebase for AI agents (see <a href="https://agents.md/">AGENTS.md</a>)</li>
<li>Writing clear requirements</li>
<li>Defining scope</li>
<li>Outlining success criteria</li>
<li>Linking to relevant parts of the codebase, diagrams, screenshots, etc.</li>
</ul>

<p>For teams which are sharing their backlogs with the community, that context can even include direct feedback or reports from users in the issue thread.</p>

<p>Because the agent automatically pulls this information, developers don’t have to spend extra time guiding or re-explaining the task. The agent starts with the same well-documented context that humans use. The difference is that it can immediately begin acting on it.</p>

<p>This approach also helps address one of the most common concerns customers have about AI-driven development: <em>“Can agents really understand what we want?”</em> In GitHub, your organization already enforces strong documentation habits and clarity standards. The agent simply benefits from that existing culture of precision and transparency.</p>

<p>And in some cases, the flow can be completely autonomous. For example:</p>

<ul>
<li>Any issue submitted with the “bug” label could automatically trigger a task template designed to reproduce and investigate user-reported issues.</li>
<li>By the time a developer opens the workspace, the bug has already been reproduced and analyzed by Claude Code, ready for inspection, corrections and merging.</li>
</ul>

<p>At Coder, we already use this workflow internally. Every AI-generated pull request is reviewed by a human expert, and if changes are needed, the process can either be repeated or the code corrected manually. This keeps quality high while maintaining the speed and efficiency of the automated flow. </p>

<h2>Get started with a GitHub Action template and guide</h2>

<p>Coder Workspaces already provide a solid foundation for running background agents safely, securely, and independently of local machines. I won’t go into the details of that here, as this topic has already been <a href="https://coder.com/blog/launch-week-2025-introducing-coder-tasks">covered in depth elsewhere</a>.</p>

<p>What I want to highlight here is the concept of the GitHub loop described above, and how easy we&#39;ve made it for any team to replicate in just a few minutes.</p>

<p>To make that possible, we’re providing a clear, step-by-step guide: <a href="https://coder.com/docs/ai-coder/github-to-tasks">GitHub to Coder Tasks - HowTo Draft</a> </p>

<p>The guide includes everything you need: </p>

<ul>
<li>A ready-to-use GitHub Action that triggers the workflow </li>
<li>A refined Coder Template that uses Claude Code as a background agent</li>
</ul>

<p>This is the exact setup I personally use at Coder to trigger implementations of features and bug fixes. It’s already proven itself in real-world conditions.</p>

<p>Please note that this GitHub integration is just the beginning. It’s powered by the new API and CLI capabilities we’ve built into Coder to manage Tasks. These foundations make it easy to connect Coder with other tools in your ecosystem just as easily. We’ll continue adding more examples like this to help you get started quickly, without having to piece everything together on your own.</p>

<h2>Coder Tasks enters general availability</h2>

<p>The December release of Coder 2.29 marks a major milestone for the Coder Tasks feature: we’re officially moving from <em>Beta</em> to <em>General Availability (GA)</em>. This means that Tasks will be fully supported in both staging and production environments, and we’ll also be committing to REST API and CLI stability guarantees. </p>

<p><img src="https://www.datocms-assets.com/19109/1765330685-coder-tasks.png" alt=""></p>

<p>Yesterday, we highlighted our new <a href="https://coder.com/docs/ai-coder/ai-bridge">AI Bridge</a> and <a href="https://coder.com/docs/ai-coder/agent-boundary">Boundary</a> features. Together, these updates make it easier to use AI coding agents safely and with greater control inside Coder workspaces.</p>

<p>Looking ahead to 2026, we&#39;ll continue investing in new ways to bring background agents even closer to where you already work. Our goal is to make this technology feel less like an external tool and more like a natural extension of your development process.</p>

<h2>Share your feedback</h2>

<p>I’m curious to hear what you think. What would make this even more valuable for you and your team?</p>

<p>Your perspective helps us shape what comes next for Coder.</p>

<p>Join the discussion on the official <a href="https://discord.gg/coder">Coder Discord</a> and share your thoughts. Whether you’ve already tried running background agents or are just starting to explore the concept, your input is invaluable.</p>


What if a GitHub issue could trigger a fully automated implementation? With Coder Tasks and background agents, now it is all possible.

GitHub to Coder Tasks

From GitHub Issue to Pull Request: Powered by Coder Tasks and Claude Code Coding Agent

<p><em>April 2026 update: This post references Coder Tasks, an earlier approach to orchestrating agent workflows on Coder infrastructure. For the latest capabilities, check out <a href="https://coder.com/docs/ai-coder/agents">Coder Agents</a>.</em></p>

<hr>

<p>When we introduced Coder Tasks in July 2025 with Coder v2.24, the feature offered a way to run low-interaction jobs with minimal manual involvement. This was perfect for agentic AI workflows, routine maintenance tasks, and other scenarios where developers didn’t want to navigate through multiple UI screens just to launch or monitor a process.</p>

<p>However, the initial release had a major limitation: everything had to be done through the Coder UI. Creating a task, checking its status, viewing logs, or sending additional prompts required point-and-click interaction. This made sense for early experimentation but quickly became a roadblock for teams looking to integrate Coder Tasks into real automation workflows.</p>

<p>Platform teams wanted to trigger tasks as part of CI/CD pipelines. DevOps engineers needed to incorporate them into GitOps-style deployments. Developers hoped to orchestrate them through internal tools or event-driven systems. But without API or CLI access, tasks couldn’t be created automatically, monitored programmatically, or connected seamlessly to existing toolchains.</p>

<p>With our latest release (Coder v2.27), that limitation disappears. The addition of REST API and CLI support for Coder Tasks means you can now create, manage, and interact with tasks entirely through code. Whether it’s integrating with GitHub Actions, scripting automated environment cleanups, or driving complex AI workflows, the full lifecycle of a task is now available programmatically with no UI interaction required.</p>

<h2><strong>What you can do now</strong></h2>

<p>With the CLI, you can list all existing tasks, create new ones either interactively or in fully automated fashion, check their status, retrieve logs, or even inject additional prompts into a running task: a feature especially useful for long-running AI jobs that might need extra context along the way. Deleting tasks when they’re no longer needed is just as straightforward.</p>

<p>Here’s a quick reference for the CLI commands:</p>

<table><thead>
<tr>
<th>Command</th>
<th>Description</th>
</tr>
</thead><tbody>
<tr>
<td><code>coder exp task list</code></td>
<td>List all tasks currently in the system.</td>
</tr>
<tr>
<td><code>coder exp task create</code></td>
<td>Create tasks using a defined task template, interactively or via flags for automation.</td>
</tr>
<tr>
<td><code>coder exp task delete</code></td>
<td>Terminate an existing task, similar to deleting a workspace.</td>
</tr>
<tr>
<td><code>coder exp task status</code></td>
<td>Create tasks using a defined task template, interactively or via flags for automation.</td>
</tr>
<tr>
<td><code>coder exp task log</code></td>
<td>Display a one-line status update for any task.</td>
</tr>
<tr>
<td><code>coder exp task send</code></td>
<td>Send additional prompts to a running task, either inline or from a file.</td>
</tr>
</tbody></table>

<p>On the API side, you have access to a dedicated  <a href="http://coder-server:8080/api/experimental/tasks/">http://coder-server:8080/api/experimental/tasks/</a>
 branch under the Coder API, supporting the full lifecycle of a task. Here’s a quick reference for the REST API commands:</p>

<table><thead>
<tr>
<th><strong>Method</strong></th>
<th><strong>Endpoint</strong></th>
<th><strong>Description</strong></th>
</tr>
</thead><tbody>
<tr>
<td><code>GET</code></td>
<td><code>/tasks</code></td>
<td>List all tasks</td>
</tr>
<tr>
<td><code>GET</code></td>
<td><code>/tasks/{id}</code></td>
<td>Retrieve the status of a single task</td>
</tr>
<tr>
<td><code>POST</code></td>
<td><code>/tasks</code></td>
<td>Create a new task</td>
</tr>
<tr>
<td><code>GET</code></td>
<td><code>/tasks/{id}/logs</code></td>
<td>Fetch logs for a specific task</td>
</tr>
<tr>
<td><code>POST</code></td>
<td><code>/tasks/{id}/send</code></td>
<td>Send additional prompts to a running task</td>
</tr>
<tr>
<td><code>DELETE</code></td>
<td><code>/tasks/{id}</code></td>
<td>Delete a specific task</td>
</tr>
</tbody></table>

<h2><strong>Unlocking new use cases</strong></h2>

<p>By introducing these capabilities, we’ve effectively turned Coder Tasks into first-class citizens for automation. Now, a GitHub Action can automatically trigger a Coder Task whenever a pull request is opened. A nightly CI/CD job can use tasks to perform quick analysis of freshly-reported issues. AI-driven tasks can request additional prompts mid-run, entirely through code.</p>

<p>For DevOps and platform teams, this opens the door to building richer internal workflows that don’t rely on manual intervention. And for developers, it means less time clicking through UIs and more time focusing on building the automation they need. Ben Potter, VP of Product at Coder, says:</p>


<blockquote>
<p>Our Tasks API lets you programmatically work with popular agents like Claude Code, without having to worry about the underlying infrastructure or Coder-isms like workspaces, builds, or templates. We expect customers to integrate Tasks into GitHub Actions, CI/CD pipelines, Slack, and anywhere else their developers are.</p>
</blockquote>


How Coder is Automating Workflows with Coder Tasks Today

<h2><strong>Getting started</strong></h2>

<p>If you want to try this out, the best place to begin is with our documentation for both the <a href="https://coder.com/docs/reference/cli">CLI</a> and <a href="https://coder.com/docs/reference/api">API</a>.</p>

<p>Alternatively, you can simply open a terminal and type:</p>


<p>This will give you a quick overview of the available CLI commands and their options so you can start experimenting right away.</p>

<h2><strong>Known limitations</strong></h2>

<p>As of release 2.27, the CLI and API remain in their “experimental” phase. The Coder Tasks feature itself is currently in Beta, with both the CLI and API scheduled to reach General Availability (GA) at the same time as Coder Tasks’ GA release, planned for the end of 2025.</p>

<p>As with any new feature, there are a few things to be aware of. Task Templates still need to be defined the traditional way via Terraform, and there’s currently no real-time streaming or webhook support for task status or logs. This means you’ll need to poll for updates rather than subscribing to push-based notifications. Finally, while the core lifecycle operations are supported via the CLI and API, some UI-only features (particularly visualizations) aren’t available outside the Coder interface just yet.</p>

<p>Having said that, please also take a look at the new Notification announcements which make it possible to subscribe to Coder Tasks’ status changes events.</p>

<h2>Integrate Coder Tasks into your automation workflows now</h2>

<p>The bottom line is simple: if you’ve been waiting to integrate Coder Tasks into your automation workflows, the wait is over. With full CLI and API support, you can now build pipelines, scripts, and event-driven systems around Coder Tasks just like any other programmable infrastructure component. It only takes a few minutes to get started, and the possibilities for automation are nearly endless.</p>


Coder Tasks are now equipped with CLI and REST API functionality, enabling GUI-less operations for your automation workflows.

Coder Tasks vis CLI and API

Automate Coder Tasks via CLI and API

<p>With the release of Coder v2.27, we’re giving both administrators and developers more powerful ways to stay informed. Until now, Coder’s notification system relied primarily on predefined, system-generated events. While useful, it left limited room for customization or user control.</p>

<p>That changes today. Two major enhancements arrive in v2.27:</p>

<ul>
<li><strong>Custom Notifications</strong> — a flexible new mechanism allowing notifications to be triggered directly from inside Coder-managed workspaces.</li>
<li><strong>Coder Task Notifications</strong> — automatic alerts when long-running tasks complete or require additional input.</li>
</ul>

<p>Together, these features make it easier than ever to focus on what matters, confident you’ll be notified when action is needed.</p>


<h2>A new era of notifications in Coder</h2>

<p>Before v2.27, Coder notifications were tightly bound to built-in system events. Administrators who wanted to enhance Coder templates with additional alerts triggered by specific environment events had no direct way to do so through Coder itself. Developers using workspaces faced similar challenges: if they wanted to customize their environment with additional notifications, there was no native way to notify anyone through the platform.</p>

<p>The same problem applied to Coder Tasks. These tasks can take a long time to finish and some require user input mid-run. Without notifications, users had two bad options: either keep checking manually or risk finding out too late that a task was blocked or had already finished hours ago.</p>

<p>The goal of these new features is simple: stop forcing users to babysit their work. Let them focus on more important activities and notify them only when their attention is required.</p>


<h2>What’s new in v2.27</h2>

<p>These two features give Coder users and admins more control, flexibility, and confidence. Developers can finally walk away from long-running jobs or complex tasks without fear of missing something important.</p>

<p>In short, <strong>notifications now work the way you need them to:</strong> customized, actionable, and integrated directly into your workflows.</p>

<h3>1. Custom Notifications</h3>

<p>Custom Notifications open up the Coder notification system for both administrators and developers.</p>

<ul>
<li>Template administrators can script notifications to fire automatically when specific events occur inside a workspace. For example, if a critical metric crosses a threshold, the workspace can immediately notify the right people without any manual intervention.</li>
<li>Developers can trigger their own notifications with a simple CLI command, such as when a long-running job finishes or when a certain condition is met inside the workspace.</li>
</ul>

<p>The syntax is straightforward:</p>

<p><code>coder notifications custom &quot;Custom Title&quot; &quot;Custom Message”</code></p>

<p>Notifications can be delivered via email, webhooks, and directly into the Coder Inbox, depending on how your environment is configured.</p>

<h3>2. Notifications for Coder Tasks</h3>

<p>The second major addition in v2.27 focuses on Coder Tasks. Users now receive notifications whenever a task changes its state, for example, when it finishes running or becomes idle waiting for additional input.</p>

<p>This means users can launch multiple tasks at once, switch to other work, and rely on notifications to call them back only when action is needed. No more checking every few minutes or discovering hours later that a task has been stuck waiting on them.</p>


<h2>Getting started with Custom Notifications and Coder Task Notifications</h2>

<p>Both features build on Coder’s existing notification system, so there’s very little setup required.</p>

<ul>
<li>For <strong>Custom Notifications</strong>, administrators can integrate scripts directly into workspaces, while developers can issue notifications manually or automatically using the CLI.</li>
<li>For <strong>Coder Task Notifications</strong>, users simply need to ensure notifications are enabled in their account settings. By default, these alerts will be sent for any task-enabled workspace with no extra configuration required.</li>
</ul>

<p>Upgrade to <strong>Coder v2.27</strong> and start using:</p>

<ul>
<li><strong>Custom Notifications</strong> to script your own alerts for any event in a workspace.</li>
<li><strong>Coder Task Notifications</strong> to stay informed when long-running or interactive tasks need your attention.</li>
</ul>

<p>Check out the <a href="https://coder.com/docs/reference/cli">Coder CLI documentation</a> and <a href="https://coder.com/docs/admin/monitoring/notifications">online help on Notifications</a> to get started today.</p>


These two features give Coder users and admins more control, flexibility, and confidence. Developers can finally walk away from long-running jobs or complex tasks without fear of missing something important. In short, notifications now work the way you need them to: customized, actionable, and integrated directly into your workflows.

Smarter Notifications in Coder

Introducing Smarter Notifications in Coder

<p><em>This post is part of Coder Launch Week (July 7–11, 2025). Each day, we’re sharing innovations that make secure, scalable cloud development easier. Follow along <a href="https://launch.coder.com">here</a>.</em></p>

<h2>Prebuilt Workspaces: Fast startup for the agentic era</h2>

<p><em>Cut wait times and context switching with developer environments that are ready before you are.</em></p>


Workspace Presets and Prebuilds Demo |  On demand remote environments

<h3>Challenge: Minutes matter in modern dev flows</h3>

<p>Cloud development environments (CDEs) already remove much of the manual setup involved in getting started with coding. But even with Coder, developers often wait minutes for a workspace to fully provision, especially in environments that require GPU resources or rely on long-running initialization scripts.</p>

<p>As we move toward more autonomous development flows including AI-provisioned workspaces, speed and scale are no longer luxuries—they’re table stakes. </p>

<h3>Solution: Start workspaces in seconds with Prebuilt Workspaces</h3>

<p>Prebuilt Workspaces solve this challenge. For complex workspaces, this feature slashes startup time from several minutes (and as much as 20 minutes in extreme cases) to under a minute without the expense of always-on infrastructure. Developers and AI agents can begin work immediately—ideal for onboarding, PR reviews, or quick experiments.</p>

<p>By pooling and preparing environments ahead of time, Coder enables on-demand, fully-configured workspace launches in seconds. This brings together the best of both worlds: the speed of persistent systems, and the efficiency of ephemeral infrastructure.</p>

<p><em>Let the machines do the waiting. Prebuilt Workspaces make sure every second counts for developers and agents.</em></p>

<h4>New for General Availability</h4>

<p>After <a href="https://coder.com/docs/admin/templates/extending-templates/prebuilt-workspaces">months of beta testing</a>, we’ve focused on behind-the-scenes improvements to deliver enterprise-grade stability, reliability, and scale. At Coder, we dogfood everything we ship — we’ve used Prebuilt Workspaces extensively to build Coder itself. The screenshot below shows an unclaimed workspace, owned by the <code>prebuilds</code> user, waiting in the pool for a developer to pick up.</p>

<p><img src="https://www.datocms-assets.com/19109/1752128037-prebuilds.png" style="max-width:100%" /></p>

<p>General Availability is just the start. Coming soon:</p>

<ul>
<li><strong>Advanced time reporting</strong>: Track prebuild durations, claim times, and total time saved. This gives platform teams better visibility into impact and ROI.</li>
<li><strong>Git identity for prebuilds</strong>: Add support for Git authentication before a workspace is claimed, improving security and automation in AI-driven workflows.</li>
</ul>

<h4>Why it matters for agentic AI</h4>

<p>As workflows shift toward agentic AI, workspace sessions per developer will surge. Agents that analyze, generate, and test code autonomously will often run in multiple workspaces simultaneously to accomplish tasks at machine speed.</p>

<p>Prebuilt Workspaces enable this new paradigm by removing the startup latency bottleneck. Paired with <strong>Workspace Presets</strong> — pre-validated configuration templates — they enable teams to launch AI-enabled environments quickly and reliably. Developers triggering experiments need workspace creation to be <strong>fast, stable, and repeatable</strong> — and now they are.</p>

<p>Pooling warm environments strikes a balance between speed and efficiency. This avoids the idle cost of always-on compute while still delivering instant access for developers and agents.</p>

<h3><strong>Get started with Prebuilt Workspaces</strong></h3>

<p>To enable Prebuilt Workspaces, template admins define a <code>prebuilds</code> block in a <code>coder_workspace_preset</code>, specifying how many ready-to-claim instances to maintain. Once published, Coder automatically provisions and manages the pool behind the scenes. Developers using a matching preset get a ready-to-code workspace in seconds—no extra steps required.</p>

<p>Coder continuously manages the pool through a built-in reconciliation loop, and admins can monitor unclaimed prebuilt workspaces directly from the dashboard or via Prometheus metrics.</p>

<p><a href="https://coder.com/docs/admin/templates/extending-templates/prebuilt-workspaces">Read our docs</a> to learn more.</p>

<hr>

<h2>Dev Containers: Improved native support</h2>

<p><em>Simplify environment management and streamline workspace setup.</em></p>


Dev Containers Demo | First-class, fully integrated support for the complete spec

<h3>Challenge: “It works on my machine”</h3>

<p>As more teams adopt AI agents to spin up workspaces, run experiments, or automate development tasks, these agents rely on deterministic, self-contained environments to operate reliably. But managing these setups often falls on platform administrators, creating a bottleneck. Developers are left waiting — or worse, debugging environment mismatches. </p>

<p>To address this, teams are turning to <a href="https://containers.dev/">Dev Containers</a>, the standard for defining portable, reproducible development environments using configuration files stored alongside your code, typically in a <code>.devcontainer</code> folder within a repository. They leverage Docker to specify the tools, runtimes, extensions, and settings required for a project, ensuring that every developer — or CI system — gets an identical, reproducible setup. This setup can be launched automatically by supported tools like VS Code or GitHub Codespaces, reducing on-boarding time and eliminating “works on my machine” issues.</p>

<p>Tools like <a href="https://github.com/coder/envbuilder"><code>envbuilder</code></a> offer a way to approximate Dev Container setups in Coder by applying environment configurations directly to the workspace, but they fall short when it comes to supporting multi-container workflows, fast rebuilds, and full alignment with the Dev Containers specification.</p>

<h3>Solution: First-class Dev Container support</h3>

<p>At Coder, our goal is to make Dev Container support <strong>seamless and invisible</strong> not just for developers, but also for the automated systems or agents working alongside them. This release brings us closer to fully hands-off environment provisioning, ensuring that whether a workspace is launched by a human or an agent, the environment “just works” every time.</p>

<p>With this release, Coder introduces <strong>flexible support for Dev Containers</strong> by allowing template admins to configure the desired level of automation. You can choose to:</p>

<ul>
<li><strong>Automatically start Dev Containers</strong> based on the <code>devcontainer.json</code> definition whenever a workspace starts, or</li>
<li><strong>Allow workspace users to start Dev Containers manually</strong> at their discretion.</li>
</ul>

<p>In both cases, <strong>Coder automatically detects and connects to running Dev Containers</strong>, ensuring seamless integration into the workspace environment. Relevant ports and running applications are surfaced directly in the Coder UI.</p>

<p>We’ve also significantly improved compatibility with the Dev Containers specification and removed the need for <a href="https://coder.com/docs/admin/templates/managing-templates/devcontainers/add-devcontainer#envbuilder-terraform-provider">manual configuration with</a> <code>envbuilder</code>.</p>

<p>Additionally, this release includes <strong>support for multiple Dev Containers per workspace</strong>, making it easier to work with complex development setups.</p>

<p>Using Dev Containers also shifts the responsibility of environment setup from the Coder platform admins managing the images onto the developers working on the projects. This removes management bottlenecks and gives developers direct control over their own environments.</p>

<h4>Working with Dev Containers in Coder</h4>

<p>To enable the integration, simply ensure the <code>devcontainer.json</code> file is present in your project repository and that your workspace template is configured for the new integration. Full instructions are available here: <a href="https://coder.com/docs/admin/templates/extending-templates/devcontainers">Dev Containers Integration Guide</a>. From there, Coder takes care of the rest—automatically detecting changes to the <code>devcontainer.json</code> and prompting users to rebuild as needed.</p>

<p>When Dev Containers are present, the <strong>Coder UI exposes service ports</strong> for both the parent workspace and each individual container. This makes it easy to access and debug applications running anywhere in your environment. To avoid confusion, parent workspace applications are hidden by default when Dev Containers are detected. You can access them via the “Show parent apps” button.</p>


<h4>Live editing and rebuilds</h4>

<p>Because the <code>devcontainer.json</code> file lives in your codebase, it can be edited just like any other source file. When changes are made, <strong>Coder automatically detects the update</strong> and notifies users with the option to rebuild the container. This ensures your environment is always aligned with the latest configuration.</p>

<p><img src="https://www.datocms-assets.com/19109/1752126841-dev-container-2.png" style="max-width:100%" /></p>

<h4>Using <code>envbuilder</code> today?</h4>

<p>If you are currently using <code>envbuilder</code>, you can continue to do so without making any changes to your existing configurations. Coder will maintain support for <code>envbuilder</code> alongside the new Dev Container integration until further notice.</p>

<p>It’s important to note that <code>envbuilder</code> doesn’t run Dev Containers directly. Instead, it interprets the <code>devcontainer.json</code> file and applies changes to the parent workspace — without fully adhering to the Dev Containers standard. Instead of launching actual containers, it transforms the container in which it is running based on the definitions in the <code>devcontainer.json</code> file. While this transformation is robust, it introduces several limitations:</p>

<ul>
<li>Limited support for fast rebuilds when the <code>devcontainer.json</code> file changes</li>
<li>Inability to use multiple Dev Containers within a single workspace and in particular the inability to use <code>docker-compose</code></li>
<li>No separation between the parent workspace and the dev container — they effectively merge under <code>envbuilder</code></li>
</ul>

<p>While it may be possible to work around some of these limitations by manually adjusting the template, doing so typically requires significantly more effort compared to using the new Dev Containers integration introduced in Coder v2.24.</p>

<p>If you decide to switch over to the new Dev Containers integration, ensure the following prerequisites are met:</p>

<ul>
<li>Your workspaces must support running a Docker container runtime (e.g., Docker-in-Docker, or DinD), and a Docker socket must be available</li>
<li>The <code>@devcontainers/cli</code> utility must be installed in the workspaces (this process can be automated by Coder’s <a href="https://registry.coder.com/modules/coder/devcontainers-cli">Devcontainer-CLI module</a>), and the necessary template configuration steps must be completed as outlined in the <a href="https://coder.com/docs/admin/templates/extending-templates/devcontainers#install-the-dev-containers-cli">Dev Containers guide</a></li>
</ul>

<h3>Get started with Dev Containers</h3>

<p>We’re excited to roll out native Dev Containers support in Coder 2.24 — and we’d love your feedback.</p>

<p>If you have questions, feedback, or feature requests, reach out via <a href="mailto:support@coder.com">Coder Support</a> or drop into our <a href="https://discord.com/channels/747933592273027093/991429648200245358">Discord #feedback channel</a>.</p>


Cut wait times and context switching with developer environments that are ready before you are.

Day 4: Instant Infrastructure – Ready-to-Code in Seconds

<p>Coder Prebuilt workspaces slash workspace startup times to under a minute—without the cost of always-on environments running for every developer.</p>

<p>Cloud Development Environments (CDEs) like Coder already make it easier to spin up development environments without lengthy manual setup every time the environments are built. But even with CDEs, developers can still wait several minutes—or longer—for a workspace to be provisioned. Provision times can be particularly long when using public clouds with limited availability of resources like GPUs, or when startup scripts take several minutes to run. Prebuilt workspaces change that by offering ready-to-use environments that deliver much shorter startup times.</p>

<h1>Optimizing for Flow</h1>

<p>The traditional workaround for avoiding cold-start delays is to keep workspaces running around the clock—even when they’re not being used. This eliminates startup time for returning users, but it leads to high <strong>idle cost</strong>, with environments burning through compute and storage without delivering value.</p>

<p><strong>Coder Prebuilt workspaces</strong> take a different approach: they intentionally trade some infrastructure efficiency for <strong>developer immediacy</strong>. By maintaining a controlled pool of warm, ready-to-go workspaces, teams can deliver <strong>much faster workspace launches</strong>—a game-changer for scenarios like:</p>

<ul>
<li><strong>On-boarding</strong> new engineers with zero friction </li>
<li><strong>Ephemeral workspaces</strong> for quick experiments, reviews, or workshops </li>
<li><strong>Scheduled training sessions</strong> and live demos without setup delays </li>
</ul>

<p>We’re making Prebuilt workspaces available in beta with Coder v2.22, giving teams a smarter, faster, and more cost-efficient way to deliver instant development experiences.</p>

<h1>The Details: How Coder Prebuilt Workspaces Work</h1>

<p>Prebuilt workspaces build on top of our <a href="https://coder.com/docs/admin/templates/extending-templates/parameters#workspace-presets-beta"><strong>Presets</strong></a> feature, which entered beta several months ago.</p>

<p><strong>Presets</strong> allow template admins to define curated combinations of settings—think of them as pre-configured workspace “flavors”—which developers can select during workspace creation. This simplifies setup and enforces consistency.</p>

<p>With Prebuilt workspaces, we take it a step further: admins can now have a pool of each preset-configured workspace ready at all times.</p>

<p>To configure Prebuilt workspaces, the preset definition needs to be extended with a <code>prebuilds</code> section that specifies how many workspaces should be kept in the pool for a given preset.</p>

<p>Here is a Terraform file code example:</p>

<pre><code class="json">data &quot;coder_workspace_preset&quot; &quot;goland&quot; {
  name = &quot;GoLand: Large&quot;
  parameters = {
    cpus          = 8
    memory        = 16
  }
  prebuilds {
    instances = 3  # Number of prebuilt workspaces to maintain
  }
}
</code></pre>

<p>Each <strong>Prebuilt Workspace pool</strong> corresponds to a specific preset and is stocked with fully-created workspaces that are waiting to be claimed. When a developer requests a matching workspace, Coder assigns them one directly from the pool. Before the workspace can be used it needs to be re-assigned to the new user. Since everything is already built and resourced, the complete re-assignment process, including <code>terraform apply</code> typically does not take longer than 30 seconds. </p>

<table><thead>
<tr>
<th></th>
<th><strong>Without Prebuilt Workspace</strong></th>
<th><strong>With Prebuilt Workspace</strong></th>
</tr>
</thead><tbody>
<tr>
<td>Workspace Request</td>
<td>Provisioned on-demand (cold start)</td>
<td>Pulled from warm pool</td>
</tr>
<tr>
<td>Startup Time</td>
<td>up to 15-20 minutes in complex cases</td>
<td>&lt;1 minute</td>
</tr>
<tr>
<td>Resource Cost</td>
<td>Low when idle, high if always-on</td>
<td>Optimized via pooling</td>
</tr>
</tbody></table>

<p>Naturally, this is a high-level explanation. Behind the scenes, the system runs a <strong>reconciliation loop</strong> that continuously monitors, replenishes, and manages the workspace pool. If you’re curious about the underlying mechanics, check out the <a href="https://coder.com/docs/admin/templates/extending-templates/prebuilt-workspaces">Prebuilt Workspaces documentation</a>.</p>

<h1>What’s Available in Beta—and What’s Coming Next</h1>

<p>The beta version of <strong>Prebuilt workspaces</strong> is already <strong>fully functional</strong>. You can configure, pool, and assign workspaces to developers. Based on internal testing and early usage, the feature is stable—and we’re actively working to identify and address edge cases.</p>

<p>Our main focus right now is on <strong>ensuring robustness and reliability</strong>. Looking ahead to general availability (GA), one of the key enhancements we’re planning is <strong>auto-scaling</strong>: the ability to dynamically adjust the number of prebuilt workspaces in the pool based on time-of-day and usage patterns to help teams optimize for both speed and cost.</p>

<h1>Understanding the Cost Trade-Off</h1>

<p>Although Prebuilt workspaces save your developers time, they do have an impact on <strong>infrastructure costs</strong>.</p>

<p>Even if a Workspace hasn’t been claimed yet, it still reserves CPU, memory, and storage resources. This means you’ll see a rise in baseline consumption as you maintain pools of warm workspaces.</p>

<p>To help manage these costs, the Workspaces page in Coder gives you clear visibility into your Prebuilt workspaces. You can filter the list to show only prebuilt instances, making it easy to monitor how many are active and assess their potential impact on infrastructure usage. For monitoring of prebuilt workspaces, consider using our  <a href="https://coder.com/docs/admin/templates/extending-templates/prebuilt-workspaces#monitoring-and-observability">built-in observability tools and Prometheus metrics</a>.  </p>


<h1>Try It Out and Share Your Feedback</h1>

<p>We’re excited to bring <strong>Prebuilt workspaces</strong> to you in beta—and we’d love to hear how it works in your environment.</p>

<p>Whether you’re reducing wait times for your team, experimenting with different pool sizes, or testing performance under load, your insights are incredibly valuable to us. Your feedback helps us refine the experience and prioritize the features that matter most.</p>

<p>If you’re trying out Prebuilt workspaces, please <strong>send us your thoughts, issues, or suggestions</strong> by reaching out through <a href="mailto:support@coder.com">Coder support</a> or <a href="https://discord.com/channels/747933592273027093/991429648200245358">Coder Discord</a> #feedback.</p>


Coder Prebuilt Workspaces slash workspace startup times to under a minute—without the cost of always-on environments running for every developer.

Introducing Coder Prebuilt Workspaces: Ready-to-Use Workspaces Without the Wait

Bartek Gatz is a Staff Product Manager at Coder, where he leads strategy and execution for core platform capabilities that power secure, scalable cloud developm

Bartek Gatz

Explore the latest from Bartek

From GitHub Issue to Pull Request: Powered by Coder Tasks and Claude Code Coding Agent

Automate Coder Tasks via CLI and API

Introducing Smarter Notifications in Coder

Day 4: Instant Infrastructure – Ready-to-Code in Seconds

Introducing Coder Prebuilt Workspaces: Ready-to-Use Workspaces Without the Wait

Related content

Coder Named to Redpoint’s 2026 InfraRed 100

In The Age Of AI, Dev Workloads Are Cloud Workloads

Deploying AI Agents at Scale Without Sacrificing Control & Governance