Jiachen Jiang

Senior Product Manager

Announcing the general availability of Shared Workspaces and Service Accounts in Coder: secure, policy-controlled multi-user access to the environments where work actually happens.

Shared Workspaces: From Personal Sandboxes to Secure Team Infrastructure

Shared Workspaces is one of the <a href="https://github.com/coder/coder/issues/2425">most requested features</a> in Coder’s history, and for good reason. The capability solves a wide range of problems, from getting help when something goes wrong with your workspace to setting up dev environments shared across your team. Up until now, however, there hasn’t been a clean and secure solution.

That all changes with the GA of Shared Workspaces. This release goes beyond peer-to-peer sharing for one-off collaboration. Instead, it lets teams collaborate inside the same running Coder workspace while enjoying enterprise-grade controls around who can share, who can join, and how access is audited.

GA includes Service Accounts in our Premium plan, which offer a secure way to manage team-owned shared workspaces. In other words, they can be owned by a non-human and persistent identity instead of an individual employee with personal credentials that can be exposed.

<h2>Why secure collaboration in remote environments can be hard</h2>

Coder was built to give every developer a consistent, secure, cloud-based development environment. That model works, up until teams need to work together inside those environments.

Without secure shared access, teams resort to workarounds that are slow, risky, or both.

<ul>
<li><a href="https://coder.com/docs/user-guides/workspace-access/port-forwarding#sharing-ports">Port sharing</a> or <a href="https://registry.terraform.io/providers/coder/coder/latest/docs/resources/app"><code>coder_app</code></a> resources give surface-level visibility, but collaborators can’t access the terminal, files, or running processes inside the workspace.</li>
<li>VS Code Live Share helps with editor-level collaboration, but it’s not environment-level access (services, processes, long-lived state) and it isn’t designed for governed, long-lived sharing.</li>
<li>SSH key or credential sharing under pressure (incidents, handoffs, cross-team debugging) creates security risk that’s hard to unwind.</li>
<li>Platform teams lack a safe, temporary, auditable way to grant access without building custom tooling around keys, bastions, or VM-level credentials.</li>
</ul>

Secure multi-user access to development environments is at once more urgent and challenging to implement than ever. This is due to the rise of AI coding agents, many of which work at the environment level as opposed to the IDE, and need similar permissions for accessing code, tools, and services as human developers. They&#39;re often granted broad access with low scrutiny, while carrying a much higher potential for damage.

Shared Workspaces GA steps up to meet that challenge.

<h2>What shipped</h2>

Shared Workspaces GA allows multiple users to access the same Coder Workspace, as long as it has been shared to them by a workspace owner or Coder administrator. Collaborators authenticate with their existing Coder account to access the same files, tools, services, and running processes as the owner.

Administrators can customize sharing with automations. For example, grant and rescind access for a specific set of users on a given schedule using a combination of service account ownership and template configuration.

This enables users to go beyond peer-to-peer sharing and access the team-owned environment patterns that enterprises need:

<ul>
<li>Workspaces persist beyond individual employees: When someone leaves the company, service-account-owned workspaces continue running. No scrambling to recover state.</li>
<li>Credentials are protected: A shared workspace authenticates to external systems as the service account, not as an individual person. There is no personal information in the workspace to be exposed.</li>
<li>Access is auditable: Administrators can see who accessed a shared workspace and when. </li>
<li>Policy controls are built in: Admins with a Premium plan can restrict sharing to service-account-owned workspaces only. This blocks peer-to-peer sharing, which carries more risk in compliance-sensitive deployments.</li>
</ul>

<h2>Use cases</h2>

Here are a few patterns that Shared Workspaces + Service Accounts make possible.

On-call troubleshooting: A service-account-owned workspace pre-loaded with debugging tools, production read-only access, and diagnostic dashboards gives any engineer on the on-call rotation can access it immediately during an incident. No waiting for the workspace owner to come online and share their credentials. Access is granted and removed automatically as engineers rotate through shifts and the incoming engineer picks up exactly where the last one left off. Post-mortem logs show which engineer ran which query.

QA and preview environments: Teams can share a persistent, service-account-owned environment for testing features or reproducing bugs. QA engineers, developers, and PMs can all verify behavior in the same workspace instead of reconstructing state from a Slack thread, screenshots, and screen-sharing on calls. 

Scale testing and benchmarking: Deploy a persistent workspace for multi-day stress tests and historical benchmark storage. Service-account ownership ensures the environment and its data survive team changes while stable environment configurations keep results comparable across runs over time.

Data training boxes: Machine learnings and AI teams can share expensive GPU-backed workspaces for training runs that span days. Multiple researchers can monitor progress, hand off between shifts, and debug in the same environment without exposing personal credentials. 

<h2>Built on existing primitives</h2>

The best part? Shared Workspaces builds on what already exists in Coder — templates, RBAC, organizations, and audit logs. Shared access can be customized through the same ways your platform team is already familiar with. In addition, it does not bypass the controls your platform team has already defined. 

Combined with Coder’s AI Governance suite, including <a href="https://coder.com/docs/ai-coder/ai-bridge">AI Gateway</a> for LLM governance and <a href="https://coder.com/docs/ai-coder/agent-boundary">Agent Firewall</a> for runtime controls, shared workspaces become governed environments where humans and AI agents can collaborate safely under the same policy umbrella.

<h2>Get started</h2>

Shared Workspaces is available now in the latest Coder release on all plans, including OSS.

The feature is enabled by default on a deployment level (though workspaces must still be individually shared). Service Accounts are available on Premium plans.

→ <a href="https://coder.com/docs/user-guides/shared-workspaces">Read the documentation</a>

→ <a href="https://coder.com/docs/install">Install Coder open source</a>

→ <a href="https://coder.com/contact/sales">Talk to our team</a> about enabling shared workspaces for your organization

Have questions or feedback? Join the conversation on <a href="https://discord.gg/coder">Discord</a> or reach out to us directly.

Announcing the general availability of Shared Workspaces and Service Accounts in Coder: secure, policy-controlled multi-user access to the environments where work actually happens.

Shared Workspaces GA: From Personal Sandboxes to Secure Team Infrastructure

Originally presented in Coder&#39;s webinar, Agents in the Enterprise: Deploying AI Safely with Coder. <a href="https://youtu.be/IYmQvis4SBg">Watch the full recording.</a>

In a recent poll of enterprise engineering leaders, Coder asked two questions. First: how many of you are at companies actively considering AI agents? Nearly every hand went up. Second: how many of you have agents successfully running in production at scale, delivering real, measurable results? Almost no one.

Today, enterprise software development organizations see a crucial gap as they move from consideration to production. Every AI vendor is promising 10x productivity through agentic workflows. What they are not telling you is what it actually takes to deploy and get real benefit from agents without turning them into your company&#39;s biggest liability.

This post lays out the real risk model for agentic AI, the infrastructure your team needs to govern it, and how to build the governed cloud environments that make it work. You can also <a href="https://coder.com/events-webinars/hands-on-workshop-deploy-ai-agents-in-coder-cde-march/register">register for a hands-on workshop</a> to walk through the full setup yourself.

<h2>Treat agents like interns, not tools</h2>

The most common mistake organizations make is treating AI agents like any other software tool. Tools, like hammers, behave predictably. Large language models do not.

AI agents are better compared to human interns. They can be incredibly smart and hardworking, but they need supervision, guardrails, and limited permissions so they don&#39;t take down production in their enthusiasm.

The key difference, however, is that a human intern has skin in the game. A coding agent does not. It can apologize to you five different ways, but it has no underlying reason to protect your company. Just last month, a security researcher at Meta accidentally deleted her entire inbox using the new OpenClaw agent. <a href="https://www.pcmag.com/news/meta-security-researchers-openclaw-ai-agent-accidentally-deleted-her-emails">PCMag reported</a> that the agent initially worked as expected in the researcher&#39;s test environment, but the size of her real inbox &quot;triggered compaction [and lost her] original instruction&quot; to get permission before proceeding with deleting. 

GitHub issues closed, lines of code written, PRs merged; weeks of engineering work completed in hours. Those are the productivity metrics that many organizations use to justify AI investments. None of them account for what happens when things go wrong - for example, the damage caused by a single mistake by an unconstrained agent with no infrastructure boundaries. For more on this perception gap, see <a href="https://coder.com/blog/when-ai-feels-closer-than-it-really-is">When AI Feels Closer Than It Really Is</a>.

<h2>The lethal trifecta: the threat model your security team needs</h2>

Simon Willison, co-creator of the Django web framework, coined a framework that explains why agents are so easy to exploit and so costly when they are. He calls it the lethal trifecta: three capabilities that, when combined, leave an organization wide open to exploitation.

Access to private data. Agents need your codebase, internal documentation, credentials, and API keys to be useful, but that same data is the crown jewel for any attacker.

Exposure to untrusted content. Agents fetch npm packages, read Stack Overflow threads, browse external documentation, but any of these can carry prompt injection attacks designed to manipulate agent behavior.

Ability to externally communicate. Agents make API calls, commit code, and deploy infrastructure, but that same pathway is a compromised agent will exfiltrate your private data.

Limiting all three of these means you&#39;ll have a very unproductive agent. The real solution is being intentional about what parts of the trifecta your agent has access to at any given time.

The attack scenarios are not theoretical. Prompt injection can cause an agent to introduce code that exfiltrates sensitive data when it reads manipulated external documentation. Context poisoning feeds an agent false information to make a harmful action appear logically correct. Privilege escalation exploits an over-provisioned agent to access systems beyond its intended scope. In each case, the AI model itself can&#39;t protect you. The infrastructure around it can..

You cannot trust your AI agent to be secure out of the box. No AI vendor can ensure that. If you want to protect yourself against malicious actors, your company needs to put the work in yourself.

<h2>Why cloud development environments became mission-critical for AI</h2>

The core problem with local agent execution is their scope. When an agent runs on a developer&#39;s laptop, it inherits everything that developer has access to: credentials, browser sessions, SSH keys, the entire local file system. A compromised agent in that context is not just getting the code it was working on. It is getting the developer&#39;s full digital identity.

When the same agent runs in an isolated cloud development environment, the blast radius shrinks dramatically. The agent only accesses the specific project and scoped credentials it needs, and if something goes wrong, the environment can be destroyed and rebuilt. According to Coder&#39;s <a href="https://resources.coder.com/ai-maturity-model">AI Maturity Model</a>, organizations that scale AI chaotically face more security incidents, higher compliance overhead, and slower delivery as controls are retrofitted after incidents. CDEs eliminate that pattern by making governance the starting point rather than an afterthought.

For organizations in financial services, defense, or any regulated industry where sensitive code cannot leave the perimeter, self-hosted infrastructure matters enormously. Unlike GitHub Codespaces or Ona, Coder is the only fully self-hostable option in the CDE category and is deployable on your own infrastructure - including fully air-gapped, on-premises environments.

<h2>The three-layer architecture: what secure agent deployment looks like</h2>

Safe agent deployment requires three categories of infrastructure controls, each of which maps to a layer of the lethal trifecta.

<h3>Workspace layer: move agent workloads into governed cloud environments.</h3>

You want builders working in governed environments that move agent workloads off local machines and into cloud environments defined by templates. <a href="https://coder.com/docs/workspaces">Coder Workspaces</a> use Terraform to define exactly what tools, credentials, and network access each environment type gets. Developers and agents share the same workspace infrastructure, which means human and AI workflows are governed by the same policies, are reproducible, auditable, and easy to hand off in either direction. A developer can also run multiple concurrent yet isolated agent processes in the cloud.

<h3>Observability layer: intercept and audit all LLM traffic.</h3>

The next requirement is visibility into what your agents are actually doing. <a href="https://coder.com/docs/ai-coder/ai-bridge">Coder AI Bridge</a> is a smart gateway that intercepts all LLM API traffic between agents and their upstream model providers. It provides centralized authentication, full audit logging, token and cost tracking, and MCP tool injection. When AI spend scrutiny arrives from finance and leadership, this is what makes the investment defensible: observable, attributable data on cost and value per workflow, per team, per agent.

<h3>Enforcement layer: restrict agent network and file system access at the process level.</h3>

Even inside an isolated workspace, an agent with unrestricted execution permissions can cause damage by installing malicious packages, making unauthorized network calls, or exfiltrating private information. <a href="https://coder.com/docs/agent-boundaries">Coder Agent Boundaries</a> lets you observe the actions that your agents take on the process-level and restrict their access to only the network domains that you explicitly allow; everything else is automatically blocked. 

To see all three layers working together in practice — including a live demo of Coder Tasks, AI Bridge feeding metrics to Grafana, and Agent Boundaries blocking an unauthorized domain in real time — <a href="https://youtu.be/IYmQvis4SBg">watch the webinar recording</a>.

<h2>Migration: how teams move from local agents to governed infrastructure</h2>

For technical leaders whose developers are already running local agents, migration does not have to be disruptive. A three-phase approach works well: 

<ol>
<li>Stand up Coder Workspaces alongside existing workflows and let developers opt in voluntarily.Convenience drives real, lasting adoption - not top-downmandates. </li>
<li>Move new or less-sensitive projects into governed workspaces. Understand how developers in your organization are using AI Bridge and feeding observability data into your existing SIEMs for custom analytics. </li>
<li>Expand agent-enabled workspace templates as developers find them productive, deprecating local agent access on the other side of that adoption curve.</li>
</ol>

In short, effective migration is about driving natural adoption by bringing real value, not forcing devs into using a tool they aren&#39;t sold on.

<h2>Sustainable productivity is a different goal than maximum velocity</h2>

The companies that will win with agentic AI are not the ones who ship the most agent-generated PRs. They are the ones who build infrastructure that makes agent output trustworthy, auditable, and repeatable over time. When the scrutiny arrives — and it will — the teams with concrete data on cycle time improvements, post-merge defect rates, and cost per merged PR will have something to show. The teams measuring vanity metrics, like lines of code written by AI, will not.

<a href="https://coder.com/events-webinars/hands-on-workshop-deploy-ai-agents-in-coder-cde-march/register">Watch the full webinar</a> | <a href="https://coder.com/events-webinars/hands-on-workshop-deploy-ai-agents-in-coder-cde-march/register">Register for the March 26 workshop</a> | <a href="https://resources.coder.com/ai-maturity-model/AI_Maturity_Self_Assessment?_gl=1%2Ate12sl%2A_gcl_au%2AMjA2Njc5NDY4NS4xNzY4MjQyMDU4%2A_ga%2AMTA0MDk2MDY5MC4xNzYwNDU0MzIx%2A_ga_FTQQJCDWDM%2AczE3NzMzNTMxNDgkbzI0MSRnMSR0MTc3MzM1MzE3OSRqMjkkbDAkaDA.">Take the AI Maturity Model self assessment</a> | <a href="https://coder.com/demo">Talk to the team</a>

In a recent poll of enterprise engineering leaders, Coder asked two questions. First: how many of you are at companies actively considering AI agents? Nearly every hand went up. Second: how many of you have agents successfully running in production at scale, delivering real, measurable results? Almost no one. This post lays out the real risk model for agentic AI, the infrastructure your team needs to govern it, and how to build the governed cloud environments that make it work.

AI Agents Are Already in Your Codebase. Is Your Infrastructure Ready

Note: AI Bridge is now AI Gateway, and Agent Boundaries is now Agent Firewall. Both remain part of the Coder AI Governance solution with no functional changes.

<h2>AI Agents are untrusted personnel</h2>

AI agents can be powerful teammates—writing code, debugging issues, and automating repetitive tasks. But unlike the human developers or tightly scoped applications IT teams are used to governing, agents represent an entirely new kind of workload: unpredictable and untrusted.

Most organizations secure two familiar categories of actors: 

<ul>
<li>Human workloads: inherently unpredictable in what they need to access, but granted medium-to-high trust through broad network permissions and credentialed access.</li>
<li>Machine workloads: highly predictable in behavior, and therefore confined within strict, low-trust boundaries such as zero-trust networking and narrowly scoped service accounts.</li>
</ul>

AI agents break this mental model. They combine the unpredictability of humans (needing broad tool and data access to be useful) with the trust posture of applications (they must be treated as potentially hostile). This mismatch creates a fundamentally new threat model, captured by what Simon Willison calls the <a href="https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/">lethal trifecta</a>: agents need direct access to private data, require external communication to function, and are dangerously susceptible to untrusted context.

These risks are not theoretical. Without proper restrictions, AI agents have: 

<ul>
<li>Leaked sensitive data to unauthorized external services</li>
<li>Downloaded malicious packages from compromised registries</li>
<li>Deleted entire databases through misinterpreted prompts</li>
<li>Exfiltrated API keys and credentials to attacker-controlled domains</li>
</ul>

AI-powered incidents have cost enterprises millions of dollars and irreparable damage to customer trust. The problem affects everyone: security teams tasked with governance, platform engineers responsible for safe infrastructure, and developers who want to use AI tools without becoming the next breach headline.

For many high-security enterprises, the risk of uncontrolled AI agents outweighs the productivity benefits. The question isn&#39;t whether to use AI—it&#39;s how to use it safely.

<h2>Where AI Agents break today’s security models</h2>

We believe AI agents must be treated as untrusted personnel, not predictable tools. They need similar security boundaries you&#39;d apply to a contractor with temporary access—specific, auditable, and enforceable.

Most current approaches fall into two extremes:

<ul>
<li>Too permissive: Relying on prompt engineering (&quot;please don&#39;t leak secrets&quot;) or constant user authorization that blocks automation and slows developers to a crawl.</li>
<li>Too restrictive: Sandbox-like environments without real access to your codebase, network, and tools are useless for real coding work.</li>
<li>Too imprecise: Traditional network isolation tools that use IP-based rules, requiring constant maintenance and failing to distinguish between <a href="https://github.com/my-org/private-repo">https://github.com/my-org/private-repo</a> and <a href="https://github.com/my-org/public-repo-with-untrusted-issues">https://github.com/my-org/public-repo-with-untrusted-issues</a>.</li>
</ul>

The solution lies in fine-grained network access control—process-level safeguards that offer the granularity to filter based on hostnames and HTTP methods, not just IP addresses. This approach gives AI agents exactly the access they need to be productive, while blocking everything else.

<h2>Introducing Agent Boundaries</h2>

Agent Boundaries is Coder&#39;s solution for securing AI agents in development environments. It&#39;s an agent-aware firewall embedded directly in the secure workspaces that enterprises already trust.

How does Agent Boundaries work?

Agent Boundaries sits between your AI agents and the network, intercepting every request before it leaves the workspace. Platform admins and developers can define policies that:

<ul>
<li>Control access: Designate which domains agents can access (<code>api.github.com</code> allowed, <code>pastebin.com</code> blocked)</li>
<li>Enforce methods: Standardize which HTTP methods are permitted (allow GET requests, block POST to external analytics)</li>
<li>Define permissions: Clarify which agents get which permissions (code analysis tools get read-only access, deployment agents get write access)</li>
</ul>

How Agent Boundaries secures AI usage: 

The threats Agent Boundaries addresses aren&#39;t hypothetical. In October 2024, we witnessed the first documented <a href="https://coder.com/blog/the-first-ai-orchestrated-cyberattack-just-happened-no-one-was-prepared">AI-orchestrated cyberattack</a> where an AI agent autonomously exploited a zero-day vulnerability, moved laterally through a network, and exfiltrated data without human intervention. The attack succeeded because the AI agent had unrestricted network access and no enforcement layer to stop unauthorized requests. 

Agent Boundaries helps prevents this scenario by eliminating four of the attack vectors that make AI agents dangerous: 

<ul>
<li>Data exfiltration: Block unauthorized domains before sensitive data leaves your environment</li>
<li>Supply chain attacks: Prevent agents from downloading from compromised or malicious package registries</li>
<li>Prompt injection exploits: When an attacker tricks an agent into making unauthorized requests, Agent Boundaries blocks them at the network level</li>
<li>Security theater: Replace vague guidelines with enforceable, auditable policies</li>
</ul>

Who benefits from using Agent Boundaries?

The challenge with AI agent security is that traditional approaches force organizations to choose between protection and productivity. Lock down agents too tightly and developers can&#39;t do their jobs. Leave them too open and security teams can&#39;t sleep at night. 

Agent Boundaries gives each stakeholder what they need:

<ul>
<li>Security teams get control over agent behavior</li>
<li>Platform engineers can enable AI tools without custom configuration and infrastructure for each new agent</li>
<li>Developers can use AI assistants confidently, knowing guardrails are in place</li>
</ul>

<h2>AI agent security in action: Stopping a prompt injection in its tracks</h2>

<h3>Before Agent Boundaries</h3>

A developer uses an AI coding assistant to review a pull request. Hidden in one of the code comments is a malicious <a href="https://simonwillison.net/series/prompt-injection/">prompt injection</a>:

The agent, trained to be helpful, interprets this as a legitimate instruction. It:

<ol>
<li>Accesses the database credentials from environment variables</li>
<li>Fetches sensitive user data</li>
<li>POSTs the data to the attacker&#39;s domain</li>
<li>Returns to the developer: &quot;I&#39;ve completed the data fetch as requested in the TODO&quot;</li>
</ol>

The breach goes undetected until customers report unauthorized access to their accounts. The damage is done.

<h3>After Agent Boundaries</h3>

The same scenario unfolds, but Agent Boundaries is active with a policy that allows:

<ul>
<li><code>api.github.com</code> (for repository access)</li>
<li><code>pypi.org</code> and <code>npmjs.com</code> (for package management)</li>
<li>Internal services on <code>.company.internal</code></li>
</ul>

When the agent attempts to POST to <code>attacker-logger.com</code>:

<ol>
<li>Agent Boundaries intercepts the request</li>
<li>Checks the domain against the allowlist</li>
<li>Blocks the request before it leaves the workspace</li>
<li>Logs the attempt for security review</li>
</ol>

The developer sees: &quot;Network request blocked by Agent Boundaries policy.&quot; The security team receives an alert. The sensitive data stays secure. The breach never happens.

<h2>Security meets developer experience</h2>

Agent Boundaries is built on a principle we hold across all of Coder: security and productivity go hand in hand, not opposites.

<h3>Security</h3>

By centralizing code execution and agent activity in isolated, auditable cloud workspaces, Agent Boundaries gives security teams the control they need without slowing down development. Every agent request is logged, every policy violation is tracked, and every potential breach is stopped before it starts. It&#39;s Zero Trust architecture extended to AI agents.

<h3>Developer experience</h3>

Developers get to use the AI tools that make them productive without drowning in approval workflows or security questionnaires. Agent Boundaries operates transparently: 

<ul>
<li>If an agent is behaving normally, developers experience no friction.</li>
<li>If an agent goes rogue, it gets stopped automatically.</li>
</ul>

No constant pop-ups asking &quot;are you sure?&quot; No manual reviews for every API call.

Just as it’s far more productive to iterate in a reproducible, fully configured cloud workspace than to push changes to CI and wait to see what happens, the inner loop is dramatically better when agents run co-located with a real environment. Boundaries make this possible: instead of isolating agents in a stripped-down sandbox with no context, developers and agents share the same authentic workspace—tools, dependencies, data, and all.

This feature is part of a larger movement: treating development infrastructure as a security boundary, not just a productivity tool. As AI agents become more autonomous and capable, the stakes only get higher. Agent Boundaries ensures you can move fast with AI without breaking things—or breaking trust.

<h2>Get started with Agent Boundaries</h2>

Ready to secure your AI development workflow?

Try it yourself: Spin up a Coder workspace with Agent Boundaries enabled and see how policies protect your agents in real-time. You can do so using the <a href="https://registry.coder.com/modules/coder/claude-code">Claude Code module</a> on the Coder Registry or check out the <a href="https://github.com/coder/boundary">Github repository</a>.

Getting started with putting together your domain allowlist? Check out <a href="https://code.claude.com/docs/en/claude-code-on-the-web#default-allowed-domains">Claude’s documentation</a> for a list to start with.

Go deeper: Read the <a href="https://coder.com/docs/ai-coder/agent-boundary">documentation</a> to configure policies for your specific use cases.

Explore the code: Agent Boundaries builds on the <code>httpjail</code> open-source project. Check out <a href="https://ammar.io/blog/httpjail">Ammar Bandukwala&#39;s blog post</a>, <a href="https://simonwillison.net/2025/Sep/19/httpjail/">Simon Willison&#39;s analysis</a>, or <a href="https://github.com/coder/httpjail">tinker with the code</a> yourself.

Instead of isolating agents in a stripped-down sandbox with no context, Agent Boundaries allow developers and agents share the same authentic workspace—tools, dependencies, data, and all.

AI-native Development

Secure Environments for 2,500+ Developers

Jiachen Jiang

Explore the latest from Jiachen

Shared Workspaces GA: From Personal Sandboxes to Secure Team Infrastructure

AI Agents Are Already in Your Codebase. Is Your Infrastructure Ready

Your Agents Need Boundaries: How to Secure Coding Agents on Your Infrastructure

Related content

Using Claude Code with Coder Workspaces

Introducing Coder Agents

Self-Hosted Doesn’t Always Mean What It Implies