Ben Potter

VP of Product

<p>Claude Code is great, but we&#39;ve found that running it on local laptops and desktops introduces challenges for the enterprise. From a security perspective, the agent can access your local files and assume your identity. This poses a risk of the agent taking actions on your behalf, deleting important files, reading your passwords, or exposing data and services to the public internet. </p>

<p>For non-technical users who often benefit the most from Claude Code (product managers, QA engineers, data scientists), this risk is even higher. These folks are not familiar with best practices around zero-trust and sandboxing and tend to offload more risky work to agents.</p>

<p>The user experience of running Claude Code locally isn’t great either. Managing multiple Claude Code sessions and worktrees is still a power-user flow and agents are often blocked waiting for approval from users to run tools, when the agent’s productivity could be much higher if all tools were automatically approved. While --dangerously-skip-permissions is a workaround, the risks of this are obvious and should never be run on local machines with sensitive intellectual property, internet access, user permissions, and the ability to externally communicate. This is coined the lethal trifecta by AI researchers, which we’ve <a href="https://coder.com/blog/every-cursor-needs-a-coder">written about</a> extensively here at Coder.</p>

<p>Because of these security and productivity hurdles, we see many examples where IT and InfoSec teams block the use of agents like Claude Code on the desktop. When approved, adoption is limited to specific cohorts of software engineers and product managers who are able to manage the complexity, productivity, and security risks associated with running Claude Code locally.</p>


Using Claude Code with Coder

<h2>Enter Coder</h2>

<p>Coder runs developer environments on remote infrastructure managed by your enterprise platform teams. Instead of coding on local laptops, developers connect to their Coder instance running on their cloud or datacenter. This means that developers do not need to locally install any tools (including Claude Code) and the environment itself is secured and follows the enterprise&#39;s best practices for package management, network security, and configuration management.</p>

<p>What this means for your IT posture is that Claude Code instances are centrally managed with proper configuration, authentication, and firewall controls in place. Users are not manually handling API keys or configuring integrations with other services, tools, sandboxes, or MCP servers.</p>

<p>Users can self-serve environments that are pre-configured and pre-hardened for Claude Code, and can just as easily create a second or third environment to run many agents in parallel, all without having to manually approve tools or set up their own sandboxing and worktree workflows; capabilities that are otherwise only accessible to advanced power users.</p>

<h2>Reference architecture</h2>

<p>Coder can be deployed in a number of different ways, however one of the most common deployment pattern we see from our customers is with Claude Code.</p>

<p><img src="https://www.datocms-assets.com/19109/1778792937-claude-code-coder_8-2.png" alt=""></p>

<h3>Infrastructure</h3>

<p>Coder is self-hosted and can run on any cloud provider or on-premise datacenter. However, our recommended and most widely used stack is AWS with EKS (Elastic Kubernetes Service). By using Kubernetes, an organization can elastically scale to support thousands of workspaces for humans and agents. </p>

<p>With AWS, customers can run workspaces and the control plane on their own VPC, isolating ingress and egress from untrusted sources and connect to other internal services hosted on AWS such as CI/CD platforms, source control systems, and LLM inference with AWS Bedrock.</p>

<p>For organizations that do not use AWS with EKS, we have a healthy number (estimated 40%) of customers with different deployment paradigms such as Azure, VMware, EC2, OpenShift, etc. Coder can also run multi-cloud. AWS along with EKS is simply the most widely used infrastructure for the control plane and workspaces.</p>

<p><a href="https://coder.com/docs/install/kubernetes">See our guides for installing Coder on Kubernetes</a></p>

<h3>Scalability, database backups, and configuration management</h3>

<p>The Coder Control Plane (coderd) manages provisioning resources, networking, and even includes a bundled database. It is configured via environment variables, making IaC and versioned upgrades very easy with Terraform, GitOps, and Helm. </p>

<p>As organizations scale their deployments, there is often a desire to break out from a monolithic architecture to scalable components in order to support multiple regions, improved performance for workspace provisioning, and managed services (e.g., RDS) for the database and backups instead of an in-app-bundled database. Regulated environments may also wish to run Coder entirely <a href="https://coder.com/docs/install/airgap">air-gapped</a> and manage all of Coder’s configuration with the <a href="https://registry.terraform.io/providers/coder/coderd/latest/docs">coderd Terraform Provider</a> to avoid ClickOps entirely. Additionally, Coder can be run in high availability with multiple replicas in order to support larger scales.</p>

<p>See <a href="https://coder.com/docs/admin/infrastructure/validated-architectures">Coder’s Validated Architectures</a> for reference architectures on how to run Coder at various scales, up to 10,000 users. </p>

<h3>Coder Templates</h3>

<p>Templates are written by platform administrators and they inform the underlying infrastructure, dependencies, and tools for developer environments. Users pick a template from your curated list to get into a workspace.</p>

<p>It is most common for enterprises to create a “golden template” for use with Coder. This template contains the most commonly used programming languages (e.g., Java, Python), utilities (e.g., git, jq), and AI tooling (e.g., Claude Code). This template is meant to serve the main population of users: a developer looking to make a quick change, a product manager prototyping a new application.</p>

<p>For organizations with different technology stacks (or for those who want to lock down environments specific to AI), separate templates can be used that grant specific groups access to different sets of infrastructure and tooling. For example a “Claude Code” template could be used for those unfamiliar with other tools but just need to use Claude Code for prototyping. This template can deploy infrastructure onto a hardened VPC with limited network access, but with the proper MCP tools and organizational context. </p>

<p>Templates often point to an image in an image registry and also consume modules from the Coder Registry to include common integrations.</p>

<p>See our <a href="https://coder.com/docs/admin/templates">guides for template management</a>.</p>

<h3>AI governance</h3>

<p>Before users can begin running AI tooling (e.g., Claude Code) on workspaces, organizations must have a strong AI Governance posture, implemented via policy as code. This ensures that authentication is handled, only the proper models and providers are used, requests are properly labeled and logged, network requests are filtered, and cost controls are in place.</p>

<p>We recently detailed the risks that emerge <a href="https://coder.com/blog/the-hidden-risks-of-ai-in-engineering-and-how-to-get-ahead">when AI adoption outpaces governance</a>. The pattern is consistent: teams adopt AI coding agents organically, and the resulting inconsistency in tool setups, untracked usage, and lack of standardized guardrails keeps developers from being their best while introducing potential security threats.</p>

<p>While there are a number of AI Gateways, agent security settings, and sandboxing approaches on the market, many of our customers use <a href="https://coder.com/docs/ai-coder/ai-governance">Coder’s AI Governance Add-On</a> in order to cleanly manage everything from network sandboxing to identity management on the same platform, with clear audit trails throughout. From there, organizations <a href="https://coder.com/docs/ai-coder/ai-gateway/monitoring#structured-logging">integrate with their SIEM</a> to ingest logs for proper storage and analysis. </p>

<p>Learn about <a href="https://coder.com/docs/ai-coder/ai-governance">AI Governance</a> with Coder.</p>

<h3>AI coding agents</h3>

<p>Claude Code is the most popular terminal-based agent used with Coder and can be installed to any template by admins using the Coder Registry. From there, developers can enter a terminal (or an IDE, using the Claude Code extensions) and begin using Claude Code without any manual authentication, MCP config, or skill installation required. The module, combined with AI Governance, handles the installation and configuration of the agent. See how to <a href="https://registry.coder.com/modules/coder/claude-code">configure Claude Code with Coder</a> on the Coder Registry.</p>

<p>Any CLI/IDE-based agentic harness works with Coder and can be pre-installed into workspaces. Additionally, we’ve launched <a href="https://coder.com/blog/introducing-coder-agents">Coder Agents</a> in beta to provide a native, centralized approach for automation, background pipelines, and parallelized development.</p>

<h3>Client machines</h3>

<p>Unlike with local development, client machines do not need to contain any source code, programming languages, or coding agents. Users can simply connect via the browser and use the web IDEs and terminal. Software engineers and power users can connect over SSH or our IDE plugins for JetBrains and plugins.</p>

<p>Learn about <a href="https://coder.com/docs/user-guides/workspace-access">Coder’s supported IDEs</a>.</p>

<h2>How it works</h2>

<p>Users (Developers, Product Managers, QA engineers) log into their enterprise’s Coder instance and provision virtual environments (Workspaces) that include Claude Code as well as all of the necessary context, dependencies, repositories, and languages required for development. Additionally, all of the necessary governance and security controls are managed centrally in the template and logged via AI Governance.</p>

<h3>Creating a workspace</h3>

<p>When creating a workspace, users are prompted with templates and parameters they can select in order to get the proper tooling for the project. These options are all configured by the Coder admins.  </p>

<p><img src="https://www.datocms-assets.com/19109/1778536148-claude-code-coder_1.png" alt=""></p>

<h3>Connecting to Claude Code</h3>

<p>Users can decide whether they want to access Claude Code directly from the terminal or from an IDE like VS Code. Either way, Claude Code is pre-authenticated and configured with the necessary MCP servers and context:  </p>

<p><img src="https://www.datocms-assets.com/19109/1778536187-claude-code-coder_2.png" alt=""></p>

<p><img src="https://www.datocms-assets.com/19109/1778536206-claude-code-coder_3.png" alt=""></p>

<p><img src="https://www.datocms-assets.com/19109/1778536236-claude-code-coder_4.png" alt=""></p>

<h3>Template configuration (for admins)</h3>

<p>The Claude Code module can be imported into any template through our module in the Coder Registry. Enterprises can mirror this to their private source control instances or include the module directly in their templates</p>

<p><img src="https://www.datocms-assets.com/19109/1778536271-claude-code-coder_5.png" alt="">
<img src="https://www.datocms-assets.com/19109/1778536279-claude-code-coder_6.png" alt=""></p>

<h3>AI governance (for admins)</h3>

<p>All Claude sessions are fully audited and can be viewed by administrators and auditors in the Coder Sessions UI. More importantly, these <a href="https://coder.com/docs/ai-coder/ai-gateway/monitoring#structured-logging">logs can be ingested via SIEM</a> for proper storage and analysis.</p>

<p><img src="https://www.datocms-assets.com/19109/1778536310-claude-code-coder_7.png" alt=""></p>

<h2>Get started</h2>

<p>You can learn how to <a href="https://coder.com/docs/install">install Coder Community Edition</a> (or a <a href="https://coder.com/trial">premium trial</a>) and have Claude Code running in a governed workspace in minutes. For a deeper dive into how Coder fits your infrastructure, reach out to our technical sales team, email <a href="mailto:sales@coder.com">sales@coder.com</a>.</p>


Run Claude Code on governed cloud infrastructure instead of local laptops. Learn how Coder secures AI coding agents with centralized controls and audit trails.

Using Claude Code with Coder Workspaces

<p>Most organizations we work with at Coder, from Fortune 500 companies to <a href="https://coder.com/solutions/government">government agencies</a> to high-tech SaaS providers, heavily invest in bringing AI into their software development lifecycles. While every team has different approaches and experiences, we have identified common patterns (and anti-patterns) around AI adoption.</p>

<p>This post is meant to start a conversation, not to offer a comprehensive market analysis or a step-by-step playbook. We plan to create additional materials and continue to share the best-in-class reference materials. In the meantime, we want to hear from you! Your feedback, experiences, and comments help us build better products and content around this topic.</p>


<h2>Assistants like GitHub Copilot didn’t meet expectations</h2>

<p>Many developers’ first introduction to AI in the enterprise was <a href="https://github.com/features/copilot">GitHub Copilot</a> (or a similar code assistant), with autocomplete-like features in the IDE. Enterprises, at an above-average pace, formed teams to procure and roll out AI assistants, followed by custom dashboards, surveys, and tooling in order to properly measure ROI and adoption metrics.</p>

<p>The results? Underwhelming, given the investment.</p>

<p>The customers and analysts I speak with will cite roughly a 10% productivity gain. Autocomplete suggestions were often reported as distracting or inapplicable to the codebase or language at hand. </p>

<p>Despite the disappointment from this initial top-down push, developers are not rejecting AI. In fact, many organizations have reported a bottom-up push to pilot IDEs like <a href="https://enterprise.cursor.com/">Cursor</a> or CLI agents like <a href="https://www.anthropic.com/claude-code">Claude Code</a>. Over the past two years, tools like GitHub Copilot have become the status quo. Now, developers are asking: what’s next?</p>

<p><strong>Lesson learned:</strong> AI needs to be native to the developer experience, not bolted on.</p>


<h2>Dedicated teams are <del>forming</del> rebranding</h2>

<p>Enterprises continue to make a significant investment in AI adoption, particularly around software development. Because of this, many Developer Productivity (DevProd) and Developer Experience (DevEx) teams are rebranding or splitting to include “AI” in their name. These teams are responsible for safe, efficient and impactful introduction of AI tools. One of our partners, <a href="https://getdx.com/blog/">DX</a>, spends a lot of time researching, <a href="https://getdx.com/blog/measuring-ai-in-software-teams-trends/">writing</a>, and <a href="https://getdx.com/podcast/metrs-ai-findings/">podcasting</a> about this exact topic.</p>

<p>At most organizations, this cannot just be attributed to a top-down mandate around AI adoption. Most developers enjoy using AI in their workflows, proven by the widespread adoption of IDEs like Cursor and <a href="https://docs.windsurf.com/getstarted/overview">Windsurf</a>. </p>

<p>At Coder, we have felt this too. Over the past two years, our conversations have shifted from provisioning standard tooling to AI assistants like Copilot and IDEs like Cursor. Now, many teams are looking for additional ways to introduce AI into the software development lifecycle beyond the IDE. Enterprises look to leverage remote coding agents for pull request reviews, code discovery and onboarding, prototyping, small bug fixes, documentation, on-call issue triage, and debugging.</p>

<p><strong>Lesson learned:</strong> The developer experience (DevEx) profession now encompasses AI tooling.</p>


<h2>Leading enterprises prioritize AI <del>efficiency</del> proficiency</h2>

<p>Despite all the hype, AI is still in its infancy and should be approached with a “crawl, walk, run” approach. We’ve seen many strategies that jump straight to “run” fail, despite being tied to clear business outcomes. Dedicated task forces around running “teams of AI agents for tech debt remediation” tend to miss the point when developers across the org lack day-to-day AI proficiency in their workflows.</p>

<p>On the other hand, we see organizations with a strong learning and experimentation culture seeing great results. By introducing new tools regularly and sharing findings widely, they build organizational AI literacy before attempting larger transformations.</p>

<p><strong>Lesson learned:</strong> AI success comes from tightly scoped use cases with broadly socialized wins.</p>


<h2>Enterprise developers rarely “vibe code”, but their peers do</h2>

<p>Business analysts, QA engineers, technical managers, security engineers, UX designers, support engineers, and other coding-adjacent roles are generating massive amounts of code for prototyping, writing tests, and accomplishing small tasks between meetings. </p>

<p>On the other hand, many enterprise software engineers we speak with remain skeptical that today’s autonomous coding agents (or “vibe coding”) can be used to augment real work in day-to-day software engineering workflows. Software engineers often cite that agents need to be heavily supervised, and therefore are unproductive for long periods of time in the background. Additionally, many report that agents do not work without extremely clear requirements or simply write code that is not well-suited for production systems.</p>

<p>That said, most agree the potential is clear: as models improve and gain access to private, enterprise-specific context, AI will become more effective for everyday tasks. The real shift will come when it is deliberately integrated into cross-functional workflows, such as helping QA generate targeted tests for developers, enabling security teams to prepare actionable fixes, and allowing product managers to deliver code-ready requirements. In these contexts, AI’s contributions become clearer, more relevant, and more impactful.</p>

<p><strong>Lesson learned:</strong> Vibe coding isn’t for software engineers, it’s for citizen developers - and useful.</p>


<h2>IT leaders are optimistic for compliance “change agents”</h2>

<p>Interestingly, many leadership roles in IT, security, and architecture are often the most optimistic about the benefits of coding agents to improve code quality, tests, documentation, and security practices in the enterprise. We often see agents being discussed alongside the context of promoting best practices or modernization. </p>

<p>This is likely due to many past failed attempts to introduce DevOps and platform engineering efforts in the enterprise, combined by the challenging dependency on software engineers to patch vulnerabilities, document their services, and other “chores.” Instead of manually bugging developers and PMs to prioritize chores in a sprint, IT leaders are hopeful that fleets of AI agents can help “nudge” projects into better compliance.</p>

<p><strong>Lesson learned:</strong> Coding agents can happily do the grunt work that detracts from a good DevEx.</p>


<h2>DevEx and security concerns hold back AI coding agents</h2>

<p>Most teams we speak with are still looking for advice on how to adopt and secure autonomous coding agents, primarily due to unclear developer experience and security concerns. </p>

<p>On the developer experience side, organizations are hesitant to introduce coding agents without clear and practical use cases within their software development lifecycle. For example, many coding agents struggle with monorepos or cannot fully understand requirements for most issues. Developers need a clear understanding of the capabilities of AI agents and when and how to use them. Without clear expectations, environments, and third-party integrations, many AI agents end up feeling impractical for day-to-day use beyond a simple demo. </p>

<p>Security and governance are another concern, especially with agents running on remote servers. Topics such as permissions/identity, environment sandboxing, configuring network firewalls, token cost controls, and MCP security are top-of-mind for security teams. The two most common risks enterprises identify are:</p>

<ol>
<li><strong>Data leaks:</strong> Source code or intellectual property is accidentally leaked to the public by an autonomous AI agent </li>
<li><strong>Destruction of property:</strong> Databases, repos, or additional proprietary data are accidentally deleted by an autonomous AI agent</li>
</ol>

<p>Organizations that are successfully operationalizing agents, such as <a href="https://coder.com/blog/inside-anthropics-ai-first-development">Anthropic</a>, are evaluating these topics from first principles. Other enterprises are waiting for vendors such as Devin and Coder (or the agents themselves) to improve their security postures.</p>

<p><strong>Lesson learned:</strong> Getting agents working in the enterprise is mostly about security and governance, not AI maturity.<a href="https://"></a></p>


<h2>Enterprise reference architectures are emerging</h2>

<p>Many enterprises we speak to have already selected an enterprise-grade LLM provider (e.g., <a href="https://docs.aws.amazon.com/bedrock/index.html">AWS Bedrock</a>) and procured several AI tools such as GitHub Copilot, Cursor, and <a href="https://www.coderabbit.ai/">CodeRabbit</a> with established policies for risk management and compliance.</p>

<p>In the coding agent landscape, thought leaders such as Simon Willison write about security models (e.g., <a href="https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/">the lethal trifecta for AI agents</a>). Companies like <a href="https://platform.openai.com/docs/codex/overview">ChatGPT Codex</a>, <a href="https://jules.google">Google Jules</a>, and <a href="https://docs.anthropic.com/en/docs/claude-code/security">Anthopic</a> are documenting best practices for securing their respective agents, both locally and for remote environments.</p>

<p>While AI is nowhere near ubiquitous in the enterprise software development lifecycle, DevEx teams and vendors alike are rushing to fill functional gaps around developer experience, security, identity management, sandboxing, and access to private data/tools. </p>

<p>For our part, Coder provides teams a single place to set up and manage development environments with <a href="https://coder.com/docs/admin/templates/template-permissions">clear access controls</a>, <a href="https://coder.com/docs/ai-coder/security#set-up-agent-boundaries-premium">isolated workspaces</a>, and <a href="https://coder.com/docs/admin/networking">secure connections</a> to internal code and <a href="https://registry.coder.com/">any popular agent</a>. It works with <a href="https://coder.com/docs/admin/users">existing logins</a>, applies company security rules, and helps developers work in a consistent, reliable setup.</p>

<p><strong>Lesson learned:</strong> Successful enterprises design purposeful AI development infrastructure.</p>


<h2>Next steps</h2>

<p>Check out our <a href="https://coder.com/blog/inside-anthropics-ai-first-development">recent webinar with the DevEx team at Anthropic</a> where we discuss how aggressive AI adoption and their security-by-design approach is shaping the next phase of enterprise coding agents. We discuss real-world patterns like multi-agent workflows, “docs to demos,” and embedding AI across the development lifecycle from prototyping to on-call playbooks for production.</p>


How Anthropic Engineers Are Adapting to AI Coding Agents

AI tools are reshaping how enterprise development teams work, but success requires more than just deploying the latest assistants. Drawing from our work with Fortune 500 companies and other enterprise customers, we've identified key lessons around what works when adopting AI in enterprise software development.

Inside AI Adoption: Lessons from Enterprise Software Development Teams

<p>The future of software development isn&#39;t coming. It&#39;s here. And it&#39;s running in terminals, spinning up in cloud development environments, and transforming how the world&#39;s most advanced AI companies build code.</p>

<p>On July 30th, we hosted a fireside chat with leaders from the Anthropic product and developer experience team building <a href="https://www.anthropic.com/claude-code">Claude Code</a> to explore how AI coding agents are reshaping development workflows. The conversation revealed something remarkable: we&#39;re witnessing the birth of AI-native software development, where agents don&#39;t just assist developers but fundamentally change what developer experience means.</p>


<h2>The Philosophy: Aggressive AI Adoption</h2>

<p>Anthropic&#39;s approach to AI development is refreshingly direct. &quot;We pretty much encourage people to use AI as aggressively as possible,&quot; explained Jacqueline Lee, Member of Technical Staff at <a href="https://www.anthropic.com/">Anthropic</a>. &quot;Because through giving AI agents really hard tasks, that&#39;s the only way to actually push the boundary of what they&#39;re capable of.&quot;</p>

<blockquote>
<p>Through giving AI agents really hard tasks, that&#39;s the only way to actually push the boundary of what they&#39;re capable of.</p>
</blockquote>

<p>This philosophy permeates everything they build. But it comes with an important caveat from Cat Wu, Product Manager for Claude Code: &quot;If I write sloppy code, it will definitely produce me more sloppy code. It&#39;s kind of like an amplifier.&quot; </p>

<p>The lesson? AI agents magnify your practices—both good and bad.</p>


<h2>Claude Code: Terminal-first, developer-ready</h2>

<p>Cat Wu cut straight to the core of their design philosophy: </p>

<blockquote>
<p>Claude Code is an agent coding tool that, for now, lives in the terminal. The reason that we designed it this way is to make it really extensible, customizable, hackable.</p>
</blockquote>

<p>This isn&#39;t about replacing your IDE. It&#39;s about meeting developers where they are. &quot;Because it runs in a terminal, it&#39;s compatible with most dev setups,&quot; Cat explained. &quot;You can run it within the terminal section of your IDE provider or your IDE of choice.&quot;</p>

<p>The terminal-first approach solves a critical adoption challenge. Every developer uses different tools, different workflows, different environments. But as Cat noted: &quot;The one thing that we found in common with everyone is that almost everyone uses a terminal.&quot;</p>


<h2>Real-world impact: From onboarding to on-call</h2>

<p>At Anthropic, Claude Code itself has become essential infrastructure. &quot;Most technical Anthropic employees were already using Claude Code&quot; before its external launch, Cat noted. The use cases span the entire development lifecycle:</p>

<h3>Developer onboarding revolution</h3>

<p>&quot;It&#39;s the fastest way for you to get up to speed on a new code base,&quot; Wu said. &quot;It also means that new hires can get work done whenever they want to work and not just when their mentor is online.&quot;</p>

<blockquote>
<p>It&#39;s the fastest way for you to get up to speed on a new code base. It also means that new hires can get work done whenever they want to work and not just when their mentor is online</p>
</blockquote>

<h3>On-call transformation</h3>

<p>Jacqueline described their on-call workflow: &quot;If you have an on-call playbook, you can just put that into your slash command, like an on-call slash command. Share context with these are the tools that... and then give Claude Code access to the tools that are mentioned in the on-call playbook.&quot;</p>

<h3>From docs to demos</h3>

<p>Perhaps most telling is the shift Cat described: &quot;We&#39;ve been seeing this shift both within Anthropic and with a lot of the customers we talk to. We call it docs to demos.&quot; With Claude Code, &quot;it&#39;s much easier to get a working prototype quickly. It might not be mergeable in a one-shot way, but at least you can build something that works, that you can interact with.&quot;</p>


<h2>Advanced workflows: Multi-Claude and beyond</h2>

<p>The most sophisticated users aren&#39;t running one instance of Claude Code. They&#39;re running multiple. &quot;A lot of people love to run multiple Claudes at the same time,&quot; Cat explained. &quot;More common is 2 to 4. Three is my sweet spot.&quot;</p>

<blockquote>
<p>A lot of people love to run multiple Claudes at the same time. More common is 2 to 4. </p>
</blockquote>

<p>Jacqueline takes this further: &quot;I do multi-Claude, but I try to not babysit them as much as possible... sometimes I would trigger a Claude through Slack. It will go off and which means that there&#39;s no steering involved.&quot;</p>

<p>The Claude Code SDK opens even more possibilities. Cat outlined three main categories:</p>

<ol>
<li>Creating GUI wrappers for less terminal-comfortable users</li>
<li>Building role-specific agents (security engineers, SREs, on-call assistants)</li>
<li>Developing general agents for legal, finance, or user-facing features</li>
</ol>


<h2>Enterprise Adoption Strategy: Security by Design</h2>

<p>For highly regulated enterprises, Jacqueline outlined a critical security framework based on three properties:</p>

<ol>
<li>Access to private/proprietary data</li>
<li>Internet access</li>
<li>Access to untrusted data</li>
</ol>

<p>&quot;Never have all three in your environment,&quot; she emphasized, to prevent data exfiltration and infrastructure destruction.</p>

<p>Practical security measures include:</p>

<ul>
<li>&quot;Remove credentials, inject agent identities&quot; with limited infrastructure access</li>
<li>Environment isolation over tool restrictions: &quot;Hardening the environment is a better approach&quot;</li>
<li>Allowlist domains instead of full internet access</li>
<li>MCP servers for controlled access to internal tools</li>
</ul>

<p>Security isn&#39;t an afterthought—it&#39;s foundational. &quot;Out of the box, Claude Code only has read-only permissions,&quot; Cat emphasized. &quot;Any additional edits require approval from a human, so that includes editing files, running tests, executing any bash commands.&quot;</p>

<p>But there&#39;s a balance to strike. As Cat warned: &quot;Developers are very sensitive to spam, because once you spam them, they&#39;re like, okay. Turn this whole thing off. This is terrible.&quot;</p>

<blockquote>
<p>Developers are very sensitive to spam, because once you spam them, they&#39;re like, okay. Turn this whole thing off. This is terrible.</p>
</blockquote>

<p>For enterprise adoption, Anthropic built first-class support for AWS Bedrock and Google Cloud Vertex AI from day one. &quot;A lot of those folks really strongly prefer to use Bedrock or Vertex to access Anthropic APIs,&quot; Cat noted.</p>


<h2>Coder: The platform for AI-native development</h2>

<p>Anthropic&#39;s integration with Coder emerged as a key theme. Jacqueline highlighted how <a href="https://coder.com/">Coder</a> enables their <a href="https://coder.com/">remote development strategy</a>: &quot;I have been focusing on remote development, majorly leveraging Coder as the control plane and configure environments for people to have one-click everything setting up all at once, ready to go kind of experience.&quot;</p>

<p>More recently, she&#39;s &quot;been pivoting more into the agency environments, configuring environments for agents to run.&quot;</p>

<p>Cat demonstrated how Coder transforms Claude Code from a local tool into enterprise infrastructure: &quot;It really lets you start to use these agents in a composable way. Meaning it&#39;s running entirely in the background. I could close my laptop and the agent continues to work... we actually have three agents all running in the background, working on various tasks.&quot;</p>

<blockquote>
<p>I could close my laptop and the agent continues to work... we actually have three agents all running in the background, working on various tasks.</p>
</blockquote>

<p>For enterprises exploring multi-Claude workflows, the benefits are clear. As one participant noted, &quot;That&#39;s one of the top use cases, as you can have a bunch of Claude instances running. They&#39;re remote. They&#39;re sandboxed. And you don&#39;t have to worry about disrupting your local branch or repo or any type of security risk.&quot;</p>


<h2>Looking ahead: The AI-native future of software development</h2>

<p>The roadmap Cat outlined points toward a future where AI agents are embedded throughout the development experience: &quot;We would love for Claude Code to be available on more surfaces that engineers are on... there&#39;s so many more places that you do work day to day.&quot;</p>

<p>The vision extends beyond code: &quot;Claude Code is most successful when it has access to all the tools that a developer has. So think being able to understand the discussions on Slack and being able to pull in the PRD, product review docs and engineering specs, Jira tickets, customer support tickets.&quot;</p>

<p>Cat&#39;s forward-looking advice for enterprises: </p>

<blockquote>
<p>Set up your remote infrastructure so that when the models are ready, you already have that set up to go, and your engineers can kick off many Claude Code runs at the same time on different tasks.</p>
</blockquote>

<p>We&#39;re not just adding AI to existing workflows. We&#39;re witnessing the emergence of AI-native development, where agents and humans collaborate like colleagues. As Kyle put it: &quot;I am very bullish on outsourcing my intelligence. I have been for a long time now. It&#39;s great.&quot;</p>

<p>The companies that understand this shift, that implement the infrastructure to support it, and that empower their developers to experiment aggressively will define the next era of software development.</p>

<p>Ready to explore AI-native development? Learn how Coder provides the <a href="https://coder.com/solutions">secure, scalable platform</a> for running Claude Code and other AI agents at enterprise scale.</p>


On July 30th, we hosted a fireside chat with leaders from Anthropic's product and developer experience team who is building Claude Code to explore how AI coding agents are reshaping development workflows. Here are the highlights.

How AI Agents Are Redefining Developer Workflows at Anthropic

<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>AI coding agents such as Claude Code, Amazon Q, and Aider are exciting to demo, but can be incredibly challenging to operationalize in the real world. For enterprises, security reviews, cost analysis, and governance are table stakes. Agent-assisted programming introduces an entirely new set of challenges that most organizations aren’t prepared for yet.</p>

<p>In this post, we’ll explore why operationalizing coding agents is hard, what risks you need to manage, and how <a href="https://coder.com/docs/ai-coder">Coder Tasks</a> lets you safely and effectively deploy AI agents on your own infrastructure.</p>


<h2>The hidden risks of running agents on local machines</h2>

<p>Most developers we speak to remain skeptical that agents are capable of understanding and working within their codebase. And running agents locally? It’s fine for exploring AI-assisted coding, but not a viable long-term solution.</p>

<p>It doesn’t scale and, worse, it compromises either security or productivity:</p>

<ul>
<li>Granting agents free rein on your laptop exposes your emails, files, source code, and more, <strong>increasing your risk profile.</strong></li>
<li>Constant prompt engineering or approvals for every request <strong>slows work down</strong> and <strong>invites human error</strong>.</li>
</ul>


<h2>Coder Tasks: Bringing coding agents into secure, managed workspaces</h2>

<p>Coder Tasks lets enterprises and hobbyists alike self-host coding agents in practical, secure environments <strong>on your existing infrastructure.</strong></p>

<p>With Coder Tasks, developer teams can use best-in-class agents as true sidekicks: answering questions, fixing bugs, and reviewing their code within their IDEs or through the Coder dashboard.</p>

<p>Whether you prefer in-IDE agents (e.g., Copilot, Windsurf, and Cursor) or headless agents (e.g., Claude Code, Amazon Q, Aider, and Goose), Coder has you covered.</p>

<p>Soon, you’ll be able to work with agents in Slack, GitHub, or via Coder’s CLI and MCP servers.</p>


Screenshot of running tasks asynchronously.

<h2>Confidently provision agents with Templates and Boundaries</h2>

<p>Administrators manage Coder Templates, which are the blueprints for provisioning coding agents, powered via Terraform.</p>

<p>These templates define:</p>

<ul>
<li>The agents your teams use</li>
<li>Boundaries for process isolation</li>
<li>Integration points for MCP tools</li>
<li>Connections to on-prem LLMs, enterprise AI subscriptions, API routers, or cloud LLM providers (e.g., AWS Bedrock)</li>
</ul>


<p>Templates ensure <strong>coding agents operate with the right permissions, in the right places, every time.</strong></p>


<h2>Developer AI adoption is surging in the enterprise</h2>

<p>Over the past two years, AI-assisted development has emerged as a <strong>leading priority</strong> for the enterprise developer productivity teams we work with. This mirrors a broader trend across industries.</p>

<blockquote>
<p>78% of companies reported using AI in at least one function in 2024, up from 55% in 2023. </p>
</blockquote>

<p>— <a href="https://aiindex.stanford.edu/report/">2025 Stanford AI Index Report</a> </p>

<p>Like any new technology, there is a maturity curve. However, almost all developer productivity organizations have introduced lightweight AI assistants to their developers. Among our customers, we are seeing a mix of technology, government, and financial services organizations leading the charge with adopting coding agents.</p>

<p>Claude Code’s creators, Anthropic, have seen strong internal adoption of the agent on remote environments. We’ll be sharing more on this topic soon–stay tuned!</p>


<h2>5 use cases where coding agents shine today</h2>

<p>To help you cut through the hype, here are five practical, low-barrier use cases for coding agents that teams can operationalize right now:</p>

<ul>
<li><strong>Answering questions about the codebase</strong> (e.g., explaining the tech stack or an error) </li>
<li><strong>Prototyping and demo applications</strong> (often referred to as “vibe coding” for quick ideas) </li>
<li><strong>Documentation reviews</strong> (e.g., auditing documentation for correctness) </li>
<li><strong>Visual updates</strong> (e.g., spacing tweaks, text copy changes, etc.) </li>
<li><strong>Experimentation</strong> (e.g., testing what agents can do in your environment) </li>
</ul>


<h2>Secure coding agents without sacrificing their usefulness</h2>

<p>Running coding agents on remote servers already reduces risk by isolating them from your emails, personal disk files, applications, and other information unrelated to the task at hand.</p>

<p>However, it is still important to consider other ways to isolate your agent from doing things you don&#39;t want them to, while ensuring that it still has the agency and information it needs to complete tasks.</p>

<p>Some steps you can take to safeguard your environments include:</p>

<ul>
<li>Issuing <strong>read-only API tokens</strong> for systems providing context for the task at hand like GitHub, Jira, and Backstage</li>
<li>Enforcing <strong>firewalls</strong> so agents can only connect through your corporate proxy or API gateway, blocking direct access to external servers</li>
<li>Audit tool calls and consider <strong>AI proxies</strong> or <strong>self-hosted LLMs</strong> to prevent leaking secrets or source code to LLMs</li>
<li>Set <strong>resource quotas</strong> to ensure agents do not spend too much in CPU, GPU, or tokens on a given task</li>
</ul>


<h2>The future: Always-on coding agent assistants</h2>

<p>As LLMs and agents improve, they’ll:</p>

<ul>
<li>Run longer in the background <strong>without interruption</strong></li>
<li><strong>Debug</strong> their own work</li>
<li>Gather <strong>richer context</strong> beyond the initial prompt from previous solutions, architectural patterns, related PRs, or product requirements (via MCP)</li>
<li><strong>Communicate seamlessly</strong> with the user via tried-and-true channels (e.g., GitHub, Slack, Jira)</li>
</ul>

<p>We believe organizations that invest in agent-friendly, automated environments today will be the ones that thrive as agents pick up more of the background work–even while you sleep!</p>


Coder Tasks Demo | Running AI Coding Agents at Enterprise Scale

<h2>Get started with Coder Tasks today</h2>

<p>Coder Tasks is available in our Open Source and Premium plans (v2.25 and above). All you need is access to an LLM provider (e.g., Anthropic, OpenAI, Ollama, Amazon Bedrock) and a compatible template.</p>

<p>👉 <a href="https://coder.com/docs/tutorials/quickstart#whats-next"><strong>Quickstart</strong>: Install Coder and try Coder Tasks</a></p>

<p>👉 <a href="https://coder.com/docs/ai-coder"><strong>Tutorial</strong>: Add a Tasks template to your Coder deployment</a></p>


Coder Tasks lets enterprises and hobbyists alike self-host coding agents in practical, secure environments on your existing infrastructure.

Day 1: Run AI Coding Agents on Your Own Infrastructure with Coder Tasks

<p>Today, organizations of all sizes are building their internal developer platforms on top of Backstage.io.</p>

<p>Why? Spotify, the original developers of Backstage.io explain the problem well:</p>

<blockquote>
<p><em>Instead of building and testing code, teams were spending more time looking for the right information just to get started. “Where’s the API for that service we’re all supposed to be using?” “What version of that framework is everyone on?” “This service isn’t responding, who owns it?” “I can’t find documentation for anything!”</em></p>
</blockquote>

<p>However, Backstage can do much more than centralize metadata across different services. Developer productivity teams are building different Backstage plugins, pages, and integrations to save developers time and increase the collective knowledge of their engineering teams. In fact, Expedia reported that <a href="https://backstage.io/blog/2023/08/17/expedia-proof-of-value-metrics-2/">4000 developers</a> spend 20+ minutes a day in Backstage. </p>


Source: Backstage.io documentation

<h1>Developer experience starts from the IDE</h1>

<p>Our mission at Coder is to keep developers in flow. Because developers spend the majority of their time in their IDE, we started there. Developers at large enterprises often suffer from poor development (IDE) environments. Here are some common traits:</p>

<ul>
<li><strong>Onboarding</strong>: Developers take weeks to onboard to new projects, often due to manual steps, outdated wikis, or missing developer tools on their machine</li>
<li><strong>Lag/latency</strong>: Developers must use a VPN or Virtual Desktop to connect, introducing high typing latency or slow download speeds</li>
<li><strong>Inconsistency</strong>: Software is difficult to install on Windows/macOS machines. These disparate environments and introduce &quot;it works on my machine&quot; problems when comparing to Linux-based QA or production environments </li>
<li><strong>Partial environments</strong>: Dependencies (databases, services) are mocked to reduce load on the laptop and reduce local troubleshooting. However, this requires waiting for test or staging environments to fully test your code, resulting in a slow development loop.</li>
<li><strong>Slow builds and tests</strong>: Developers spend hours per day waiting on slow builds, IDE indexing, or git clones </li>
</ul>

<p>Coder is an open-source, self-hosted platform for cloud development environments (CDEs), which allows developers to set up a secure remote environment in minutes, not days. Here’s how a developer can start contributing to a project with Coder, starting from Backstage:</p>


<p><a href="https://github.com/coder/backstage-plugins/tree/main/plugins/backstage-plugin-coder">Check out the Coder Backstage plugin on GitHub</a></p>

<p>Don&#39;t use Coder? The <a href="https://github.com/coder/backstage-plugins/tree/main?tab=readme-ov-file#backstage-plugins">Dev Containers plugin</a> can detect repos with devcontainer.json and give developers a link set up the repo in local VS Code. Use it to prove the the one-click onboarding experience using local compute. </p>

<h2>How it works</h2>

<p>The plugin matches Backstage catalog items with a compatible template and sends any parameters (such as git repository) to Coder. Templates can use the <a href="https://coder.com/docs/v2/latest/templates/devcontainers">Dev Containers</a> specification or a common base image can be used to ensure the proper tools for the projects are pre-installed in the workspace.</p>

<h2>Our methodology</h2>

<p>Like Backstage, we built Coder to allow developers to continue using the tools they love, while also providing sensible defaults. After all, developers take a <a href="https://www.youtube.com/playlist?list=PL6zLuuRVa1_iDEP4EicZ8972RgyccCRGF&themeRefresh=1">lot of pride</a> in configuring and optimizing their IDEs. Coder relies on open standards to give developers the environments they need:</p>

<ul>
<li><p>IDEs: Any editor with SSH support (VS Code, JetBrains, vim, emacs) or web access (Jupyter, RStudio) is supported</p></li>
<li><p>Infrastructure: Workspaces are defined with Infrastructure as Code (Terraform) and can be VMs or Kubernetes pods.</p></li>
<li><p>Dependencies: Define a project’s dependencies (Python 3.11, Java 3.8, Podman 2.1) with a <a href="https://containers.dev">devcontainer.json</a> in the git repository</p></li>
</ul>

<h2>Next steps</h2>

<p>You can check out the <a href="https://github.com/coder/backstage-plugins/tree/main/plugins/backstage-plugin-coder">Coder Backstage plugin on GitHub</a>. Want a demo? <a href="https://coder.com/demo">Contact us</a>.</p>

<p><em>Related Content:</em></p>

<p><em>Register for our upcoming webinar <a href="https://coder.com/webinars/backstage-coder-the-full-software-development-lifecycle/register">Backstage + Coder: The Full Software Development Lifecycle</a>, March 27 at 10 am PST</em></p>


Learn about our plugin for Backstage.io, a framework for building developer portals

Introducing the Coder Backstage Plugin

<p>Cloud development environments (CDE) are popular among students, hobbyists, and small- to medium-sized businesses. They don’t have the time or expertise to set up their development environments before they can even edit the first file. So they turn to platforms like <a href="https://replit.com/">Replit</a> and <a href="https://stackblitz.com/">StackBlitz</a> to start coding quickly, typically in minutes, often on modest hardware. These platforms leverage the cloud to give these developers turnkey configurations, automatically-provisioned compute and storage, easy collaboration, and other features.</p>

<p>Enterprise development organizations are realizing that they can also gain from a platform to manage their CDEs. Industry analysts <a href="https://www.gitpod.io/blog/gartner-2023-cde-hypecycle">Gartner</a> and <a href="https://redmonk.com/jgovernor/2022/12/01/the-year-of-the-cloud-development-environment/">Redmonk</a> confirm this growing interest and investment. Closer to the ground, at Coder we’ve been helping our enterprise customers roll-out CDEs to thousands of developers across a wide range of industries, from banking to <a href="https://coder.com/blog/skydio-takes-development-to-the-literal-clouds">drones</a>. </p>


<h2>Enterprise teams have the same problems, only bigger and more complex</h2>

<p>Your enterprise probably wrestles with these situations:</p>

<ul>
<li><strong>Onboarding:</strong> Developers follow giant tutorials and fill out tickets to set up their environments.</li>
<li><strong>Dependencies:</strong> Dozens, more likely hundreds, of dependencies to manage.</li>
<li><strong>Build times:</strong> Hundreds, probably thousands, of files to check out, index, and compile.</li>
<li><strong>Security/IT compliance:</strong> These take up developer time that would otherwise be spent on actual software development.</li>
<li><strong>Hardware:</strong> High-performance or exotic hardware either sits idle or is overstretched.</li>
<li><strong>Collaboration:</strong> Heterogeneous teams, like developers, testers, and deployers, work on the same projects.</li>
<li><strong>Geography:</strong> Teams and the people in them are spread among several time zones.</li>
<li><strong>Build vs buy:</strong> We’ve seen customers spend more to maintain an in-house CDE platform than they would spend on an managed enterprise solution with more features.</li>
</ul>

<p>The teams in your enterprise might also be spending too much time on non-development activities. We commissioned a survey of 223 enterprise organizations about where their developers spend their time. They report spending as much or more time on configuring their development environments and complying with security and IT policies as they do tasks like planning, coding, and testing.</p>


<h2>Productivity engineering is a balancing act</h2>

<p>Enterprise organizations manage these bigger problems by dedicating staff to productivity engineering. They make sure that development teams have what they need to get work done. </p>

<p><strong>It’s a balancing act:</strong></p>

<ul>
<li>To solve friction points like slow laptops or complicated onboarding, a productivity engineering team takes a product management approach for quick wins. </li>
<li>That puts them at odds with the top-down efforts that they’re also responsible for, like consolidating languages and services.</li>
</ul>

<p><strong>Then there the challenges of doing more with less:</strong></p>

<ul>
<li>Change the core workflows and habits of developers they don&#39;t control. </li>
<li>Work with limited or even shrinking resources.</li>
</ul>

<p>Productivity engineering teams land in a position where they are more likely to focus on squeezing more value out of existing solutions. Any effort to invest in substantial, sustainable improvement seems like a risk. In other words, keeping the status quo feels like a safe bet. </p>

<p>The result: Enterprise organizations invest little in improving developer flow because the complications of their myriad official development environments seem like barriers to adopting a managed CDE platform. </p>

<p>In fact, at Coder we’ve seen that the opposite is true.</p>


<h2>The costs and benefits of a managed CDE platform</h2>

<p>What many enterprises don&#39;t realize is that adopting a managed CDE platform lets them incorporate best practices at the very beginning of the software development lifecycle. This leverage frees up a productivity engineering team’s time to improve the other issues that development teams face. And they can do this systematically and confidently.</p>

<p>Developer experience is, by nature, impossible to define. We believe that improving developer flow starts from the IDE, where developers should spend most of their time. Unlike other tools, we’ve seen how a successful CDE platform roll-out can have a measurable, direct impact on developer satisfaction. </p>

<p>A successful roll-out pays off in the long term too. Once they’ve adopted managed CDE platform, an enterprise is in an excellent position reach goals like these:</p>

<ul>
<li>Faster developer onboarding</li>
<li>Substituting costly in-house developer solutions</li>
<li>Standarding legacy system access</li>
<li>Higher compliance to security and IT policies</li>
</ul>


<h2>A foundation for continuous improvements</h2>

<p>It’s almost impossible for an enterprise to make a confident decision to adopt a CDE without the proper knowledge. There isn’t a lot of guidance out there. </p>

<p>We’ve helped big enterprise development organizations adopt a managed CDE platform as the foundation to improve developer flow. With the right metrics, planning, and communication, we’ve seen our customers get big benefits, bigger than they (or we!) expected.</p>

<p>We’ve put this all together into a whitepaper to help your enterprise do the same. You can learn, step-by-step, how to research, build a business case, plan, implement, and measure the adoption of a managed platform for the CDEs in your enterprise. <a href="https://coder.com/ebooks-and-reports/reports/introducing-cdes-to-your-enterprise">Download the whitepaper here</a>.</p>

<p><em>Related Content:</em></p>

<p><em><a href="https://coder.com/blog/cdes-are-going-to-live-up-to-the-hype">CDEs Are Going to Live Up to the Hype</a></em></p>

<p><em><a href="https://coder.com/blog/four-reference-architectures-for-cdes-kubernetes-vs-vms">Four Reference Architectures for CDEs: Kubernetes vs. VMs</a></em></p>

<p><em><a href="https://coder.com/blog/introducing-the-coder-registry">Introducing the Coder Registry</a></em></p>


Discover how embracing cloud development environments (CDEs) can elevate your enterprise's efficiency and streamline your coding processes, effectively tackling complex issues while boosting developer morale.

Introducing CDEs

Introducing Cloud Development Environments to Your Enterprise

<p>The term “cloud development environment” (CDE) is pretty ambiguous. If you are looking into setting up CDEs for your enterprise, it’s important to consider the different architectures. For example, you may be surprised to learn that the <a href="https://slack.engineering/remote-development-at-slack/">Slack engineering team</a> (as well as 44% of Coder users) use virtual machines over containers as their primary development environment.</p>


Pie chart

<p>We’ll get into the benefits of virtual machines vs. Kubernetes a bit later in the post. There isn’t a one-size-fits all solution.</p>


<h1>Where to run CDEs</h1>

<p>When selecting (or building) a platform for cloud development environments, you should also consider where they are going to run. There are some fully-managed (SaaS) solutions that you can provision inside your cloud account, or hybrid approaches that even support on-prem environments.</p>

<p><strong>SaaS (fully managed)</strong></p>

<p>There are many SaaS solutions that are as simple as sign up, click 
button, get dev environment. If you are in a non-regulated industry and have relatively simple codebases (small-to-medium-sized projects), this is a great option. Replit, GitHub Codespaces, and GitPod are vendors in this space and make it quick to get in and coding. You get into an environment by visiting a URL.</p>

<blockquote>
<p><em>Disclaimer: Coder is intentionally not a SaaS product, so our writing will likely bias towards suggesting running CDEs in your cloud/on-prem CDEs. We think it’s the best fit for large organizations.</em></p>
</blockquote>

<p><strong>In the cloud</strong></p>

<p>If you use a cloud provider such as AWS, Google Cloud, Azure, or DigitalOcean, or are in the process of migrating to the cloud, running development environments in the cloud comes with many benefits. First, CDEs make great training or “best practices” environments with Docker, Kubernetes namespaces, ephemeral environments, cloud CLIs, and any other tools they need. </p>

<p>Second, if your staging and production environments run in the cloud, running CDEs in the same location lets developers access all the storage buckets, databases, and other resources necessary for development. Developers can get an exact replica of what they are deploying against without having to wait on pipelines, configure VPNs, or run mock data/servers locally that often drift from production.</p>

<p>The large cloud providers have solutions, such as Azure Devbox or Google Cloud Workstations. Or, you could always go with a cloud-agnostic vendor like Coder or DevPod. </p>

<p><strong>On-premise datacenters</strong></p>

<p>Your first impression might be “yuck,” but hear me out. Large enterprises have a significant amount of data and dependencies in on-prem datacenters, and plan to keep them there. This means a large number of developers rely on on-prem filesystems, networks, and databases to develop against. We’ve also found that older and more complex codebases benefit more from CDEs as they take a long time to clone, build, and have the most steps to set up manually.</p>

<p>Plus, cloud compute is expensive. Unlike other applications that are mission critical, cloud development environments are often designed to be ephemeral in nature, meaning the premiums we often see in the clouds for reliability and elasticity is less necessary.</p>


<h1>Reference architectures</h1>

<p>Now let’s get into the fun stuff! </p>

<p><strong>Kubernetes deployments</strong></p>

<p>If you are already familiar with and encouraging cloud-native development, running CDEs on Kubernetes is a natural fit. You also save on infrastructure cost compared to VMs as you can overprovision many workspaces on a single node. After all, most of the time, CDEs sit relatively idle except for when they need to burst to build. </p>

<p>In many ways, Kubernetes is a great target environment for cloud development environments. The typical architecture is a pod/deployment with a persistent volume claim mounted at the user’s home directory. </p>


<p>This balance of ephemerality and persistence allows developers to rely on the base image to get the latest version of their tools and languages (e.g. python3) while a persistent disk stores the developer’s unique source code and any IDE customizations. </p>

<p>Since Kubernetes wasn’t made with CDEs in mind, we’ve made several open source tools to make the experience more natural and secure. <a href="https://github.com/coder/envbuilder">envbuilder</a> is an image that can build and run Devcontainers in Kubernetes while <a href="https://github.com/coder/envbox">envbox</a> makes it possible to securely run Docker and system services within Kubernetes pods.</p>

<p>However, there are challenges running CDEs on Kubernetes. Even with proper <a href="https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/">resource management</a> in place, users can encounter a “noisy neighbor” problem through limitations of the underlying nodes such as file watcher limits or network bandwidth. Plus, if you aren’t well-versed in Kubernetes, managing a CDE cluster’s dynamic disks, periodic spikes in usage, and active terminal sessions within pods probably isn’t the place to start!</p>

<p><strong>Kubernetes namespaces</strong></p>

<p>This is like the previous architecture, but even more cloud-native and 🪄magical </p>


<p>Instead of waiting on a pipeline, PR preview environments, or manual deployments, developers can get a remarkably fast inner development loop that matches production. Tools such as Garden, vCuster, Okteto, and Coder make it possible for developers to get their own namespace in Kubernetes to build and deploy against. This reduces a long cycle time, often up to 10 minutes, that developers have to typically wait on to test their changes.</p>

<p>While tools like Garden and Okteto aren’t exactly CDEs (they sync code from a local filesystem to a remote cluster), they give developers an extremely fast development loop and can be <a href="https://github.com/garden-io/garden-coder-example">paired with CDEs</a> like Coder for onboarding and IDE consistency.</p>

<p>See this template for provisioning <a href="https://coder.com/blog/kubernetes-namespaces-as-dev-environments#:%7E:text=Setting%20up%20developer%20environments%20for,or%20spin%20up%20infrastructure%20locally.">Kubernetes namespaces as dev environments</a> in Coder.</p>

<p><strong>VMs with nested containers</strong></p>

<p>This may sound strange, but this is actually the architecture behind GitHub Codespaces. Each workspace is a VM running a single nested container.</p>


<p>Source: <a href="https://docs.github.com/en/codespaces/overview">Github Codespaces Overview</a></p>

<p>There are several benefits to this approach, primarily around isolation. There is no noisy neighbor, and each CDE gets its own dedicated CPU, memory, isolated Docker socket, and volume mounts. At the same time, the developer interacts primarily with the container, giving them a consistent, reliable, and ephemeral environment. VMs are expensive, but as CDEs, they can automatically shut down when not in use. A developer uses their environment about 6 hours each day for 5 days a week. Why pay for it 24/7?</p>

<p>We’ve published two <a href="https://github.com/coder/coder/issues/10735">Coder OSS templates</a>, and are working on building a version of envbuilder targeted at VMs.</p>

<p><strong>Traditional VMs</strong></p>

<p>We found that a large number of developers in enterprise organizations are already using virtual machines for their developer environments, managed CDE platform or not. We worked with SlashData to run a survey of 233 enterprise engineers and 41% reported their primary development environment is a “virtual machine in any cloud,” with only 20% reporting their primary environment was local. The rest were through a CDE platform such as Coder or GitHub Codespaces). </p>

<p>If this is also the case for your organization, moving to a centralized CDE platform gives you standardized operating systems, reduced support costs, smaller security surface area, and reduced cloud cost.</p>

<p>However, attempting to migrate all of these VM workloads to containers may be a mistake. A significant number of workloads may not be designed to run in a container. For example, VMs often are a better fit for large monorepos, desktop applications, app development, or applications that require Linux kernel features. </p>


<p>Source: <a href="https://slack.engineering/remote-development-at-slack/">Remote Development at Slack</a>. Each engineer can lease a VM in an autoscaling group.</p>

<p>You can still make images with dependencies pre-installed with tools such as Packer or EC2 Image Builder, but this isn’t necessarily required. If developers just need a fast, secure, virtual machine and are willing to manually run setup scripts, this can remove the burden of image management. </p>

<p>We have <a href="https://github.com/coder/coder/tree/main/examples/templates">Coder OSS templates</a> for AWS, Azure, GCP, and DigitalOcean. With Terraform, you can decide whether the entire virtual machine is persistent (starts/stops when not in use) or ephemeral (deletes when not in use) with a persistent external “home” volume mounted, similar to the Kubernetes model. </p>

<p><strong>Bonus: Provision any infrastructure as a CDE</strong></p>

<p>Cloud development environments are not one-size-fits all, and we’ve seen some pretty complex configurations that provision cloud secrets, S3 buckets, bare metal machines, NFS mounts, and much more. Here are some of our favorites from our OSS telemetry:</p>


<p>Coder is an open-source platform for managing cloud development environments at scale. By leveraging Terraform-based templates, Coder workspaces can be deployed as pods, virtual machines, containers on any cloud, or even on-prem. Check out the <a href="https://github.com/coder/coder">Coder OSS documentation</a>.</p>

<p>Our enterprise product, built for global 2000 and government organizations, includes security and governance features such as audit log, RBAC, groups, and template policies. <a href="https://coder.com/demo">Request a demo</a> if you’re interested in working with us!</p>

<p>Special thanks to <a href="https://www.linkedin.com/in/alanmbarr/">Alan Barr</a> for guidance and reviewing this post.</p>


The term “cloud development environment” (CDE) is pretty ambiguous. If you are looking into setting up CDEs for your enterprise, it’s important to consider the different architectures. For example, you may be surprised to learn that the Slack engineering team (as well as 44% of Coder users) use virtual machines over containers as their primary development environment.

Four Reference Architectures for CDEs: Kubernetes vs. VMs

<p>We are excited to announce the launch of the Coder Registry: the new hub for creating and extending Coder templates. Visit <a href="https://registry.coder.com">registry.coder.com</a> to browse example templates for various clouds and platforms (e.g. AWS EC2, Kubernetes) and modules to integrate with other software &amp; tools (e.g. JupyterLab, JFrog Artifactory).</p>

<h2>How it works</h2>

<p>With Coder, developers can self-service cloud development environments via Templates. Platform teams build Coder templates with Terraform to define the underlying infrastructure for a workspace. Templates can provision anything as a workspace: EC2 VMs, OpenStack Instances, or ephemeral Kubernetes Pods as workspaces. It’s all configurable via the template!</p>


<p>With the Coder Registry, you can view starter templates for different cloud providers (e.g. AWS) or orchestration platforms (e.g. Kubernetes). Our community can contribute templates as well! </p>

<h2>Modules</h2>

<p>We discovered that many Coder users build templates that do much more than provision infrastructure. Templates were full scripts of to hook into NFS shares, pre-install IDEs (code-server), configure extensions, and even pre-authenticate users with other third-party tools. The extensibility of templates is great, but leads to a lot of code duplication and maintenance burden. </p>

<p>We decided to extract this functionality using a native Terraform feature: <a href="https://developer.hashicorp.com/terraform/language/modules">Modules</a>. Launching today, modules are primarily focused on the following categories:</p>

<ul>
<li>Web IDEs: code-server, JupyterHub, VS Code Web</li>
<li>Third-Party Integrations: JFrog Artifactory</li>
<li>Helpers: Personalize, Dotfiles, Region Parameters, git clone</li>
</ul>


<h2>Vision</h2>

<p>We’ve designed Coder v2 to be extensible, giving every organization the integration points to build their unique developer experience. We will continue building official modules and plan to work with our community and ecosystem partners to make the Coder workspace the hub for developer productivity.</p>


Introducing the Coder Registry #coding #remotedevelopment

<p><em>This video is from our <a href="https://coder.com/webinars/coder-2">Coder 2.0 launch webinar</a>. To discover all the exciting announcements from the launch, be sure to <a href="https://coder.com/webinars/coder-2/register">register</a> for the complete webinar.</em></p>


<h2>Getting started</h2>

<p>If you’re just starting with Coder, browse our <a href="https://registry.coder.com/templates">example templates</a> in the registry to begin creating workspaces on your preferred cloud! </p>

<p>If you’re a Coder operator, we encourage you to begin using modules! Whether you’re <a href="https://github.com/coder/modules/blob/main/CONTRIBUTING.md">contributing to the registry</a> or managing them in an internal repository, modules are a great way to add new integrations and magic into Coder workspaces! 🪄</p>


The new hub for creating and extending Coder templates.

Introducing the Coder Registry

<p>Setting up developer environments for Kubernetes projects can be complex. With Coder, developers can auto-provision a namespace on your development cluster, no need to configure tools or spin up infrastructure locally.</p>

<h2>How it works</h2>

<p>Coder is a self-serve portal for remote developer environments. With a few clicks, an developer can log in with SSO, provision a workspace, and connect via VS Code Remote or a web IDE.</p>


<p>In this tutorial, you&#39;ll learn how to create a <a href="https://coder.com/docs/v2/latest/templates">Coder template</a> that will provision the following resources on behalf of each developer:</p>

<ul>
<li>a Kubernetes namespace</li>
<li>a pod with <code>kubectl</code>, <code>helm</code>, <code>tilt</code>, and other DevOps tools</li>
<li>a persistent <code>/home/coder</code> volume to store projects and git repositories</li>
<li>a <code>ServiceAccount</code> + <code>RoleBinding</code> which allows the user to deploy additional resources within the namespace</li>
</ul>

<p>Developer tools such as <a href="https://tilt.dev">Tilt</a>, <a href="https://skaffold.dev">Skaffold</a>, <a href="https://garden.io">Garden</a>, and <a href="https://okteto.com">Okteto</a> can be used inside Coder workspaces for a quicker development loop. Coder makes it easier to provision Kubernetes infrastructure and give developers IDE access.</p>

<h2>Prerequisites</h2>

<p>This tutorial assumes you already have the following set up:</p>

<ul>
<li><strong>Coder deployment</strong>: Coder is open-source and the dashboard can be installed on Kubernetes, VM, or even a local machine. <a href="https://coder.com/docs/v2/latest/install">Install Coder</a></li>
<li><strong>&quot;Development&quot; Kubernetes cluster</strong>: You&#39;ll need a cluster intended for development workloads, and not production.</li>
<li><strong>Coder CLI</strong>: You&#39;ll need the CLI on your local machine to upload templates. The server and client share the same CLI. <a href="https://coder.com/docs/v2/latest/install">Install Coder</a></li>
</ul>

<h2>Create a new Coder template</h2>

<p>Coder templates are written in Terraform, meaning any resource from the <a href="https://registry.terraform.io/">Terraform registry</a> can be provisoned as part of a template. </p>

<p>Create a new folder for your project on your local machine and create a <code>main.tf</code> file:</p>

<pre><code class="hcl"># main.tf

terraform {
  required_providers {
    coder = {
      source  = &quot;coder/coder&quot;
      version = &quot;~&gt; 0.6.14&quot;
    }
    kubernetes = {
      source  = &quot;hashicorp/kubernetes&quot;
      version = &quot;~&gt; 2.18.1&quot;
    }
  }
}

provider &quot;kubernetes&quot; {
  config_path = &quot;~/.kube/config&quot;
}
</code></pre>

<p>Keep in mind that workspace builds will run Terraform on the Coder server, not your local machine. In this example, there must be a <code>~/.kube/config</code> file on the Coder server. </p>

<p>Refer to the <a href="https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs#authentication">Kubernetes provider documentation</a> to see different authentication methods. This is necessary if you installed Coder via Helm, since the default ServiceAccount does not have permissions to create namespaces.</p>

<p>Next, add a resource block for the namespace. It uses the workspace name, so each new workspace created with this template will also create a unique workspace name. </p>

<pre><code class="hcl"># main.tf (continued)

# Info about the current workspace
data &quot;coder_workspace&quot; &quot;me&quot; {}

# Used for all resources created by this template
locals {
  name = &quot;coder-ws-${lower(data.coder_workspace.me.owner)}-${lower(data.coder_workspace.me.name)}&quot;
  labels = {
    &quot;app.kubernetes.io/managed-by&quot; = &quot;coder&quot;
  }
}

resource &quot;kubernetes_namespace&quot; &quot;workspace&quot; {
  metadata {
    name   = local.name
    labels = local.labels
  }
}
</code></pre>

<p>Now, import your template into Coder.</p>

<pre><code class="sh">coder templates create kubernetes-namespace-example
</code></pre>

<p>In the Coder dashboard, you should see your new template. </p>


<p>You can edit the template settings and add a friendly name, description, and icon. I used the official <a href="https://raw.githubusercontent.com/kubernetes/community/master/icons/svg/resources/unlabeled/ns.svg">Kubernetes namespace icon</a>, but you could also name the template after the project(s) it is intended for.</p>

<p>From the dashboard, you can also create your first workspace using the template. On the workspace page, Coder will show a list of resources your workspace includes.</p>


<p>You can optionally use <a href="">resource metadata</a> to customize the listing and expose info about the namespace:</p>

<pre><code class="hcl"># main.tf (continued)

resource &quot;coder_metadata&quot; &quot;namespace-info&quot; {
  resource_id = kubernetes_namespace.workspace.id
  icon        = &quot;https://svgur.com/i/qsx.svg&quot;
  item {
    key   = &quot;name in cluster&quot;
    value = local.namespace
  }
}
</code></pre>

<p>Push your change to Coder, which will create a new template version:</p>

<pre><code class="sh">coder templates push kubernetes-namespace-example
</code></pre>

<p>After updating your workspace, the resource will have a custom icon and new metadata:</p>


<h2>Add a Kubernetes pod to the template</h2>

<p>Developers will need a way to connect to their namespaces. Let&#39;s add a Kubernetes pod + a ServiceAccount with permissions to provision resources in the pod.</p>

<blockquote>
<p>You can find a full version of this template <a href="https://github.com/bpmct/coder-templates/tree/main/kubernetes-namespace">on my GitHub</a></p>
</blockquote>

<pre><code class="hcl"># main.tf (continued)

# ServiceAccount for the workspace
resource &quot;kubernetes_service_account&quot; &quot;workspace_service_account&quot; {
  metadata {
    name      = local.name
    namespace = kubernetes_namespace.workspace.metadata[0].name
    labels    = local.labels
  }
}

# Gives the ServiceAccount admin access to the
# namespace created for this workspace
resource &quot;kubernetes_role_binding&quot; &quot;set_workspace_permissions&quot; {
  metadata {
    name      = local.name
    namespace = kubernetes_namespace.workspace.metadata[0].name
    labels    = local.labels
  }
  role_ref {
    api_group = &quot;rbac.authorization.k8s.io&quot;
    kind      = &quot;ClusterRole&quot;
    name      = &quot;admin&quot;
  }
  subject {
    kind      = &quot;ServiceAccount&quot;
    name      = kubernetes_service_account.workspace_service_account.metadata[0].name
    namespace = kubernetes_namespace.workspace.metadata[0].name
  }
}

# The Coder agent allows the workspace owner
# to connect to the pod from a web or local IDE
resource &quot;coder_agent&quot; &quot;primary&quot; {
  os   = &quot;linux&quot;
  arch = &quot;amd64&quot;

  login_before_ready     = false
  startup_script_timeout = 180
  startup_script         = &lt;&lt;-EOT
    set -e

    # install and start code-server
    curl -fsSL https://code-server.dev/install.sh | sh -s -- --method=standalone --prefix=/tmp/code-server --version 4.8.3
    /tmp/code-server/bin/code-server --auth none --port 13337 &gt;/tmp/code-server.log 2&gt;&amp;1 &amp;
  EOT
}

# Adds the &quot;VS Code Web&quot; icon to the dashboard
# and proxies code-server running on the workspace
resource &quot;coder_app&quot; &quot;code-server&quot; {
  agent_id     = coder_agent.primary.id
  display_name = &quot;VS Code Web&quot;
  slug         = &quot;code-server&quot;
  url          = &quot;http://localhost:13337/&quot;
  icon         = &quot;/icon/code.svg&quot;
  subdomain    = false
  share        = &quot;owner&quot;

  healthcheck {
    url       = &quot;http://localhost:13337/healthz&quot;
    interval  = 3
    threshold = 10
  }
}

# Creates a pod on the workspace namepace, allowing
# the developer to connect.
resource &quot;kubernetes_pod&quot; &quot;primary&quot; {

  # Pod is ephemeral. Re-created when a workspace starts/stops.
  count = data.coder_workspace.me.start_count

  metadata {
    name      = &quot;primary&quot;
    namespace = kubernetes_namespace.workspace.metadata[0].name
    labels    = local.labels
  }
  spec {
    service_account_name = kubernetes_service_account.workspace_service_account.metadata[0].name
    security_context {
      run_as_user = &quot;1000&quot;
      fs_group    = &quot;1000&quot;
    }
    container {

      # Basic image with helm, kubectl, etc
      # extend to add your own tools!
      image = &quot;bencdr/devops-tools&quot;

      image_pull_policy = &quot;Always&quot;
      name              = &quot;dev&quot;

      # Starts the Coder agent
      command = [&quot;sh&quot;, &quot;-c&quot;, coder_agent.primary.init_script]
      env {
        name  = &quot;CODER_AGENT_TOKEN&quot;
        value = coder_agent.primary.token
      }

      # Mounts /home/coder. Developers should keep
      # their files here!
      volume_mount {
        mount_path = &quot;/home/coder&quot;
        name       = &quot;home&quot;
        read_only  = false
      }
    }
    volume {
      name = &quot;home&quot;
      persistent_volume_claim {
        claim_name = kubernetes_persistent_volume_claim.home.metadata.0.name
        read_only  = false
      }
    }
  }
}

# Creates a persistent volume for developers
# to store their repos/files
resource &quot;kubernetes_persistent_volume_claim&quot; &quot;home&quot; {
  metadata {
    name      = &quot;primary-disk&quot;
    namespace = kubernetes_namespace.workspace.metadata[0].name
    labels    = local.labels
  }
  wait_until_bound = false
  spec {
    access_modes = [&quot;ReadWriteOnce&quot;]
    resources {
      requests = {
        storage = &quot;10Gi&quot;
      }
    }
  }
}

# Metadata for resources

resource &quot;coder_metadata&quot; &quot;primary_metadata&quot; {
  count       = data.coder_workspace.me.start_count
  resource_id = kubernetes_pod.primary[0].id
  icon        = &quot;https://svgur.com/i/qrK.svg&quot;
}

resource &quot;coder_metadata&quot; &quot;pvc_metadata&quot; {
  resource_id = kubernetes_persistent_volume_claim.home.id
  icon        = &quot;https://svgur.com/i/qt5.svg&quot;
  item {
    key   = &quot;mounted dir&quot;
    value = &quot;/home/coder&quot;
  }
}

resource &quot;coder_metadata&quot; &quot;service_account_metadata&quot; {
  resource_id = kubernetes_service_account.workspace_service_account.id
  icon        = &quot;https://svgur.com/i/qrv.svg&quot;
  hide        = true
}


resource &quot;coder_metadata&quot; &quot;role_binding_metadata&quot; {
  resource_id = kubernetes_role_binding.set_workspace_permissions.id
  icon        = &quot;https://svgur.com/i/qs7.svg&quot;
  hide        = true
}
</code></pre>

<p>Be sure to push a new template version:</p>

<pre><code class="sh">coder templates push kubernetes-namespace-example
</code></pre>

<p>ℹ️ See my <a href="https://github.com/bpmct/coder-templates/tree/main/kubernetes-namespace">GitHub repository</a> for a complete example of this template.</p>

<h2>That&#39;s it!</h2>

<p>From there, a developer can connect via VS Code, SSH, or a web terminal and deploy pods on the cluster!</p>


<h2>Next steps</h2>

<p>You may want to make some changes to the template to get it prepared for your project. Here are some ideas:</p>

<ul>
<li>Use <a href="https://tilt.dev">Tilt</a> or <a href="https://skaffold.dev">Skaffold</a> inside the workspace for faster Kubernetes development against the namespace.</li>
<li>Add <a href="https://coder.com/docs/v2/latest/templates/docker-in-docker">Docker support</a> to run the primary pod so users can build images from their workspace.</li>
<li>Add <a href="https://coder.com/docs/v2/latest/templates#parameters-alpha">parameters</a> to prompt developers with inputs on the &quot;create workspace&quot; page</li>
<li>Modify the template to include a custom base image with more tools (e.g. <code>skaffold</code>, <code>Java</code>, <code>Python</code>)</li>
<li>Add a <a href="https://kubernetes.io/docs/concepts/policy/resource-quotas/">Kubernetes Quotas</a> to the namespace and template to prevent excessive resource use. <a href="https://coder.com/docs/v2/latest/admin/quotas">Coder Quotas</a> can prevent excessive workspace creation.</li>
</ul>

<p>Feel free to <a href="https://discord.gg/coder">reach out on Discord</a> if you have questions. </p>


Set up self-serve Kubernetes workspaces with Coder. Give developers full kubectl access in your cloud.

Kubernetes namespaces as dev environments

<h2>Enhanced Quotas</h2>

<p><a href="https://coder.com/docs/coder-oss/latest/admin/quotas">Quotas</a> is a mechanism for controlling cloud spend in Coder. In November, we&#39;ve enhanced our quotas system:</p>

<ul>
<li><a href="https://coder.com/docs/coder-oss/latest/admin/groups">Groups</a> can have different quota allowances (e.g. data scientists have 50 credits)</li>
<li>Templates can have an associated <a href="https://coder.com/docs/coder-oss/latest/admin/quotas#establishing-costs">cost</a>, which can be a static value (e.g. 20 credits) or calculated from workspace parameters (e.g. &quot;instance type&quot;).</li>
</ul>


Coder workspace build log

<p>See our <a href="https://coder.com/docs/coder-oss/latest/admin/quotas">quotas documentation</a> for more information. This is an enterprise feature.</p>

<h2>Windows installers</h2>

<p>We&#39;ve added the following install methods to simplify installation for Windows:</p>

<ul>
<li>Windows installer (published in <a href="https://github.com/coder/coder/releases">GitHub releases</a></li>
<li><a href="https://winstall.app/apps/Coder.Coder">winget package</a></li>
</ul>


<h2>Performance &amp; scale testing</h2>

<p>In November, we began work on performance-related features to ensure Coder can support deployments up to 3,000 users.</p>

<ul>
<li>Consistent pagination across workspaces, users, and audit pages</li>
<li>Performance fixes to support 1,000 concurrent workspace builds, 10,000 active SSH connections to workspaces, and 1,000 web terminal connections.</li>
</ul>

<p>Stay tuned for more updates around scale testing in December and January! </p>

<h2>Prometheus metrics</h2>

<p>In November, we added documentation on using <a href="https://coder.com/docs/coder-oss/latest/admin/prometheus">Prometheus with Coder</a> as well as a number of metrics around measuring Coder&#39;s usage &amp; performance.</p>


<h2>Template version browser</h2>

<p>You can now preview Terraform and Markdown files within a template version from the Coder dashboard! </p>


<p>Additionally, users can now use any template version with their workspaces. This can be helpful if the latest version is broken or if a user needs to use old features.</p>


Rolling back a workspace's template version

<p>Additionally, users can now use any template version with their workspaces. This can be helpful if the latest version is broken or if a user needs to use old features.</p>

<h2>Port forwarding in code-server</h2>

<p>If you are using code-server inside Coder, ports are automatically forwarded to Coder when you start a server.</p>

<h2>Until next time ✌️</h2>

<p><a href="https://github.com/coder/coder">Install Coder</a>, <a href="https://coder.com/docs/coder-oss/latest/admin/upgrade">upgrade</a> or follow along <a href="https://github.com/coder/coder">on GitHub</a>.</p>


We've release a number of features in Coder v2!

What's New in November 2022

<p>Well, we actually develop on two machines. When our Australian coworkers found out, they wanted one too.</p>


<p>First, let&#39;s explain how we landed here. Over the past few years, we&#39;ve tried a few different solutions for development environments.</p>

<h2>Local environments</h2>

<p>We’re building a remote development platform, so local development wouldn’t be a good choice for us. Awkward. Besides, we don’t want new engineers to wait for equipment or <a href="https://coder.com/docs/coder-oss/latest/CONTRIBUTING">manually set up their environments</a> before they can start at work.</p>

<p>Engineers at Coder use Windows machines, Linux desktops, and MacBooks (x86 and m1).  We’re a small company and don’t want to maintain lengthy wikis with instructions for each platform.</p>

<p>More importantly, we don’t want to be stuck troubleshooting dev environments instead of working on customer-facing features.</p>

<h2>Kubernetes environments</h2>

<p>Our first product, Coder v1, uses Kubernetes to create remote development environments. This allowed us to onboard engineers quickly. Through web IDEs or SSH, engineers develop using powerful cloud compute (gigabit network, 16 cores, 32 GB RAM). Some were even <a href="https://coder.com/blog/i-developed-on-an-ipad-for-two-weeks">developing via an iPad</a>. </p>

<p>After moving our development to Kubernetes, we pretty much spent zero time troubleshooting our environments. However, we spent a lot of time trying to tune our clusters and keep our cloud bill down. We maintained separate clusters in the US, Brazil, and Australia so international employees could develop with low latency. Apart from the compute costs, Google charges ~$72/cluster/mo which gets quite pricey across regions and demo/staging/production environments.</p>


<p>Kubernetes is awesome and we still recommend enterprises use <a href="https://coder.com/docs/coder-oss/latest/install/kubernetes">Coder v2 with Kubernetes</a> but, as a small startup, it was overkill for us. Kubernetes was cheaper than giving each developer a beefy VM, but not by much.</p>

<h2>Today: Docker environments on a bare metal machine</h2>

<p>Our second iteration, Coder v2, gave us a bit more flexibility. We rent a 32-core bare metal machine from <a href="https://teraswitch.com/">TeraSwitch</a> for $400/mo. Typically, the machine is underutilized. However, workspaces can burst to leverage all resources for expensive tasks.</p>


<p>Here are some benchmarks:</p>

<table><thead>
<tr>
<th></th>
<th>TeraSwitch Box</th>
<th>GKE Cluster</th>
<th>Local machine (2019 Macbook Pro)</th>
</tr>
</thead><tbody>
<tr>
<td>Network speed test</td>
<td>2.5 gigabit</td>
<td>1.1 gigabit</td>
<td>100 megabit (simulated)</td>
</tr>
<tr>
<td>Workspace start time</td>
<td>5s</td>
<td>3m 39s</td>
<td>8m 45s (nix-shell)</td>
</tr>
<tr>
<td>Build (coder/coder)</td>
<td>1m 4s</td>
<td>1 min 34 seconds</td>
<td>2m 8s</td>
</tr>
<tr>
<td>Test suite (coder)</td>
<td>18s</td>
<td>47s</td>
<td>1m 56s</td>
</tr>
<tr>
<td>git clone (kubernetes/kubernetes)</td>
<td>44s</td>
<td>56s</td>
<td>3m 24s</td>
</tr>
<tr>
<td>Build (kubernetes/kubernetes)</td>
<td>2m 12s</td>
<td>6m 55s</td>
<td>7m 8s</td>
</tr>
<tr>
<td>Experience</td>
<td>😎 Cool</td>
<td>🙂 Nice</td>
<td>🤷 Meh</td>
</tr>
</tbody></table>

<h2>How we did it</h2>

<ol>
<li><a href="https://github.com/coder/coder">We installed Coder</a> on the primary machine.</li>
<li>We wrote a <a href="https://github.com/coder/coder/tree/main/dogfood">Coder template</a> with Terraform. It that gives each developer a container using the <a href="https://github.com/nestybox/sysbox">sysbox-runc</a> runtime (for <a href="https://coder.com/docs/coder-oss/latest/templates/docker-in-docker">docker-in-docker</a>).</li>
<li>Our engineers log in, create a workspace, and connect over HTTPS (code-server) or SSH (VS Code Remote, JetBrains Gateway).</li>
<li>Admins can push updates to the template anytime. Developers are notified when a new template version is out.</li>
</ol>

<p>Oh, and we set up another machine + template for our Australian coworkers. Since <a href="https://coder.com/docs/coder-oss/latest/networking">Coder’s networking</a> supports peer-to-peer connections, users connect directly with no added latency.</p>


<h2>Coder is free and open source</h2>

<p>Whether you’re a tinkerer, small startup, or (especially 😉) an enterprise with 1000+ developers, we think you’ll like <a href="https://coder.com">Coder</a>.</p>

<p>Developers connect with familiar interfaces (such as VS Code Remote SSH) and admins can manage workspace templates with familiar infrastructure tools (such as Terraform). </p>


<p>See how to install at <a href="https://github.com/coder/coder">https://github.com/coder/coder</a> or <a href="https://discord.gg/coder">reach out on Discord</a> if you have questions. We only charge for <a href="https://coder.com/docs/coder-oss/latest/enterprise">enterprise features</a> such as RBAC and audit logs.</p>


How our development team shares one giant bare metal machine

<h2>Git Authentication</h2>

<p>Link <a href="https://coder.com/docs/coder-oss/latest/admin/git-providers">git providers</a> with Coder to authenticate users when they run <code>git</code> operations in their workspace. All major git providers are supported, including self-hosted ones.</p>


<h2>Template Permissions &amp; Groups</h2>

<p>This <a href="https://coder.com/docs/coder-oss/latest/admin/rbac">enterprise feature</a> allows you to manage which users (and groups of users) can access templates in Coder.</p>


<h2>App sharing</h2>

<p>Expose apps within workspaces to other users, or even the public! We&#39;ve added a <a href="https://registry.terraform.io/providers/coder/coder/latest/docs/resources/app#share">share property</a> that you can use within templates.</p>


<h2>Dashboard redesign</h2>

<p>Many of the pages in the Coder dashboard have been revamped, including the workspace and resource view. There is also a new &quot;Deployment&quot; page which exposes Coder&#39;s configuration values to admins.</p>


<h2>API Tokens</h2>

<p>You can create long-lived API tokens to perform actions on behalf of a user. For example, <a href="https://coder.com/docs/coder-oss/latest/templates/change-management">updating templates with CI/CD pipelines</a>.</p>

<h2>High availability</h2>

<p>Run Coder with horizontal scalability and automatic failover within a single region. This is an <a href="https://coder.com/docs/coder-oss/latest/admin/high-availability">enterprise feature</a>.</p>

<h2>Next steps</h2>

<p><a href="https://coder.com/docs/coder-oss/latest/install">Install</a>, <a href="https://coder.com/docs/coder-oss/latest/admin/upgrade">upgrade</a>, or check out Coder <a href="https://github.com/coder/coder">on GitHub</a>.</p>


Groups, template RBAC, API tokens, dashboard redesign, 

What's New in October 2022

<p>Remote IDEs bring enormous speed and productivity benefits to software teams. Server-class machines lead to faster performance and reduced cycle time between changing code and seeing the result. For developers, this means faster <a href="https://coder.com/blog/automate-developer-onboarding-with-coder">onboarding</a> and less time <a href="https://coder.com/blog/reduce-ci-failures-with-unified-dev-and-build-environments">troubleshooting</a> environments.</p>

<p>However, it&#39;s important to provide great developer experience with remote workspaces. Previously, we’ve discussed how to support <a href="https://coder.com/docs/coder/latest/workspaces/editors">VS Code and JetBrains IDEs</a> in the cloud. In this post, we’ll cover <strong>latency</strong>.</p>

<h2>Latency hinders flow</h2>

<p>As demonstrated by a <a href="https://input-delay.glitch.me/">typing latency simulator</a>, latency immediately impacts your flow. A reliable connection is just as important as having powerful servers.</p>


<p>In this post, we’ll refer to “latency” as the connection delay between the developer (client) and workspace (server), and not operations inside the workplace itself (compiles, builds, tests) as those are unaffected by the user’s internet speed.</p>

<p>Let’s take a look at how we can tune remote workspaces to have the “snappy” experience we know and love. </p>

<h2>Optimize your infrastructure</h2>

<p>First, we recommend using servers <strong>close in proximity to your developers</strong>! 🌎</p>

<p>At Coder, we have a distributed engineering team. Our developers can pick between servers in the United States, United Kingdom, Spain, Australia for the optimal experience. If engineers join from another location, we can quickly deploy another <a href="https://coder.com/docs/coder/latest/admin/workspace-providers">workspace provider</a> in that region to support them. </p>


<p>If you are using a managed development platform, this is not something you can control. If geolocation and network speeds are important to you, we recommend self-hosting your IDEs. You can use software such as <a href="https://coder.com/docs">Coder</a>, <a href="https://www.gitpod.io/self-hosted">Gitpod</a>, or a homegrown solution.</p>

<h2>Native IDEs vs virtual desktops</h2>

<p>If you’re developing through a virtual desktop solution (e.g VDI, RDP, VNC), the overhead from streaming an entire desktop environment will often result in additional latency.</p>

<p>Whenever possible, we recommend using native IDEs (web-based or desktop). With VS Code and JetBrains <a href="https://coder.com/docs/coder/latest/workspaces/editors">remote development extensions</a>, you can develop directly on remote workspaces with low latency.</p>

<p>If you still need to access desktop-only apps, you can still use your virtual desktop and your IDE, potentially all <a href="https://coder.com/blog/run-any-application-or-ide-in-coder">through the same workspace</a>.</p>


<p>If you need fast remote desktop access, <a href="https://parsec.app/">Parsec</a> is an emerging tool to keep an eye on. Today however, Parsec does not have support for Linux hosts.</p>

<h2>Use direct connections, whenever possible</h2>

<p>Reducing proxies and network hops provides users a snappier and more reliable experience, which is why we went through the effort of <a href="https://coder.com/blog/rearchitecting-coder-networking-with-webrtc">implementing a peer-to-peer network architecture</a> in Coder. As a result, we have achieved a 68% latency reduction, as measured by our <a href="https://github.com/coder/coder-cli/blob/main/docs/coder_workspaces_ping.md">workspace ping utility</a> (61.23ms to 29.92ms) for our internal developer workspaces.</p>

<p>While your own performance improvement may vary depending on your network topology, in general, reducing the number of network hops and the physical distance between your computer and the server will reduce your perceptible latency.</p>

<h2>Improving SSH responsiveness</h2>

<p>For those who prefer to use vim/terminals development, <a href="https://mosh.org/">mosh</a> is a great tool for reducing perceived latency in SSH connections.</p>


<p>Mosh particularly comes in handy if you are on a limited internet connection, or if you’re far away from the data center.</p>

<h2>Offline development</h2>

<p>You may find yourself in cases where you’d like to access your workspace without a stable internet connection, such as on an airplane. </p>

<p>We plan to cover this in a dedicated blog post, but our general recommendation is to define your remote workspaces with non-proprietary tools. With Dockerfiles, devcontainers, or standard VM images, you can optionally run your environments on local machines for an, albeit slower, offline development experience. Once an internet connection is restored, you can sync files back to your remote workspace.</p>

<h2>Coder: self-hosted developer workspaces</h2>

<p>If you’re serious about moving software development to your infrastructure, we’d <a href="https://coder.com/demo">love to chat</a>. You can also <a href="https://coder.com/docs/coder/latest/setup/docker#installing-coder-for-docker">install Coder</a> for free and try it yourself.</p>


Remote IDEs bring productivity benefits to software teams. See how to optimize them for low latency

Achieving low latency remote development

<p>We’ve added <a href="https://marketplace.digitalocean.com/apps/coder">Coder</a> to the DigitalOcean marketplace! Coder is a self-hosted platform for managing remote IDEs. Coder can be particularly useful if you’re looking for faster dev environments or onboarding developers. You can also develop from an iPad!</p>


<p><strong>How it works:</strong></p>

<ol>
<li>Deploy a DigitalOcean droplet with our <a href="https://marketplace.digitalocean.com/apps/coder">Coder one-click application</a></li>
<li>Build a container image with your project’s dependencies <a href="https://marketplace.digitalocean.com/apps/coder">(docs)</a></li>
<li>Create workspaces and use your favorite IDE (VS Code, IntelliJ, JupyterLab, etc)</li>
<li>Invite your team members to your Coder deployment (optional)</li>
</ol>

<p>If you’re not a DigitalOcean user, you can deploy Coder to any cloud or on-premises. Visit the <a href="https://coder.com/docs">Coder setup docs</a> for instructions with AWS, Google Cloud, Azure, Google Cloud, Docker, Kubernetes, etc.</p>


Coder is a self-hosted platform for managing remote IDEs. We're excited to be a partner on the DigitalOcean marketplace.

Dev Environments on DigitalOcean with Coder

Jonathan Yu

Senior Software Engineer

<p><strong>The challenge</strong></p>

<p>Continuous integration helps deliver complex software faster and more reliably. When failures occur, however, developers can try to reproduce the failure locally, or resort to diagnosing and resolving the problem by pushing additional changes to the pull request and waiting for a new build to complete, which results in long cycle times. In addition, they do not have access to familiar debugging tools, and will instead need to rely on non-interactive build logs:</p>


<p>The other option is for developers to reproduce the failure locally. To do so, however,  they often need to interpret and translate the configuration files used for the build, which can be complex and specific to a particular continuous integration system. Moreover, warnings or errors can be difficult to replicate due to subtle differences, such as versions of a tool or installed plugins.</p>

<p>Coder presents a third option: since it runs standard container images, you can use common images between development workspaces and build environments, eliminating <a href="https://coder.com/blog/what-is-configuration-drift">configuration drift</a>, not just between developers, but also between developers and the build system.</p>


<p><strong>Solution</strong></p>

<p>By moving developer workspaces to Coder, everyone on the team develops with a consistent set of tools, down to the exact version. Expanding upon this, we can reuse the same base image in build environments as well, reducing the divergence between dev and build infrastructure. When failures happen in the build system, developers can reproduce them in their personal development environments, confident in the knowledge that the tools and versions match.</p>

<p>For years, our team at Coder has been using this development/build/test workflow, greatly simplifying the process of debugging inevitable failures. When we have a lint check failure in our build environment, we can re-run the command in our development environment, comfortable in the knowledge that the output will be the same, since the tools are identical. For other checks that run frequently in continuous integration and rarely on local machines, such as browser-based tests, we ensure that local checks continue to succeed. In other words, our build/test infrastructure ensures that our development container image includes the exact tools necessary to build the software, acting in a virtuous cycle and ensuring dependencies are kept in sync.</p>


<p>Implementing this workflow with a system like GitHub Actions is simple: build a container image including the necessary development/build dependencies, push it to a container registry, and run builds using that image.</p>

<p><strong>Other benefits of this approach</strong></p>

<p>In addition to the primary benefit of keeping everything synchronized between development, build, and test environments, this workflow also:</p>

<ul>
<li>Improves portability of your build environment, since many build systems (including <a href="https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontainer">GitHub Actions</a>, <a href="https://docs.gitlab.com/ee/ci/docker/using_docker_images.html">GitLab CI</a>, <a href="https://buildkite.com/docs/tutorials/docker-containerized-builds">Buildkite</a>, and <a href="https://circleci.com/docs/2.0/custom-images/">CircleCI</a>) support running builds inside containers using an image you control</li>
<li>Allows the use of container security and compliance scanning tools (e.g., those produced by <a href="https://anchore.com/container-vulnerability-scanning/">Anchore</a>, <a href="https://jfrog.com/xray/">JFrog</a>, <a href="https://www.aquasec.com/">Aqua</a>, and <a href="https://snyk.io/product/container-vulnerability-management/">Snyk</a>) to help ensure that the container images used for development do not include vulnerable dependencies</li>
<li>Consolidates all dependencies for development and build into a Dockerfile, rather than spreading the instructions across documentation and setup scripts</li>
<li>Creates a fully-verifiable software supply chain through container signing with tools like <a href="https://www.sigstore.dev/">Cosign</a></li>
<li>Improves reliability and performance of the build process, since dependencies are “cached” in a container registry, rather than downloaded from various sources</li>
<li>Optionally enables “offline builds,” in which the container running the build is isolated from the Internet, further improving reproducibility and reducing risk of data exfiltration</li>
</ul>

<p>If you’d like to try Coder, you can <a href="https://coder.com/docs/coder/latest/setup/docker">self-host in minutes</a> with Docker. You can also <a href="https://coder.com/demo">request a demo</a> of Coder.</p>


Containerize your dev and build workflows to share dependencies and reduce configuration drift across environments.

Reduce CI failures with unified dev and build environments

<h2>Why you should automate developer onboarding</h2>

<p>It happens too often. A new software engineer joins the team eager to get started. Then they end up waiting days to get the proper hardware, access keys, and instructions for setting up the development environment that they need. </p>

<p>And it doesn’t necessarily end there. The getting started documentation is often outdated or lacking. Setup scripts can be flaky and hard to troubleshoot. </p>

<p>It’s frustrating for engineers <em>and</em> their managers. </p>

<p>There’s a better way to onboard engineers: <strong>remote, preconfigured workspaces.</strong></p>

<p>With preconfigured workspaces, changes to the tech stack are self-documenting, similar to the <em>infrastructure as code</em> padadigm.</p>

<h2>Onboarding with Coder</h2>

<h3>How it works</h3>

<p>Coder helps developers self-serve workspaces, hosted on your organization’s infrastructure. It’s a win-win for everyone involved.</p>


Launching a Coder workspace template from a git repository

<h3>Features</h3>

<ul>
<li>Develop on any device with the web browser, or use desktop IDEs</li>
<li>Pre-install languages, IDEs, web apps, and VS Code extensions in <a href="https://coder.com/blog/whats-in-a-coder-workspace">workspaces</a></li>
<li>Manage groups of users and images in &quot;Organizations&quot;</li>
</ul>

<h3>Use cases</h3>

<p><strong>For new engineers:</strong> a workspace spins up in minutes with all of the required software, including a <a href="https://coder.com/docs/coder/latest/workspaces/editors">variety of IDEs</a> to connect from. One less thing to worry about at a new job! <a href="https://coder.com/blog/new-developers-make-their-first-commit-on-day-1-thanks-to-coder">(example)</a></p>

<p><strong>For engineering leaders:</strong> development environments <a href="https://coder.com/blog/what-is-configuration-drift">stay in sync</a> for your team and codebase, eliminating troubleshooting time and rigid onboarding docs. </p>

<p><strong>For DevOps teams:</strong> workspaces are defined via container images, allowing developers to self-serve infrastructure in a secure and repeatable way.  Leverage your build pipeline and security scanning to make new software a pull request away!</p>

<h2>Next steps</h2>

<p>Like what you see <a href="https://coder.com/trial">try Coder</a> for free (self-host with Docker or Kubernetes).</p>


Create developer workspaces that run on your organization’s infrastructure and have your new engineers start coding on day one.

Automate developer onboarding with Coder

<p>Organizations adopting DevOps continue to benefit from giving developers on-demand access to resources instead of relying on manual systems and ticket queues. In this post, we’ll discuss how Coder and Teleport work together to empower software teams.</p>

<h2>First, let’s define these tools:</h2>

<p><a href="https://coder.com">Coder</a> allows developers to provision remote workspaces on their organization’s infrastructure. Remote workspaces speed up onboarding time, builds, tests, while still giving developers the flexibility they’re used to with local machines.</p>

<p><a href="https://github.com/gravitational/teleport">Teleport</a> gives developers access to cloud infrastructure including Kubernetes clusters, databases, SSH servers, windows servers, and web applications in an easy and secure fashion.</p>

<h2>How it works: automating development workflows</h2>

<p>1) Engineers can spin up Coder workspaces with all the tools they need, defined by a container <a href="https://coder.com/docs/coder/latest/images">image</a> (this can include the <code>teleport</code> CLI).</p>


<p>2) With the Teleport CLI (<code>tsh</code>), it’s simple to connect a Coder workspace to other infrastructure in your clouds, such as a remote Kubernetes cluster, database, SSH servers, or a specific application. Certificates can be short-lived (for debugging) or long-lived (leverage an internal API).</p>


Using Teleport inside a Coder workspace to access additional infrastructure

<h2>Try it yourself</h2>

<p><strong>Prerequisites:</strong></p>

<ul>
<li>Teleport deployment. Follow the <a href="https://goteleport.com/docs/installation/">installation docs</a></li>
<li>Coder deployment. Follow the <a href="https://coder.com/docs/coder/latest/setup">installation docs</a></li>
<li>Machine with Docker (or podman) for building images</li>
</ul>

<p>To use Teleport inside a Coder workspace, you need to create a <a href="https://coder.com/docs/coder/latest/images">custom image</a>. You can also set <a href="https://goteleport.com/docs/setup/reference/cli/#tsh-mfa-rm">environment variables</a> to pre-configure Teleport. </p>

<p><strong>Step 1)</strong> Let’s create the Dockerfile:</p>

<pre><code class="Dockerfile">FROM codercom/enterprise-base:ubuntu

USER root

# Add Teleport CLI (tsh, tctl)

RUN curl https://deb.releases.teleport.dev/teleport-pubkey.asc | sudo apt-key add - &amp;&amp; \
    add-apt-repository &#39;deb https://deb.releases.teleport.dev/ stable main&#39; &amp;&amp; \
    apt-get update &amp;&amp; \
    apt install teleport

ENV TELEPORT_PROXY=https://teleport.mycompany.com

# Add any other tools you’ll need for development here (e.g OpenJDK-11, TypeScript, kubectl)

USER coder
</code></pre>

<p><strong>Step 2)</strong> Build and push the image</p>

<pre><code class="sh"># this will use Docker Hub by default
docker build . -t username/coder-image
docker push username/coder-image
</code></pre>

<p><strong>Step 3)</strong> Create a new <a href="https://coder.com/docs/coder/latest/workspaces/create">Coder workspace</a> with your image. You can connect to the workspace from a web-based or desktop IDE.</p>


Coder works with Teleport! See how these tools work together to empower developer teams.

Secure developer infrastructure with Teleport and Coder

Mark Milligan

Head of Sales

<p>Ona (formerly known as Gitpod) and Coder both provide developers with reproducible, powerful, cloud-based developer environments or workspaces, but they differ dramatically in their target audience: While Ona appears to be focused on individuals or small teams by way of a SaaS offering only, Coder is focused on making cloud development available to the enterprise, with a self-hosted on-premises and public cloud solution. </p>

<p>Here&#39;s how to choose the best fit for your development team.</p>

<h2>Why remote development</h2>

<p>Today most developers have their IDEs on their local machines. There is a growing interest in moving development workspaces and IDEs to the cloud, which solves some key problems for organizations while also offering advantages for the developer:</p>

<ul>
<li><p><strong>start coding on day one</strong> — developers often spend hours or days setting up a development environment on a local machine before they can make their first commit. With cloud-based workspaces, fully configured workspaces are available for developers to <a href="https://coder.com/blog/new-developers-make-their-first-commit-on-day-1-thanks-to-coder">start contributing immediately</a>.</p></li>
<li><p><strong>secure source code</strong> — individual devices remain the <a href="https://resources.coder.com/ai-maturity-model/AI_Maturity_Self_Assessment">least secure endpoint in the software development pipeline</a>. With local development, source code and data are cloned to individual workstations, creating security risks. With cloud-based workspaces, source code and data remain within the organization’s infrastructure.</p></li>
<li><p><strong>less drift</strong> — dependency and <a href="https://coder.com/blog/what-is-configuration-drift">configuration drift in the development environment results in broken environments and builds</a>, i.e., the classic “it works on my machine” problem. Reproducible, cloud-based developer workspaces ensure that everyone is working with the same basic configuration. </p></li>
<li><p><strong>greater compute power</strong> — cloud development eliminates the need to focus on local hardware. Need more processing power? <a href="https://coder.com/cde/premium">Add more cores to your instance</a>—or a GPU.</p></li>
<li><p><strong>remote access</strong> — because development environments are in the cloud, developers can <a href="https://resources.coder.com/whitepaper-the-cube/governing-ai-workflows-thecube-research">access them securely from wherever they are</a>.</p></li>
</ul>

<h2>Ona: Easy to get started, but only hosted SaaS</h2>

<p>Ona is very focused on the developer experience. Getting started with Ona is easy. Like Coder, they developed (and open-sourced) a fork of VS Code suited for the web browser. Using a familiar IDE makes it simpler for developers to transition to remote development, since they do not need to learn new shortcuts, extensions, etc. Ona also supports different IDEs beyond VS Code in the web browser. Developers can choose between VS Code (Web), VS Code (Local), and beta support for IntelliJ IDEs to write code. </p>

<p>Ona’s <a href="https://ona.com/docs/ona/getting-started">opinionated model</a> for development environments can work well for new projects and small teams building web applications. All workspaces are ephemeral, run in containers, and new workspaces can be created for each task (feature, bugfix, code review) a developer does.</p>

<p>There is a growing list of hosted SaaS offerings from larger, more established suppliers like <a href="https://github.com/features/codespaces">GitHub Codespaces</a>, <a href="https://aws.amazon.com/codecatalyst/">Amazon CodeCatalyst</a>, <a href="https://azure.microsoft.com/en-us/products/dev-box/#features">Microsoft Dev Box</a>, and soon <a href="https://about.gitlab.com/direction/create/editor/remote_development/">GitLab</a>. </p>

<h2>Coder: Supporting enterprises, on their infrastructure</h2>

<p>While Ona has a <a href="https://ona.com/docs/ona/configuration/overview">single-tenant SaaS offering</a> option, it has discontinued support for a self-hosted offering like Coder. Coder continues to only be a self-hosted offering because our target customers, larger enterprises, prefer this flexibility and security to run Coder on-premises or in their public cloud.</p>

<p>One example is multi-cluster and workspace infrastructure support. With Coder, workspaces can be provisioned on whatever Kubernetes, Docker or VM infrastructure you prefer, so developers can develop remotely with low-latency wherever they are on the globe. This is particularly useful for organizations that may have teams of developers that are geographically distributed. Coder supports other enterprise-grade features such as built-in single-sign-on, an audit log, configurable workspace resources, quotas, and usage metrics.</p>

<p>Coder supports different types of workspace infrastructure. While Coder can run on Kubernetes, it is not required. Coder also runs on Docker and VMs. The Coder control plane can also run on a laptop, a VM or Kubernetes.</p>

<p>Enterprises can confidently deploy Coder at scale in their organization, measure its adoption, and configure their deployment to match requirements for different teams. </p>

<p>With that being said, the developer experience with Coder is not an afterthought. Coder supports multiple IDEs, full Linux desktop, container and VM development (including Windows and Visual Studio or macOS), GPU support, REST access, CLI  access, and personalization to enable developers and teams to move their existing workflows to remote workspaces.</p>


<table>
  <tr>
   <td>
   </td>
   <th style="text-align: left;">Coder
   </th>
   <th style="text-align: left;">Ona
   </th>
  </tr>
  <tr>
   <td>Try in seconds (laptop)
   </td>
   <td>
         ✅
   </td>
   <td>
   </td>
  </tr>
  <tr>
  <tr>
   <td>Try in seconds (cloud SaaS)
   </td>
   <td>
   </td>
   <td>✅
   </td>
  </tr>
  <tr>      
   <td>SaaS version
   </td>
   <td>
   </td>
   <td>✅
   </td>
  </tr>
  <tr>
   <td>Self-host (Docker)
   </td>
   <td>✅
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>Self-host (Kubernetes)
   </td>
   <td>✅
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>Self-host (Multi-region)
   </td>
   <td>✅
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>Organizations/teams
   </td>
   <td>✅
   </td>
   <td>✅
   </td>
  </tr>
  <tr>
   <td>SSO Support
   </td>
   <td>✅
   </td>
   <td>✅
   </td>
  </tr>
  <tr>
   <td>Usage metrics
   </td>
   <td>✅
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>Audit log
   </td>
   <td>✅
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>Configurable workspace resources and limits
   </td>
   <td>✅
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>GitHub, GitLab, Bitbucket integration
   </td>
   <td>✅
   </td>
   <td>✅
   </td>
  </tr>
  <tr>
   <td>Use VS Code IDEs
   </td>
   <td>✅
   </td>
   <td>✅
   </td>
  </tr>
  <tr>
   <td>Use JetBrains IDEs
   </td>
   <td>✅
   </td>
   <td>✅
   </td>
  </tr>
  <tr>
   <td>Custom apps and IDEs
   </td>
   <td>✅
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>Docker in workspaces
   </td>
   <td>✅
   </td>
   <td>✅
   </td>
  </tr>
  <tr>
   <td>GPUs in workspaces
   </td>
   <td>✅
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>Configure workspace images and templates
   </td>
   <td>✅
   </td>
   <td>✅
   </td>
  </tr>
  <tr>
   <td>Workspace pre-builds
   </td>
   <td>
   </td>
   <td>✅
   </td>
  </tr>
  <tr>
   <td>Workspace snapshots
   </td>
   <td>
   </td>
   <td>✅
   </td>
  </tr>
  <tr>
   <td>CLI 
   </td>
   <td>✅
   </td>
   <td>✅
   </td>
  </tr>
  <tr>
   <td>REST API
   </td>
   <td>✅
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>Collaboration
   </td>
   <td>via third-party <br />IDE extensions
   </td>
   <td>✅
   </td>
  </tr>
</table>

<center><small>This table was last updated on 12/19/2022. Please [contact us](https://coder.com/contact) if you find inaccuracies or missing information.</small></center>


<h2>Next steps</h2>

<p>Ona can be right for some environments, but if you&#39;re looking to securely scale AI agents for your developers then a self-hosted alternative like Coder is exactly what you need.</p>

<p>Learn more by reading <a href="https://coder.com/docs/coder-oss">our documentation</a> or <a href="https://coder.com/trial">sign up for a trial.</a> You can also <a href="https://coder.com/demo">request a demo</a> of Coder or <a href="https://coder.com/contact">request to speak with Sales</a> about licensing and pricing.</p>


Ona and Coder both provide developers with reproducible, powerful, cloud-based developer environments or workspaces. See the differences.

Coder vs. Ona: Which is better for your team?

Joe Previte

Software Engineer

<p>Last week, we released <a href="https://github.com/cdr/code-server/releases">code-server 4.0</a>. This is a big milestone for the project because it’s our first major release since <a href="https://github.com/coder/code-server/releases/tag/3.0.0">March 2020</a>. Here’s what changed.</p>

<h2>New VS Code Architecture 👨🏼‍💻</h2>

<p>For those unfamiliar with code-server, it’s an open-source project that runs VS Code in the web browser. We’ve gone through <a href="https://github.com/cdr/code-server/pull/857">a</a> <a href="https://github.com/cdr/code-server/releases/tag/3.0.0">few</a> <a href="https://github.com/cdr/code-server/pull/2476">iterations</a> of patching the VS Code to support running on the web.</p>

<p>Recently, the VS Code team has open-sourced many of the core <a href="https://github.com/microsoft/vscode/tree/main/src/vs/server">components of the web server</a>. Because of this, we’ve moved to a fork-based workflow so that we are able to support new VS Code versions faster, and leverage the <a href="https://github.com/cdr/code-server/pull/4414">upstream server</a>. ⚡</p>

<h2>Open-VSX Extension Registry 📦</h2>

<p>Microsoft’s extension marketplace is proprietary and limited to use within Microsoft products. This means that unofficial forks such as code-server, openvscode-server, and VSCodium cannot use the marketplace.</p>

<p>Our previous workaround was to maintain our own extension marketplace, this worked for a while but became fragile and unreliable. We opted for the better solution: using the <a href="https://open-vsx.org/">Open-VSX registry</a>. This is now the default extension marketplace for code-server. </p>


<p>We’ve previously documented using open-vsx with code-server, but we’re pretty excited about it being the default option now. Here’s why:</p>

<ul>
<li>Python, C++, CLang, and other language extensions will “just work” 🙌🏼</li>
<li>Many extensions are published and maintained on Open VSX. Our custom registry had to automatically, or often manually pull open-source extensions from GitHub </li>
<li>OpenVSX <a href="https://github.com/eclipse/openvsx/issues/249">added support for web extensions</a>, so code-server users can use their favorite extensions with no issues 🎉</li>
<li>Extensions are available across IDEs (Eclipse Theia, openvscode-server, etc). Users will not need to change their workflow if they switch IDEs</li>
</ul>

<h2>50,000 GitHub stars 🌟</h2>

<p>2021 was a pretty awesome year for code-server. For starters, we hit 50,000 GitHub stars! The project had 86 unique contributors and 748 users participated in issues. Two open source maintainers (<a href="https://github.com/jsjoeio">jsjoeio</a> and <a href="https://github.com/TeffenEllis">TeffenEllis</a>) also joined in 2021. Stay tuned for an in-depth “year in review” for code-server!</p>

<h2>Next steps</h2>

<p>Our next priority for code-server is to assess our changes compared to upstream VS Code and see if we can remove as much as possible. That way, we are more aligned with upstream and can also submit patches upstream 🎉</p>

<p>Big thank you to everyone in the community who contributed to code-server 4.0! We couldn’t have done it without you.</p>


Last week, we released code-server 4.0. This is a big milestone for the project because it’s our first major release since March 2020. 

code-server 4.0

<p>The <a href="https://aws.amazon.com/devops/what-is-devops/">benefits of DevOps</a> and automated deployments are clear for most organizations. Many also leverage containerized workloads to make applications more reproducible and portable. In this post, we’ll discuss shifting further left with ephemeral development and staging environments with Coder + Shipyard.</p>

<p>Today, setting up your machine to develop software projects isn’t a great experience. Too often, <a href="https://github.com/tidepool-org/development#initial-setup">long, manual steps</a> are required and your workspace can quickly shift and behave differently from a coworker’s, resulting in <a href="https://coder.com/blog/what-is-configuration-drift">configuration drift</a>. Cloud development platforms such as <a href="https://coder.com">Coder</a> make it possible to automate developer workspaces following DevOps best practices: ephemeral workspaces defined by code.</p>

<p>Once a developer creates a new branch and commits code (a new feature), automated ephemeral environments make it possible for developer, product, and QA teams alike to test applications before they are deployed to production. This is where Shipyard comes in. Ephemeral environments shorten feedback cycles and automate processes for testing PRs, giving WIP feedback, and deploying to production. Using Coder with <a href="https://shipyard.build">Shipyard</a> allows organizations to supercharge their workflows from development to production.</p>


<h2>How it works: automating development workflows</h2>

<p>1) When onboarding to a project, developers use Coder to create their workspace from a template defined by the team. This workspace includes the IDEs (VS Code, IntelliJ IDEA, PyCharm, etc.), libraries, and tools necessary for development.</p>


Coder workspaces can run Docker and docker-compose, which Shipyard will later use for the staging environment.

<p>2) Once a feature is added, developers commit code to source control (e.g. GitHub) and create a pull request for review.</p>


<p>3) From the pull request, Shipyard automatically deploys a unique shareable ephemeral environment. These Shipyard managed environments are completely independent of one another allowing your teams to iterate on a given feature without needing DevOps intervention or creating problems that can block other teams.</p>


Shipyard environments are automated and short-lived, saving time and compute costs

<p>4) End-to-end tests can be run against these environments using your favorite tools (Cypress, Mabl, CircleCI, ArgoCD etc.) Developers, QA teams, and stakeholders can securely and independently validate new features pre-merge asynchronously. By tightening the feedback loop with Coder + Shipyard features are tested more thoroughly resulting in faster, more stable releases!</p>

<h2>Next steps</h2>

<p>As demonstrated, automating your environments with Coder and Shipyard will make your environments more consistent &amp; accessible for teams.</p>

<p>Coder: <a href="https://coder.com/docs">Docs</a>, <a href="https://coder.com/trial">60 Day Trial</a>, <a href="https://coder.com/demo">Request Demo</a>
Shipyard: <a href="https://docs.shipyard.build/">Docs</a>, <a href="https://shipyard.build">30 Day Trial</a>, <a href="https://shipyard.build/contact">Request Demo</a></p>


Coder and Shipyard give developers superpowers with ephemeral dev and staging environments.

Automated development and staging environments with Coder + Shipyard

<p>If you develop with IntelliJ IDEA, PyCharm, GoLand, or other JetBrains IDEs,  it’s likely you’ve waited for “indexing” to complete after opening a project. While this may be annoying, it’s necessary for IntelliJ and other heavy-weight IDEs to have features such as code search, highligiting, refactoring, and code completion.</p>

<p>Waiting for an IDE to finish indexing a project might not be a big problem for many workflows. After the first load, indexes are cached and subsequent runs are faster. However, indexing time can be a huge blocker for developers, especially in these cases:</p>

<ul>
<li><p>large projects (monorepos, many dependencies, monolithic applications)</p></li>
<li><p>running old/slow machines (indexing is CPU-intensive)</p></li>
<li><p>ephemeral developer workspaces (containers, remote IDEs)</p></li>
</ul>


original: xkcd's "compiling" comic  https://xkcd.com/303/

<p>In this post, we’ll cover how <a href="https://www.jetbrains.com/help/idea/shared-indexes.html">shared indexes</a> can significantly reduce IDE load times, share some examples, and a one-line command to generate these for your project. (Historically, shared indexes have been difficult to set up)</p>

<h2>How indexing works</h2>

<p>Indexing works by traversing the project’s codebase to create a “virtual map” of classes, methods, and objects for future lookups. After the index is generated, it is cached on your device for later use.</p>

<p>Indexing a codebase will likely take the longest <strong>the first time you open it on your machine</strong>. When the codebase changes, such as pulling code or switching branches, your indexes will “update,” but significantly faster than the first time.</p>

<h2>Shared indexes ⚡</h2>

<p><a href="https://www.jetbrains.com/help/idea/shared-indexes.html">Shared indexes</a> make it possible to host pre-generated indexes for others to download, significantly improving loading speeds across your team. These remote indexes work in conjunction with local indexing to ensure your IDE always has up-to-date information on the codebase.</p>


Loading cdr/code-server in WebStorm

<h2>Generating JetBrains shared indexes for your project</h2>

<p>JetBrains has a <a href="https://www.jetbrains.com/help/idea/shared-indexes.html">guide for creating shared indexes</a>, but it involves many steps, including downloading custom tooling and uploading indexes to a CDN. It also lacks instructions for automating this process, to generate indexes in CI, for example.</p>

<p>Using a Docker container to generate shared indexes makes it simple to try locally or automate with cron/CI:</p>

<pre><code class="sh">cd your_large_codebase/

# generate shared indexes
docker run -it --rm \
  -v &quot;$(pwd)&quot;:/var/project \
  -v &quot;$HOME&quot;/indexes-output:/shared-index \
  -e INDEXES_CDN_URL=https://cdn.myserver.com/project \
    -u &quot;$(id -u):$(id -g)&quot; \
  bencdr/indexer:idea-2021.3
</code></pre>

<p>After generating indexes, you can upload the output folder to your CDN, or a local server. You can also use shared indexes without a CDN by using a network share or even your local filesystem for testing. Check out my GitHub repo for details: <a href="https://github.com/bpmct/jetbrains-indexer">https://github.com/bpmct/jetbrains-indexer</a></p>

<h2>Benchmarking shared indexes</h2>

<p>I tested indexing time for some popular projects on my 2019 MacBook Pro. To benchmark your own projects, <code>File → Invalidate Caches</code> in your IDE will allow you to opt in/out of downloading shared indexes to simulate first launching your project.</p>

<table><thead>
<tr>
<th>Project</th>
<th>Language(s)</th>
<th>Local indexing 🐌</th>
<th>With shared indexes ⚡</th>
<th>Improvement %</th>
</tr>
</thead><tbody>
<tr>
<td><a href="https://github.com/kubernetes/kubernetes">kubernetes/kubernetes</a></td>
<td>Go</td>
<td>2m 40s</td>
<td>22s</td>
<td>727%</td>
</tr>
<tr>
<td><a href="https://github.com/cdr/code-server">cdr/code-server</a></td>
<td>Typescript</td>
<td>2m 30s</td>
<td>34s</td>
<td>441%</td>
</tr>
<tr>
<td>Coder internal monorepo</td>
<td>Go &amp; Typescript</td>
<td>3m 20s</td>
<td>32s</td>
<td>625%</td>
</tr>
<tr>
<td><a href="https://github.com/jetbrains/intellij-community">jetbrains/intellij-community</a></td>
<td>Java</td>
<td>6m 30s</td>
<td>2m 15s</td>
<td>288%</td>
</tr>
</tbody></table>

<p>These times were averaged across two test runs. Your mileage will vary depending on network speeds, device performance, etc.</p>

<h2>Remote development &amp; shared indexes in JetBrains</h2>

<p>Recently, JetBrains released <a href="https://www.jetbrains.com/remote-development/">remote development support</a>, making it simple to develop from powerful, remote workspaces. On-demand workspaces have a lot of benefits, such as faster onboarding and better reproducibility. However, first-time indexing happens much more frequently, since, after all, workspaces are meant to be ephemeral.</p>

<p>Shared indexes work with <a href="https://coder.com">Coder</a>, our remote development platform. Coder supports all JetBrains IDEs locally, or via the web browser. If you don’t want to host a CDN for shared indexes, you can include them in the workspace image, so everything loads in a snap ⚡</p>

<p>If you’d like to learn more about Coder, you can <a href="https://coder.com/demo">request a demo</a> or <a href="https://coder.com/trial">try it for free</a>.</p>

<h2>References</h2>

<ul>
<li><a href="https://www.youtube.com/watch?v=xJKff0QUd3c">Talk: Indexing, or How We Made Indexes Shared and Fast</a></li>
<li><a href="https://www.jetbrains.com/remote-development/">JetBrains Remote Development</a></li>
<li><a href="https://www.jetbrains.com/help/idea/shared-indexes.html">JetBrains docs: Indexing</a></li>
<li><a href="https://github.com/damintsew/idea-shared-index-dockerfile">GitHub: idea-shared-index-dockerfile</a></li>
</ul>


Learn how JetBrains’ shared index feature can speed up your IDEs with large projects.

Faster JetBrains IDEs with shared indexes

Tyler Crandall

Product Manager

<p>Coder 1.25 is now available for installation or upgrade, with some important milestone features. In previous releases of Coder, you needed a Kubernetes cluster to install Coder. Today, we are pleased to announce that you can also install and run Coder with Docker! </p>

<p>This release also adds alpha support for using AWS EC2-based workspaces, multi-zone support, and more.</p>

<h2>Run Coder with Docker</h2>

<p>You can now run Coder in seconds with a Docker run command:</p>

<pre><code class="shell">docker run -it --rm -p 7080:7080 \
    -v ~/.coder:/var/run/coder \
    -v /var/run/docker.sock:/var/run/docker.sock \
    codercom/coder:1.25.0
</code></pre>

<p>All you need is <a href="https://docs.docker.com/get-docker/">Docker</a> installed on the machine where you are installing Coder.</p>

<p>Coder for Docker is limited to a single host machine, so it won&#39;t scale to large numbers of workspaces, Coder for Docker can also be used to evaluate features in the latest Coder version before upgrading your larger Coder deployment. For detailed instructions, <a href="https://coder.com/docs/coder/latest/setup/docker">visit our documentation</a>.</p>

<h2>EC2 Workspaces in Coder (Alpha)</h2>

<p>We’ve also added support for provisioning workspaces on EC2 instances, virtual machines managed by Amazon Web Services. </p>

<p>Similar to Coder’s Docker and Kubernetes workspace providers, EC2 workspaces use container images. Each EC2 workspace runs in a container on an individual EC2 instance.</p>


<p>You can try the alpha feature in v1.25 by adding Amazon EC2 in the admin panel. After that, developers can begin creating EC2 workspaces in Coder.</p>

<h2>Workspace providers: explained</h2>

<p>Workspace providers are logical groups of resources to which developers can deploy workspaces. Since the <a href="https://coder.com/blog/coder-v1-17">release of workspace providers in March</a>, they have been mainly used to improve connection speed for geo-distributed teams.</p>

<p>With the introduction of Docker and EC2 workspaces in Coder v1.25, workspace providers now give Coder admins more options for deploying Coder workspaces. As of 1.25, the three providers are now:</p>

<ul>
<li>Kubernetes: one pod powers a single workspace</li>
<li>EC2: one instance powers a single workspace</li>
<li>Docker: one container powers a single workspace</li>
</ul>

<p>We plan to continue to expand the available options in the future with new ways to deploy Coder and workspaces. Read more about <a href="https://coder.com/docs/coder/latest/admin/workspace-providers">workspace providers in our docs</a>.</p>

<h2>AWS IAM Roles for Service Accounts</h2>

<p>We&#39;ve added support for using  IAM roles for AWS Service Accounts. This allows more flexibility in defining which AWS resources Coder can access. To configure this, see <a href="https://coder.com/docs/coder/latest/admin/registries/ecr#option-b-link-an-aws-iam-role-to-the-coder-kubernetes-service-account-irsa">our docs</a>.</p>

<h2>Multi-Availability Zone Deployments Support</h2>

<p>We&#39;ve added support for Coder deployments distributed across multiple availability zones. This improves availability and reduces downtime for teams. This can be done by changing the affinity in the Workspace Provider. Previously this was set by default and is now exposed and can be modified.</p>

<h2>New workspace screen</h2>


<p>The “New workspace” screen has been simplified in Coder v1.25, with many options being moved to the “Advanced” panel. All of the options are still available for familiar users, but the experience has become easier for a user who is new to Coder.</p>

<h2>Kubernetes 1.19 End of Life</h2>

<p>Coder v1.25 will be the last release to support Kubernetes v1.19 clusters.</p>

<p>The final patch release of Kubernetes 1.19 was published on 28 October 2021. As such, Coder v1.26 (released next month) and later will require the use of Kubernetes 1.20 or later. See Coder&#39;s <a href="https://coder.com/docs/coder/latest/setup/kubernetes#supported-kubernetes-versions">version support policy</a> for more information.</p>

<h2>Ready to try out v1.25?</h2>

<p>Start a <a href="https://coder.com/trial">free trial</a>, <a href="https://coder.com/docs/coder/latest/setup/updating">upgrade</a>, or <a href="https://coder.com/demo">request a demo</a></p>


Today, we are pleased to announce that you can also install and run Coder with Docker! 


Coder for Docker and AWS EC2 Alpha: Coder v1.25

<p>JetBrains has released some tools that make it possible to develop remotely with their suite of IDEs 🎉</p>

<ul>
<li>JetBrains Gateway makes it possible to develop on any server over SSH</li>
<li>JetBrains Projector makes  remote development a possibility for JetBrains IDEs like IntelliJ, PyCharm, GoLand, WebStorm, and more.</li>
</ul>

<h2>The benefits of remote development</h2>

<p>Developing on a remote server has a lot of <a href="https://coder.com/blog/why-cloud-development">great benefits</a>, including improved speed, security, and consistency. You can also connect to your workspace from any device! In this post, we’ll compare the tools and walk you through how to get started developing on a remote server (or in Coder) with JetBrains.</p>

<h2>Remote development with your local IDE (JetBrains Gateway) 🖥️</h2>

<p>While it&#39;s still in active development, JetBrains Gateway makes it possible to connect to and develop on a remote server with local JetBrains IDEs.  </p>


<h3>To get started with JetBrains Gateway:</h3>

<p>1) Download the JetBrains Gateway via <a href="https://www.jetbrains.com/toolbox-app/">JetBrains Toolbox</a> for the latest version</p>

<p>2) Connect to a remote server (or Coder workspace) over SSH</p>

<p>JetBrains has also added support in their latest IDEs (2021.3 and above) for remote development without the Gateway application.</p>


<h2>Remote development with your  web browser (JetBrains Projector)</h2>

<p>Another option would be to use <a href="https://github.com/JetBrains/projector-server">JetBrains Projector</a>. You can install JetBrains IDEs on a remote server and access them via the web browser. As mentioned in their <a href="https://blog.jetbrains.com/blog/2021/03/11/projector-is-out/">launch post</a>, JetBrains Projector can be particularly useful if you would like to develop securely from a thin client (web browser).</p>

<p>At the time of writing, the following IDEs are supported: <em>IntelliJ IDEA Ultimate, IntelliJ IDEA Community, IntelliJ IDEA Educational, PhpStorm, WebStorm, PyCharm Professional, PyCharm Community, PyCharm Educational, RubyMine, CLion, GoLand, DataGrip, DataSpell, Rider, Android Studio.</em></p>

<h3>To get started with JetBrains Projector</h3>

<p>There are a few ways to install JetBrains Projector including container images, install scripts, or even an IDE plugin. If you have many opinions on how to install apps on remote servers, <a href="https://jetbrains.github.io/projector-client/mkdocs/latest/ij_user_guide/running/">visit the Projector docs</a> for more information. In this guide, we’ll install Projector with pip.</p>

<p>1) If you don’t have a remote server, you’ll need to create one. An Ubuntu virtual machine from Vultr with 4 CPU cores and 8 GB of memory will work great. </p>


<p>2) Connect to your virtual machine using SSH or the built-in console</p>

<p>3) Install dependencies</p>

<pre><code class="sh">DEBIAN_FRONTEND=noninteractive sudo apt-get update &amp;&amp; \
    sudo apt-get install -y less libxext6 libxrender1 &amp;&amp; \
    libxtst6 libfreetype6 libxi6 python3 python3-pip &amp;&amp; \
    python3-cryptography
</code></pre>

<p>4) Create a user to run Projector</p>

<pre><code class="sh">sudo adduser coder

# give this user sudo access
sudo usermod -aG sudo coder

# log in as this user
su coder
</code></pre>

<p>5) Install pip and the projector-installer</p>

<pre><code class="sh">python3 -m pip install -U pip --user 
pip3 install projector-installer --user

# If you see a warning, add $HOME/.local/bin to path in $HOME/.bashrc 
vim $HOME/.bashrc &amp;&amp; source $HOME/.bashrc
</code></pre>

<pre><code class="sh"># $HOME/.bashrc

# Add to end of file:
export PATH=$PATH:$HOME/.local/bin
</code></pre>

<p>6) Run <code>projector install</code> to install your first IDE on the remote server</p>


<p>7) Install your IDE of choice</p>

<p>8) You can now connect via the web browser!</p>


<p>9) If you haven’t already, you’ll probably want to <a href="https://github.com/JetBrains/projector-installer/blob/master/README.md#Secure-connection">secure your server</a>. You can edit your config with <code>projector config edit</code>. A few options are</p>

<ul>
<li>Set a password (handshake token) for Projector </li>
<li>Only listen on 127.0.0.1, and use a VPN such as <a href="https://tailscale.com">Tailscale</a></li>
<li>Only listen on 127.0.0.1, and secure with something like <a href="https://www.cloudflare.com/products/argo-smart-routing/">CloudFlare Argo</a>, <a href="https://www.pomerium.com/">Pomerium</a>, or <a href="https://ngrok.com/docs#http-auth">ngrok with password protection</a></li>
</ul>

<p>Coder workspaces support JetBrains Projector out of the box. You can use one of Coder’s packaged JetBrains images, or <a href="https://coder.com/docs/coder/v1.24/images/writing#example-installing-an-intellij-ide">build a custom image including a JetBrains IDE</a>.</p>


<h2>Next steps</h2>

<p>We&#39;d like to invite you to try <a href="https://coder.com">Coder</a>, a remote developer workspace platform. Manage multiple workspaces, templates, users, and even develop with multiple IDEs including VS Code, JupyterLab, and JetBrains of course.</p>

<p>To get started, you can <a href="https://coder.com/trial">self-host Coder</a> or try our <a href="https://coder.com/trial">hosted beta</a>.</p>


JetBrains has released some tools that make it possible to develop remotely with their suite of IDEs 🎉

Remote development tools for JetBrains IDEs

<p>In Coder v1.23, we added the ability to configure <a href="https://coder.com/docs/coder/latest/workspaces/applications">workspace applications</a>. This makes it possible to add anything to the workspace applications panel in the Coder dashboard, through a config file. Before this, Coder supported <a href="https://coder.com/docs/coder/latest/workspaces/editors">the most IDEs</a> of any cloud-powered remote development solution – and now you can bring any IDE or desktop application along with you. </p>

<p>In this blog post, we’ll explore a few ways this new functionality can be used to power up and customize your remote workspaces.</p>

<h2>Remote Desktop (VNC)</h2>

<p>Coder’s <a href="https://github.com/cdr/enterprise-images/tree/main/images/vnc">VNC image</a> now includes a custom “Desktop” application This launches a VNC client in the web browser, giving developers access to full desktop applications. We also have instructions to build your <a href="https://coder.com/docs/coder/latest/guides/customization/vnc">own VNC image</a>.</p>


Opening a VNC Desktop in the web browser with Coder

<h2>Desktop applications and IDEs</h2>

<p>To take it one step further, it’s possible to configure and launch a single desktop application as a full-screen application through VNC. </p>


The Insomnia app is only available as a desktop application, but we can use Coder + VNC to create a smooth browser-based experience that adjusts to your window size.

<p>You can also add desktop-only IDEs to your workspace, such as Eclipse or Spyder <a href="https://coder.com/blog/run-a-desktop-ide-in-a-browser-using-coder-and-vnc">(we have guide for that)</a>. I’ve found that the latency can be quite low if you have a good connection to the Coder workspace. In the future, I’d love to try x2go or GTK Broadway to reduce overhead and improve speeds.</p>

<h2>Web-based tools and IDEs (Portainer, JupyterLab, code-server)</h2>

<p>As long as you add it to the image, you can configure &amp; launch any web application through it’s specified icon in Coder.</p>


<h2>Internal tooling</h2>

<p>With custom applications, you can also do things like share an internal tool with your development team, such an onboarding app. </p>


<p>The application can run as a web server in Coder image, which could redirect to an external URL. </p>

<h2>How to configure workspace applications in Coder</h2>

<p>First, make sure you have the feature flag on!</p>


<p>In most cases, you’ll want to use a custom image in Coder to add applications to your workspaces.</p>

<p>Our application specs go into the full details, but a  <code>/coder/apps/config.yaml</code> in the image provides the icons and start scripts for applications.</p>

<p>You can use <a href="https://github.com/bpmct/team-env">this image</a> as a reference, as it has all the apps mentioned below.</p>

<h3>Desktop apps (e.g Insomnia)</h3>

<p>This script will start an application on the VNC desktop and make it full screen. I saved it as <code>/coder/apps/start_insomnia.sh</code> and made sure the file is executable.</p>

<pre><code class="sh">#!/bin/sh

# start Insomnia app on the VNC desktop
DISPLAY=:90 insomnia&amp;
# make it fullscreen 
sleep 2
DISPLAY=:90 xdotool key F11
</code></pre>

<h3>Portainer:</h3>

<p>Portainer is a container management GUI, which makes it easier to develop with containers. As long as CVM workspaces are enabled, we can add it to the apps panel:</p>

<pre><code class="yaml"># saved in: /coder/apps/config.yaml
apps:
  - name: Portainer
    scheme: http
    port: 9000
    # Working directory
    working-directory: /home/coder
    # File path to icon used in application launcher
    icon-path: /coder/apps/portainer.svg
    # VNC server will be started by default in this image
    command: &quot;/usr/bin/docker&quot;
    # Array of arguments for command
    args: [
      &quot;run&quot;,
      &quot;-d&quot;,
      &quot;--publish=8000:8000&quot;,
      &quot;--publish=9000:9000&quot;,
      &quot;--name=portainer&quot;,
      &quot;--volume=/var/run/docker.sock:/var/run/docker.sock&quot;,
      &quot;--restart=always&quot;,
      &quot;--volume=portainer_data:$HOME/portainer&quot;,
      &quot;portainer/portainer-ce:latest&quot;
    ]
    health-check:
      http:
        scheme: &quot;http&quot;
        path: &quot;/&quot;
        port: 9000
</code></pre>

<h3>code-server (different version or patch)</h3>

<pre><code class="yaml"># saved in: /coder/apps/config.yaml
apps:
  - name: code-server
    scheme: http
    port: 8080
    # Working directory
    working-directory: /home/coder
    # File path to icon used in application launcher
    icon-path: /coder/apps/code.png
    # VNC server will be started by default in this image
    command: &quot;code-server&quot;
    # Array of arguments for command
    args: [
      &quot;--auth=none&quot;
    ]
    health-check:
      http:
        scheme: &quot;http&quot;
        path: &quot;/&quot;
        port: 8080
</code></pre>

<h3>JupyterLab (different version or patch)</h3>

<p>You may find that some applications run better as a subdomain. Such is the case for JupyterLab. See <a href="https://github.com/bpmct/team-env/blob/main/.coder/img/coder/apps/config.yaml#L58-L76">this example</a> on redirecting to a dev URL.</p>

<hr>

<p>We’re looking forward to hearing how you customize Coder with this new functionality. Join our community Slack to chat about use cases you’re exploring, feedback you have, or any questions you have along the way. Happy building!</p>


In Coder v1.23, we added the ability to include custom applications in your workspace.

Run any application or IDE in Coder

Marc Paquette

Freelance Writer

<p><em>The original article was written by Ben Potter. We’ve updated it to cover the latest improvements to these methods for connecting to remote development servers.</em></p>

<p>Historically, using a development environment across multiple devices would mean compromises on speed, access, or device options. With VS Code however, developing from any device is much more approachable.</p>

<p><a href="https://code.visualstudio.com/docs/remote/ssh">VS Code (Remote SSH)</a>: Use VS Code on the desktop to connect and develop on a remote machine
- <a href="https://github.com/coder/code-server">code-server</a>: UseAccess VS Code onfrom athe web browser, runs on a remote machine or run a local machine that you access remotely</p>

<p>Both of these tools have their advantages and disadvantages. For most of my projects, I develop remotely on cloud servers. With other projects, like (iOS development), I use my local machine but use tunnels to connect to it from any device.</p>

<p>Here&#39;s my workflow:</p>

<ul>
<li>I use VS Code (Remote SSH) for near-local experience</li>
<li>I use code-server to connect from unfamiliar devices (e.g Grandma’s computer) or “light” devices such as an iPad or Chromebook</li>
<li>I also use VS Code on my MacBook and open it up with <code>code-server --link</code></li>
</ul>

<h2>Installing code-server</h2>

<p><a href="https://coder.com/docs/code-server">code-server</a> is an open source project that hosts VS Code in the web browser. It can be installed on a remote server or locally (to make your local environment remote).</p>

<p>Use code-server’s install script:</p>

<pre><code class="sh"># dry run:
curl -fsSL https://code-server.dev/install.sh | sh -s -- --dry-run

# install:
curl -fsSL https://code-server.dev/install.sh | sh
</code></pre>

<p>Run as a Docker container:</p>

<pre><code class="sh"># Note: running code-server as a Docker container
# will not expose your local projects and settings.
#
# To persist any dependencies installed use a custom image,
# mount volumes, or add them to the home directory

mkdir code-server &amp;&amp; cd code-server
docker run -it --name code-server -p 127.0.0.1:8080:8080 \
  -v &quot;$PWD:/home/coder&quot; \
  -u &quot;$(id -u):$(id -g)&quot; \
  -e &quot;DOCKER_USER=$USER&quot; \
  codercom/code-server:latest
</code></pre>

<p>Other options are in our docs: <a href="https://coder.com/docs/code-server/latest/install">Installing code-server</a></p>

<h2>Syncing code-server and VS Code settings (optional)</h2>

<p>You can also configure code-server to use the same settings and extensions as VS Code.</p>

<pre><code class="sh"># on the machine/container with code-server installed:
vim $HOME/.config/code-server/config.yaml
</code></pre>

<p>Add the VS Code directories. On macOS, they are:</p>

<pre><code class="yaml"># config.yaml

user-data-dir: &quot;/Users/username/Library/Application Support/Code&quot;
extensions-dir: &quot;/Users/username/.vscode/extensions&quot;
</code></pre>

<h2>Connect to a remote server</h2>

<p>Once you have code-server and/or VS Code Remote installed, it’s time to make them accessible remotely. Normally, this would require either port forwarding, configuring firewalls, or a VPN,</p>

<h3>Option 1: code-server —link</h3>

<p>If you’ll only be connecting remotely from the web browser, you can use the <code>code-server --link</code> flag to get a public tunneled URL. Instead of authenticating with a password, you’ll be prompted to log in with GitHub. Future logins with the tunneled URL will verify your GitHub account.</p>

<p>You can also add <code>link: true</code> to code-server’s config.yaml to launch with —link by default.</p>


Secure tunnel, domain, and TLS with code-server --link

<p>Note: &#39;code-server&#39; —link will not proxy your SSH server. The next option can do this for you.</p>

<h3>Option 2: Self-host a tunnel</h3>

<p>A self-hosted tunnel exposes local services to the internet. I’ve chosen <a href="http://inlets.dev">Inlets Pro</a>, which is a self-hosted tunneling software with abstractions that makes it simple to get to my instance of code-server. Inlets is not free, so you’ll need a license for inlets Pro. Their personal plan is $25.00/month. </p>

<p>Since this is also a self-hosted solution, you’ll need a remote server and a domain name. I use <a href="https://www.digitalocean.com/pricing">DigitalOcean</a> for this, which costs me roughly $5/month.</p>

<p><a href="https://github.com/alexellis/">Alex Ellis</a>, the founder of Inlets (and OpenFaaS), and I connected and he provided some excellent support when preparing this guide. Inlets offers a lot of flexibility when it comes to self-hosting tunnels, but also has the <a href="https://github.com/inlets/inletsctl">inletsctl</a> tool to get up and running quickly!</p>

<h4>Installing inlets-pro</h4>

<p>If you already have a server, you can use the <a href="https://docs.inlets.dev/">inlets documentation</a> to install &amp; configure inlets-pro. </p>

<p>In this example, I use inletsctl to deploy an “exit” server. The inlets doc has examples for different providers that work great, just be sure to include the <a href="https://letsencrypt.org/">Let’s Encrypt</a> flags.</p>

<pre><code class="sh">inletsctl create --provider digitalocean \
 --access-token DIGITALOCEAN_ACCESS_TOKEN \
 --region nyc1 \
 --letsencrypt-domain code.bpmct.net \
 --letsencrypt-email ben@example.com \
 --letsencrypt-issuer prod
</code></pre>

<p>Be sure to replace the domain, email, and optionally the <a href="https://status.digitalocean.com/">region</a>. Also include a <a href="https://docs.digitalocean.com/reference/api/create-personal-access-token/">DigitalOcean access token</a> from your account.</p>

<p>After the server is created, inletsctl will return the server’s IP address. Add a DNS A record for your custom domain to the IP. Inlets will also give an example command on how to start a tunnel. Change the —upstream flag to the where code-server is hosted (usually 127.0.0.1:8080). Also, this is where you add your <a href="https://inlets.dev/pricing/">inlets license</a>.</p>

<pre><code class="sh">inlets-pro http client --url &quot;wss://[server IP]:8123&quot; \
  --upstream &quot;code.bpmct.net=http://127.0.0.1:8080&quot; \

Starting HTTP client. Version 0.8.6 - 18d8e239f940d8694532e332867c25f823439cc6
Licensed to: Ben Potter &lt;********&gt;
Upstream:  =&gt; http://127.0.0.1:8080
Connecting to proxy
Connection established.. OK.

# access at https://code.bpmct.net


# if you&#39;re on Linux, you can generate a systemd service file
inlets-pro http client generate=systemd
</code></pre>

<p>After that, you’ll be able to access your secure tunnel via your domain.</p>


Self-hosted inlets tunnel with code-server's authentication

<p>Tunneling a SSH server with inlets is also possible. To do this, we’ll need to log in to the exit server (the one we created with inletsctl) and run a second instance of inlets in TCP mode. We’ll also need to edit our local machine’s SSH settings so that it can listen on another port (since the exit server already uses port 22).</p>

<pre><code class="sh"># add additional local SSH port (2222)
# add a line: &quot;Port 2222&quot;
sudo vi /etc/ssh/sshd_config

# ssh into the exit server (DigitalOcean emails the root password)
ssh root@[SERVER_IP]

# run a TCP exit server as well
inlets-pro tcp server \
 --auto-tls \
 --auto-tls-san=[DOMAIN_NAME] \
 --control-port 8124 \
 --auto-tls-path=/tmp/tcp_certs/

# generate systemd service to keep TCP server running
inlets-pro tcp server --generate=systemd --auto-tls \
 --auto-tls-san=[DOMAIN_NAME] \
 --control-port 8124 \
 --auto-tls-path=/tmp/tcp_certs/

# create the service (ensure it has the proper flags)
sudo vim /etc/systemd/system/inlets-pro-tcp.service

# run the service on start, and start it up now
systemctl enable --now inlets-pro-tcp

# go back to our local machine
exit

# tunnel SSH as well
inlets-pro tcp client \
 --url &quot;wss://[DOMAIN_NAME]:8124&quot; \
 --upstream &quot;127.0.0.1&quot; \
 --ports 2222

# now you can ssh from any device into your local machine
# ssh -p 2222 code.bpmct.net
</code></pre>

<h2>Installing/enabling a SSH server</h2>

<p>If you want to access your dev environment over VS Code Remote SSH, you’ll need an SSH server running on your machine. Most operating systems have a built-in -SSH server that just has to be enabled.</p>

<ul>
<li><a href="https://support.apple.com/en-ca/guide/mac-help/mchlp1066/mac">MacOS</a></li>
<li><a href="https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse">Windows 11 and Windows Server 2022</a></li>
<li>Linux: You probably know what you’re doing for SSH :)</li>
</ul>

<h2>Looking forward</h2>

<p>It’s clear there are a lot of options when it comes to developing in the cloud. Wherever you are developing (local machine, managed service, or private datacenter), developers can have smooth workflows without compromises.</p>

<p>I’m particularly interested in how we can enable these workflows while also reducing the setup/friction associated with developing on remote servers such as provisioning, managing access keys, or setting up tunnels. Here are a few things we’re still exploring and improving at Coder:</p>

<ul>
<li>a single tunnel to a server for SSH and multiple IDEs</li>
<li>extension for tunneling ports inside code-server</li>
<li>1-click provisioning and access for dev servers</li>
<li>dev teams using <a href="https://coder.com/blog/why-cloud-development">containers for their dev environments</a> (local, remote, or hybrid)</li>
</ul>

<p>Thoughts? We’d love to hear from you. Drop us a <a href="mailto:ask@coder.com">note</a> or reach us on <a href="https://cdr.co/join-community">Slack</a>.</p>


How to connect to your VS Code Environment (local or on a cloud server) from any machine by using a remote server!

AI-native Development

Secure Environments for 2,500+ Developers

Ben Potter

Explore the latest from Ben

Using Claude Code with Coder Workspaces

Inside AI Adoption: Lessons from Enterprise Software Development Teams

How AI Agents Are Redefining Developer Workflows at Anthropic

Day 1: Run AI Coding Agents on Your Own Infrastructure with Coder Tasks

Introducing the Coder Backstage Plugin

Introducing Cloud Development Environments to Your Enterprise

Four Reference Architectures for CDEs: Kubernetes vs. VMs

Introducing the Coder Registry

Related content

Introducing Coder Agents

Self-Hosted Doesn’t Always Mean What It Implies

Coder Sets a New Standard for AI Coding with Self-Hosted, AI Model Agnostic Coder Agents