Eric Paulsen

Sales Engineer

<h2>The promise and the problem with OpenClaw</h2>

OpenClaw recently took the developer world by storm. Within weeks, thousands of people had set up their own personal AI assistant. An always-on digital chief of staff that could manage email, handle calendar invites, automate browser tasks, and chat with you across messaging apps like Telegram and WhatsApp. It ran on hardware you own, like a Mac Mini or a cheap cloud server, which meant your data stays under your control. The appeal was obvious.

Then security researchers started looking under the hood.

They found thousands of OpenClaw setups that were accidentally wide open to the Internet. Anyone who knew where to look could access the owner&#39;s shell, browser automation tools, and API keys. The root cause was a design choice: OpenClaw&#39;s main service, by default, listens for connections from any network instead of just the local machine. Its security features are still new and under-tested. The gap between &quot;I got it working&quot; and &quot;it&#39;s exposed to the world&quot; is dangerously small.

The community responded with workarounds: layering on firewalls, VPN tunnels, and reverse proxies. These were patches on a system that wasn&#39;t built with security at its core. OpenClaw was designed as a single-user local tool that organically grew into something much bigger. Security was bolted on after the fact instead of baked in from the start.

I wanted everything OpenClaw offered: a personal AI agent on my own hardware, connected to my real tools, available around the clock. But I also wanted a system where the secure setup is the default, without requiring constant hardening and maintenance.

<h2>Why I actually needed this</h2>

My digital life is a bit chaotic. My downloads folder has 847 files in it. Some are things I need to keep (tax documents, visa paperwork, that one PDF about fixing my dishwasher), others are garbage I downloaded once and forgot about. I can&#39;t tell which is which without opening every single one.

My Gmail inbox has 3,200 unread emails. I miss appointments because calendar invites get buried. I have recipes saved across email, Notes, bookmarks, and screenshots, and when I want to make that pasta dish I had three months ago, I have no idea where I saved it. I bookmark articles to read later and never look at them again.

What I wanted was an AI that could look at my downloads folder every week and tell me &quot;these 15 files are probably safe to delete, these eight look important and need filing.&quot; An assistant that could triage my inbox in the morning and surface the five things that actually need my attention. Something that could scan my calendar and remind me &quot;you have a dentist appointment tomorrow at 2pm, and based on traffic you should leave by 1:30.&quot; An agent that could remember where I saved that recipe, or find the hiking trail recommendations my friend sent me six months ago.

I also wanted separation. I wanted a general-purpose assistant for everyday tasks (email, calendar, recipes, research) and a separate agent for handling more sensitive things like medical questions or financial planning. These contexts shouldn&#39;t mix. My recipe searches shouldn&#39;t live in the same conversation history as questions about retirement accounts.

OpenClaw could theoretically do all of this, but the security posture made me uncomfortable. An agent that reads your email and has access to your file system is one of the most sensitive pieces of software you can run. Having it accidentally exposed to the internet because of a misconfigured firewall wasn&#39;t acceptable.
So I built one that I could actually trust. It took about two weeks, a Mac Mini, and two key pieces of open-source software: <a href="https://blink.coder.com/">Blink</a> (for running the agent) and Tailscale (for keeping it private). The whole stack is free to run with no subscriptions, no vendor lock-in, no cloud dependency. 

Here&#39;s how it works.

<h2>The tech kit I used to make this possible</h2>

<a href="https://blink.coder.com/">Blink</a> is the agent platform. It&#39;s open source, <a href="https://github.com/coder/blink">available on GitHub</a>, and free to use. Think of it as the operating system for your AI assistants. It handles running agents, storing conversation history, managing connections to tools like Gmail or Google Calendar, and deploying updates, all inside isolated containers (essentially, separate virtual rooms that can&#39;t see into each other). Where OpenClaw runs everything in one big process, Blink gives each agent its own sealed environment. It also doubles as your management interface: the Blink Server ships with a built-in web UI where you can chat with your agents, monitor their status, review conversation history, and manage deployments, all from a single browser tab. No separate dashboard to install, no React app to host, no extra service to configure. You deploy Blink, open the UI, and you&#39;re working.

<a href="https://coder.com/products/mux">Mux</a> is the development tool. It lets me run multiple coding sessions side by side, each working on a different feature or experiment. This matters because a great AI agent isn&#39;t built in one sitting. It takes dozens of iterations to get the behavior right. Mux makes that iteration fast.

Mac Mini M4 is the hardware. Apple&#39;s latest compact desktop has more than enough power to run the entire system: the agent platform, the database, and the networking layer, all at once. It idles at about 10 watts, which is less than a desk lamp. It sits on a shelf, plugged into Ethernet, and just runs.

Tailscale is the security layer. It&#39;s also open-source at its core (built on WireGuard) and free for personal use. It creates a private, encrypted network between your devices. Once the Mac Mini joins this network, it becomes invisible to the public internet. There are no open ports, no public web addresses, nothing for an attacker to find. The only way to reach the machine is to be on the same private network, authenticated by your identity. Setup takes about ten minutes.

<h2>Plumbing this into my routine</h2>

Everything runs on the single Mac Mini with four components in one box:

The Blink Server manages agents, handles deployments, and serves the built-in web UI. There&#39;s no separate frontend to deploy, no additional service to maintain. You open <a href="https://your-mac-mini:3005">https://your-mac-mini:3005</a> over Tailscale and you&#39;re looking at a clean interface where you can chat with any of your agents, inspect their logs, provision new ones, and push updates. For a single-box deployment, this collapses the entire stack (runtime, routing, and UI) into one process. Critically, it only accepts connections from the local machine and the Tailscale network, never from the outside world.

Agent Containers are the individual assistants, each running in its own isolated container with its own storage, conversation history, and credentials. I run two. My business agent handles strategy questions, research tasks, and technical ideation. It&#39;s where I think out loud about architecture decisions or ask for competitive analysis. My personal agent is connected to Gmail and Google Calendar and handles the day-to-day: email triage, scheduling, recipe suggestions, and medical questions. Think of each container as a locked office. One agent can&#39;t peek into another&#39;s files. My personal agent has access to my inbox; my business agent doesn&#39;t, and couldn&#39;t even if it tried. This is a fundamental difference from OpenClaw, where everything runs in a single process and a vulnerability in one area could expose credentials from another.

PostgreSQL runs locally on the Mac Mini and stores everything stateful: conversation history, agent configuration, and per-agent state. Each agent gets its own scoped storage within the database. There&#39;s no shared mutable state between them. Running the database locally means no external dependency, no network latency, and no credentials leaving the machine.

<h2>Making the Mac Mini invisible to the internet</h2>

Here&#39;s the core idea: the Mac Mini simply does not exist on the public internet. There are no open ports, no web addresses pointing to it, no way for a scanner or attacker to even find it. The only path in is through Tailscale&#39;s encrypted private network, which requires identity-based authentication using cryptographic proof of who you are.

This approach is fundamentally different from OpenClaw, where security depends on the user doing extra work: setting up firewalls, configuring reverse proxies, rotating tokens. With the Blink + Tailscale approach, the secure setup comes first. You don&#39;t harden the system after the fact. You start from a position where there&#39;s nothing exposed to harden. And because Blink is open source, you can audit exactly how your data is handled. There&#39;s no black box between your credentials and the agent runtime.

Here&#39;s how the two approaches compare across key security concerns:

<table><thead>
<tr>
<th>Concern</th>
<th>OpenClaw (default setup)</th>
<th>Blink + Tailscale</th>
</tr>
</thead><tbody>
<tr>
<td>Main service</td>
<td>Publicly accessible</td>
<td>Local only, invisible from the internet</td>
</tr>
<tr>
<td>Management UI</td>
<td>Separate concern requiring HTTPS setup</td>
<td>Built into Blink Server, one less thing to secure</td>
</tr>
<tr>
<td>Remote access</td>
<td>Standard SSH (publicly accessible)</td>
<td>Tailscale SSH only (private network)</td>
</tr>
<tr>
<td>Authentication</td>
<td>Password or token (still maturing)</td>
<td>Cryptographic identity via Tailscale</td>
</tr>
<tr>
<td>Network discovery</td>
<td>Broadcasts hostname and services</td>
<td>No broadcasts, completely silent</td>
</tr>
<tr>
<td>Credential storage</td>
<td>All in one shared process</td>
<td>Isolated per-agent in separate containers</td>
</tr>
<tr>
<td>Multi-agent safety</td>
<td>Shared state where one breach affects all tools</td>
<td>Container isolation with agents walled off from each other</td>
</tr>
<tr>
<td>Security setup effort</td>
<td>Significant (firewalls, proxies, token rotation)</td>
<td>Minimal (Tailscale install, ~10 minutes)</td>
</tr>
</tbody></table>

To be fair, the OpenClaw community has done impressive work building security guides, and the project&#39;s Tailscale integration is a genuine improvement. But the underlying challenge remains: retrofitting security onto a system that wasn&#39;t designed for it is always harder and riskier than building security in from day one.

<h2>Why I split my agent in two</h2>

OpenClaw gives you one agent that does everything. That sounds convenient until you think about what it means: the same process that handles your strategic thinking also has access to your personal inbox. The same context window that holds your business research also holds your medical questions and recipe history.

I initially tried running a single agent that handled everything: business strategy, email, calendar, recipes, health questions. The context window got cluttered, the system prompt got unwieldy, and the responses got worse. When I asked for a competitive analysis of a customer&#39;s tech stack, the agent would sometimes drift into suggesting dinner recipes because it couldn&#39;t keep the contexts separate.

Blink&#39;s container model lets you run specialized agents that stay in their own lanes. Each agent has its own container, its own conversation history, its own credential store, and its own system prompt. They share nothing. If I decide my business agent needs access to my calendar (to check availability before suggesting meeting times, say), I can grant it read-only access to specific calendars without exposing my entire inbox. The permissions are granular by design.

This separation also improves quality. An agent tuned for one domain performs better in that domain. A system prompt optimized for strategic analysis produces worse recipe suggestions, and vice versa. Specialization makes each agent better at its job.

<h2>Connecting the agent to real tools</h2>

Blink uses what&#39;s called a typed integration registry: a structured way to connect your agent to the tools and services it needs. Each integration (Gmail, Google Calendar, Slack, etc.) is a self-contained module that declares what it needs to run (specific credentials or API keys) and what it can do (a set of actions the AI can use). At startup, the system checks which integrations have their required credentials available, activates those, and makes their capabilities available to the agent. The agent doesn&#39;t need to know the details. It simply sees a menu of available actions and picks the right one based on what you ask.

This design has a real security benefit: integrations are isolated from each other. Your Gmail integration can&#39;t accidentally (or maliciously) access your Calendar credentials. Each module stays in its own lane, with its own scoped storage and its own set of permissions.

Adding a new integration is straightforward: create the module, register it, and deploy. The agent automatically picks up the new tools without any changes to its core behavior or configuration. This means you can start simple (just email, for example) and layer on capabilities over time as your needs grow, without rearchitecting anything.

<h2>Reaching the agent wherever I am</h2>

A personal AI agent is only useful if you can reach it wherever you already are. Blink supports multi-channel messaging out of the box (Telegram, SMS, WhatsApp, Discord, and more) with a clean separation between how messages arrive and how the agent thinks.

Each messaging channel has a lightweight adapter: a small piece of code that translates that platform&#39;s message format into a standard shape the agent understands. The adapter handles the transport; the agent handles the intelligence. This means all the important logic (conversation history, cost tracking, tool use, and model selection) is shared across every channel. No duplication, no drift between platforms.

Adding support for a new messaging platform means writing about 20-30 lines of adapter code. Everything else comes for free.

<h2>Using the right model for the job</h2>

Here&#39;s something I learned quickly: not every message needs your most powerful AI model. If I text my agent &quot;Good morning,&quot; a lightweight model handles it perfectly. If I say &quot;Search my email for the tax document from my accountant and add the April 15th deadline to my calendar,&quot; I need the heavy hitter.

The system automatically routes each message to the right model tier:

Lightweight model (Haiku): Handles simple messages like greetings, acknowledgments, and quick replies. Costs roughly a quarter of the premium model.

Premium model (Sonnet): Handles complex requests that involve using tools, multi-step reasoning, or detailed analysis.

In practice, about 40% of my messages go to the lightweight model, which significantly reduces running costs without any loss of quality for the messages that need full capability. Each response shows which model was used, so I can see exactly where my money goes.

OpenClaw uses a single model for everything, so you pay premium prices even for &quot;thanks&quot; and &quot;got it.&quot;

<h2>Why iteration speed matters</h2>

The first version of any AI agent does the obvious thing. The twentieth version is the one that actually feels useful: handling edge cases gracefully, recovering from errors, maintaining context across long conversations, and responding in a way that feels natural rather than robotic.

This is where <a href="https://coder.com/products/mux">Mux</a> comes in. It lets me work on three or four things in parallel: refactoring one piece of the system in one window, prototyping a new integration in another, and stress-testing in a third. Each has its own workspace and its own version of the code, so experiments don&#39;t interfere with each other.

Combined with Blink&#39;s hot-reload feature (change a file, save it, and the running agent picks up the changes instantly with no restart needed), the feedback loop is remarkably tight. Most of the tuning happens in the system prompt (the set of instructions that tells the AI how to behave), and testing a change is as simple as saving the file and sending a message.

<h2>What it actually costs to run</h2>

Because the entire stack is open source and runs on a Mac Mini you already own, the ongoing costs are minimal:

<table><thead>
<tr>
<th>Item</th>
<th>Monthly cost</th>
</tr>
</thead><tbody>
<tr>
<td>Mac Mini M4 (purchase price spread over 3 years)</td>
<td>~$19</td>
</tr>
<tr>
<td>Electricity (10W around the clock)</td>
<td>~$1.50</td>
</tr>
<tr>
<td>Tailscale (free tier supports up to 100 devices)</td>
<td>$0</td>
</tr>
<tr>
<td>AI model usage (varies by volume)</td>
<td>~$5-15 per agent</td>
</tr>
<tr>
<td>Database (runs locally on the Mac Mini)</td>
<td>$0</td>
</tr>
</tbody></table>

A comparable cloud-hosted OpenClaw setup runs $5-15 per month for the server alone, plus the same AI model costs, plus the time you spend on security hardening. With an open-source stack on your own hardware, the only variable cost is the AI models themselves. The Mac Mini pays for itself within a year.

<h2>What I learned building this</h2>

Set up security first, not last. The temptation is to build everything on your local machine and &quot;add security later.&quot; Don&#39;t. Install Tailscale before you write a single line of agent code. Develop against the private network addresses from the start, and your development environment becomes identical to your production environment. There&#39;s no separate &quot;hardening step&quot; because the secure setup is the only setup.

Start with the right architecture. I initially tried a polling approach (the agent checking for new messages on a timer) before landing on the webhook pattern (messages arrive and trigger the agent immediately). The latter is simpler, faster, and maps cleanly to Blink&#39;s container model. Every messaging adapter should be a thin, stateless translator. The agent handles the thinking.

Use built-in storage instead of adding dependencies. I initially reached for Redis (a popular external database) before realizing that Blink already provides per-agent persistent storage. One fewer external service means one fewer thing to secure and maintain.

Specialize your agents early. I started with one agent that handled everything: business strategy, email, calendar, recipes, health questions. The context window got cluttered, the system prompt got unwieldy, and the responses got worse. Splitting into a business agent and a personal agent improved quality immediately. Each agent is simpler, more focused, and easier to tune.

What this means for personal AI agents

OpenClaw proved that the demand for personal AI agents is real. People want an always-on assistant connected to their actual tools (email, calendar, messaging) running on hardware they control. That instinct is sound. And the open-source ecosystem has matured to the point where you can build something production-grade without paying for a single platform license.

But the execution needs to match the sensitivity of the data. A personal AI agent that reads your email, manages your calendar, and sends messages on your behalf is one of the most sensitive pieces of software you can run. Security has to be foundational. Isolation between agents, encrypted credential storage, private networking, and strict access controls are the bare minimum for software that handles your personal data.

Blink provides the agent runtime, the management UI, and the isolation model. All open source, so you can inspect every line of code that touches your data. Tailscale provides the network security. The Mac Mini provides quiet, efficient, always-on compute. Together, they deliver what OpenClaw promises (a personal AI agent on your own hardware) with a security model designed in from the ground up, and no recurring platform fees.

The entire system was built by one person in about two weeks. Good open-source infrastructure does the heavy lifting. Blink handles deployment, state management, and the user interface. Tailscale handles networking and authentication. Mux accelerates the development process. The engineering time goes where it should: making the agents genuinely useful.

That&#39;s what good infrastructure enables. You spend your time on the agents instead of on the plumbing.

<h2>Getting started</h2>

Blink is open source and available in Early Access. Everything described in this article is free to build yourself:

Blink SDK + Server: <a href="https://github.com/coder/blink">github.com/coder/blink</a>

Mux: <a href="https://mux.coder.com/">mux.coder.com</a>

Tailscale: <a href="https://tailscale.com">tailscale.com</a> (free for personal use)

The quickstart: install Blink, run blink dev, write your first agent, and deploy. Add Tailscale to your Mac Mini and your development machine. You&#39;ll have a secure, always-on AI agent in an afternoon, built entirely on open-source tools you own and control.

I wanted everything OpenClaw offered: a personal AI agent on my own hardware, connected to my real tools, available around the clock. But I also wanted a system where the secure setup is the default, without requiring constant hardening and maintenance.

Why I Ditched OpenClaw and Built a More Secure AI Agent on Blink + Mac Mini

Knowledge workers waste 3.2 hours per week searching for information across disconnected systems—that&#39;s over 166 hours per year, more than <a href="https://slite.com/learn/enterprise-search-survey-findings">a full month of productivity lost</a> to redundant searching.

The bottleneck isn&#39;t search technology. It&#39;s that traditional enterprise search requires users to know which tool to open, which query syntax to use, and how to interpret results. What if you could simply ask a question and get a sourced answer in seconds?

This is where agentic AI creates new value. But Gartner warns that <a href="https://www.reuters.com/business/over-40-agentic-ai-projects-will-be-scrapped-by-2027-gartner-says-2025-06-25/">over 40% of agentic AI projects will be scrapped by 2027</a> due to high costs and execution challenges. The missing piece is infrastructure that makes agent development fast, flexible, and production-ready.

Enter <a href="https://coder.com/blog/coder-launches-blink-the-fastest-way-to-build-and-deploy-ai-agents">Blink: Coder&#39;s open-source platform for building and deploying AI agents</a>. To solve real challenges in our own fast-growing business, we built Animus, a customer intelligence agent that unifies all of Coder&#39;s customer data into a single conversational interface. It went from concept to production in weeks, not months, and achieved immediate adoption across sales, engineering, product, and marketing teams.

<h2>What Blink enables</h2>

Blink removes infrastructure friction from AI agent development. Developers build and test agents from the terminal with hot-reload, switching between chat mode and edit mode with a single keystroke. When it&#39;s time to ship, <code>blink deploy</code> handles everything: no infrastructure code, no container orchestration, no deployment manifests.

The platform provides first-class Slack support, with GitHub and other integrations coming soon. Threading, file uploads, typing indicators, slash commands: Blink&#39;s <code>@blink-sdk/slack</code> package handles all of it without boilerplate. The platform works with any LLM and lets you swap models without rewriting application code.

Unlike coding assistants or workflow automation tools, Blink is a complete development platform for building intelligent, event-driven agents that integrate with real-world systems.

<h2>The proof: Building Animus</h2>

Animus consolidates Coder&#39;s customer intelligence into a single conversational interface. The challenge was representative of what enterprises face: data scattered across Zoom recordings, Salesforce records, Zendesk tickets, internal documentation, and telemetry systems.

<h3>Technical architecture</h3>

Animus combines three capabilities that work together to answer questions no single system could handle alone.

RAG retrieval from a unified knowledge base. All customer data flows into AWS Bedrock Knowledge Base backed by OpenSearch Serverless. Call transcripts from Zoom, Granola, and internal tools get automatically processed and indexed alongside CRM records covering accounts, opportunities, and 87K+ leads. Support tickets maintain customer context, internal documentation stays clearly separated from customer-stated information, and open-source telemetry exports hourly from Google BigQuery.

Structured queries against pre-aggregated summaries. Semantic search alone isn&#39;t sufficient for analytical questions. Animus maintains JSON summaries rebuilt by AWS Lambda functions: account-level data like ARR, renewal dates, and feature adoption; opportunity pipeline by stage, region, and owner with win rates; and lead records with conversion tracking.

Multi-persona reasoning. Different questions require different expertise. The agent applies domain knowledge through specialized lenses: Account Executive perspective for deal status and competitive positioning, Sales Engineer thinking for technical requirements and POV frameworks, Product lens for feature adoption signals, and PMM analysis for messaging effectiveness.

<h3>Development velocity</h3>

What typically requires months of infrastructure work was operational within weeks. The entire agent runtime lives in a single <code>agent.ts</code> file:

<pre><code class="shell">blink dev # Start with hot-reload
blink deploy # Ship to production
</code></pre>

When the agent needed conversation compaction to handle long Slack threads exceeding Claude&#39;s 200K token context limit, the implementation shipped in hours: detect context limit errors, trigger summary generation, replace history with compressed context. Blink handled the infrastructure complexity.

The data pipeline runs on AWS Lambda with Terraform-managed infrastructure. Transcript sync fetches Zoom recordings every 6 hours, processors convert raw formats to searchable text, and indexers build pre-aggregated summaries. This entire pipeline was operational within days of starting development.

<h2>The results</h2>

Animus achieved organization-wide adoption because it solved real problems with zero training required.

Sales teams transformed deal preparation and account management. Reps ask &quot;Summarize the last three calls with Goldman Sachs&quot; and get chronological context that would take 30 minutes to compile manually. &quot;Customers with renewals in Q1 and recent support escalations&quot; surfaces at-risk accounts immediately. &quot;What are customers saying about [competitor]?&quot; aggregates mentions across hundreds of calls.

Sales engineering gets leverage on technical discovery and reference matching. &quot;What does Dropbox’s tech stack look like?&quot; searches transcripts and CRM simultaneously. &quot;Active technical evaluations over $100K&quot; returns deals with SE involvement. Finding reference customers for specific use cases takes seconds instead of email threads.

Product teams stay close to the customer voice without sitting in on every call. &quot;Top 10 customers using Cursor&quot; ranks by mention frequency and context. Synthesizing enterprise feature requests across hundreds of calls happens with a single question.

Leadership gets real-time visibility into pipeline and customer health. Commit deals by region, accounts with declining engagement, feature requests from enterprise customers over $500K ARR: the questions that inform strategic planning now get immediate, sourced answers.

<h2>Three takeaways for building enterprise AI agents</h2>

1. Treat infrastructure as a first-class concern from day one.

Most failed AI projects don&#39;t fail because the AI doesn&#39;t work. They fail because teams spend months on authentication, scaling, state management, and deployment before the agent does anything useful. By the time infrastructure is ready, budgets are exhausted and stakeholders have lost patience.

Blink exists because we learned this lesson building Animus. Choose tools that let you ship a working agent in days, then iterate. If your first version requires custom Kubernetes configs, you&#39;re solving the wrong problem first.

2. Design for trust through transparency.

Enterprise users won&#39;t adopt agents they can&#39;t verify. Every architectural decision in Animus prioritized auditability: source attribution on every answer, clear separation between customer statements and internal claims, full conversation history available for review.

When building your own agents, ask: can users trace any answer back to its source? Can they understand why the agent said what it said? If not, adoption will stall regardless of how accurate the underlying model is.

3. Ship the interface before perfecting the data.

The instinct is to build comprehensive data pipelines before exposing anything to users. Resist it. A conversational interface with incomplete data still provides value and generates feedback that prioritizes future work. A perfect knowledge base with no interface provides nothing.

Animus launched with transcript search and basic CRM integration. Users immediately asked for support ticket context and telemetry data. That feedback shaped the roadmap more effectively than any upfront planning could have.

<h2>What this means for enterprise AI</h2>

Most companies have invested in search tools that require users to learn query syntax and manually synthesize results. They&#39;ve deployed conversation intelligence platforms that capture calls but still require training and configuration. The tools are good but the friction remains.

Animus represents the next step: conversational interfaces that unify scattered data and provide answers with source attribution. Instead of learning five different tools, teams ask questions in natural language.

The infrastructure to build this exists today. <a href="https://coder.com/blog/coder-launches-blink-the-fastest-way-to-build-and-deploy-ai-agents">Blink is available in Early Access</a> following its October 2025 launch at Cloudflare Connect. The difference between abandoned proofs-of-concept and production deployments comes down to infrastructure friction. Teams that can iterate from concept to production in weeks will capture the value first.

That&#39;s what Blink enables.

<h2>FAQ: Architectural decisions from building Animus</h2>

Why start with Slack instead of a standalone interface?

Slack is where our teams already work. Building a separate app would require users to context-switch and remember to use it. Deploying to Slack meant Animus was accessible in the flow of work from day one.

How do you handle hallucination risk?

Source attribution is the primary safeguard. When every claim links to a specific transcript or record, users can verify. The multi-persona reasoning also helps: the agent frames answers through domain-specific lenses rather than generating unconstrained responses.

What happens when Slack threads get too long?

Automatic conversation compaction detects when context approaches Claude&#39;s 200K token limit, generates a summary of the conversation so far, and continues with compressed context. Users don&#39;t notice the handoff.

How much did this cost to build and run?

Development cost was primarily engineering time: one engineer for several weeks. Infrastructure costs are modest: AWS Lambda functions run on-demand, Bedrock Knowledge Base charges by query volume, and Blink Cloud handles deployment. The ROI was immediate given time savings across teams.

Coder built Animus, a customer intelligence agent that unifies scattered enterprise data into a conversational Slack interface, using Blink to go from concept to production in weeks and deliver immediate value across sales, engineering, and product teams.

From Enterprise Search to Intelligent Agents: How Blink Enables Conversational AI at Scale

AI is fundamentally changing how software is built. What started as autocomplete and chat-based helpers has rapidly evolved into agents that can draft text, repair code, update documentation, and trigger full workflows with minimal human input.

This shift is happening inside engineering teams today. But the speed of adoption has created an uncomfortable reality: AI is moving faster than most organizations’ ability to govern, standardize, and operationalize it.

Understanding where your organization sits on this spectrum is the first step toward closing that gap. We&#39;ve developed a practical <a href="https://resources.coder.com/ai-maturity-model/AI_Maturity_Self_Assessment">AI Maturity Model Self-Assessment</a> and comprehensive whitepaper, <a href="https://resources.coder.com/hub/col/resource-center/the-5-stage-maturity-whitepaper">The 5 Stage Maturity Model for Agentic AI Software Development</a>, to help engineering leaders benchmark their current state and identify what comes next. 

When AI adoption outpaces governance, the cracks show up fast. Here’s what you need to know to stay ahead.

<h2>What happens when shadow AI takes hold?</h2>

For many teams, AI usage begins organically. Developers try out tools, use agents in local environments, and automate pieces of their workflow wherever it feels safe. The upside is undeniable - faster delivery, less repetitive work, and more focus on higher-value tasks.

But as AI spreads, so do the risks:

<ul>
<li>Inconsistent setups across teams </li>
<li>Untracked or shadow AI usage </li>
<li>Sensitive context leaking into prompts </li>
<li>Unpredictable agent behavior </li>
<li>Secret exposure </li>
<li>Uneven quality or noisy PRs </li>
<li>Unclear ownership or review standards</li>
</ul>

The rapid, organic adoption of AI tools by individual developers can quickly lead to shadow AI proliferating within an organization, compounding small issues into massive problems. While decentralized experimentation provides immediate velocity and proof of value, the resulting inconsistency in tool setups, untracked usage, and lack of standardized guardrails across teams keep developers from being their best while introducing potential security threats.

An <a href="https://www.tomshardware.com/tech-industry/artificial-intelligence/googles-agentic-ai-wipes-users-entire-hard-drive-without-permission-after-misinterpreting-instructions-to-clear-a-cache-i-am-deeply-deeply-sorry-this-is-a-critical-failure-on-my-part">incident with</a> Google’s Antigravity agentic Integrated Developer Environment (IDE) showed how quickly things can go wrong when AI operates without guardrails. In one of the most recent examples, the AI agent wiped a user’s entire drive while building an application. No warning. No clear reason why it happened. While the agent apologized for its error, this kind of critical error is the exact kind of nightmare scenario that keeps CISOs up at night.

Let’s be clear. This wasn’t a failure of AI capability, it was a failure of environment isolation and governance, exactly the challenges teams face as AI becomes more embedded in development workflows. 

Incidents like this tend to happen when three factors collide - a pattern often described by Simon Willison as the <a href="https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/">lethal trifecta</a>: access to your private data, exposure to untrusted content, and ability to externally communicate. Each on its own is manageable, but together they create high-impact failure modes that traditional engineering processes aren’t designed to catch in time.

Small cracks widen quickly in fast-moving engineering organizations. The more teams rely on AI without structure, the harder it becomes to retrofit the right controls later.

<h2>What does AI maturity look like in software development?</h2>

The organizations that do build a foundation of standardized environments, clear boundaries, defined policy, and full auditability start to unlock something far more powerful: safe scale.

Agents can run in parallel. Automated workflows become predictable. Review cycles tighten. Security improves. Leaders get visibility instead of surprises.Engineering teams finally get the reliability and velocity AI has been promising.

Skydio shows what this looks like in practice. The drone platform company scaled coding agents across a million-line monorepo by treating AI as infrastructure, not individual developer tools. They deployed standardized cloud development environments through Coder, running multiple concurrent AI workstations with clean context isolation.

The results: infrastructure engineers now deliver end-to-end features without handoffs, product managers contribute code, and the team sees a 30-40% increase in merged pull requests. They&#39;ve avoided &quot;AI slop&quot; through bite-sized, single-file PRs that specific team members own and review leading to hundreds of manageable reviews per day instead of one-off massive, unmanageable changesets. Watch the full case study in our webinar, <a href="https://youtu.be/aT0YUV5TavM">How Skydio Scaled Coding Agents to a Million-Line Monorepo</a>.

The challenge is no longer whether to adopt AI - it’s how to adopt it responsibly, and how to progress from early experimentation to consistent, governed, high-leverage use.

<h2>How do you apply an AI maturity model to your organization?</h2>

Think of AI maturity as a deliberate path from individual productivity tools to full-scale autonomous systems. Each stage builds on the last, adding governance and capability in lockstep. Here&#39;s how most organizations progress:

<ul>
<li>Start with IDE assistants. Code completion and chat-based helpers give developers immediate productivity gains with minimal setup. Focus here on establishing baseline policies and tracking which tools your teams actually use. </li>
<li>Move to local agents. Once you have visibility, let engineers direct agents to handle complete tasks—refactoring, test generation, documentation. The key shift is standardizing environments so agents behave predictably across your organization. </li>
<li>Scale to remote automation. Cloud-based agents respond to triggers like bug reports or scheduled maintenance, working in parallel while humans review their output. This is where you&#39;ll see genuine capacity expansion, but it requires organization-wide governance and quality gates to prevent review fatigue. </li>
<li>Experiment with autonomy. At higher maturity, agents function as team members who identify work, interpret requirements, and deliver features with minimal prompting. This level demands robust governance frameworks and clear accountability structures. </li>
<li>Coordinate specialized teams. The most mature organizations deploy multiple agents—product, design, engineering, QA, operations—that coordinate across the full development lifecycle. An orchestrator manages handoffs, maintains quality standards, and enforces budget controls.</li>
</ul>

Most teams will find their inflection point when they begin to scale cloud-based agents, where parallelism unlocks measurable ROI and agents handle routine work while engineers focus on architecture and review. 

Moving up the maturity ladder requires four critical control mechanisms working together: risk-based governance that differentiates access by responsibility level, standardized environments that serve as the execution layer for both humans and agents, a centralized decision point that applies policies consistently across tools and teams, and integrated assurance that automates security checks before merge.

These controls represent a foundation that lets organizations move up the maturity curve without accumulating risk. The teams that get this right unlock the velocity AI promises while maintaining the governance enterprises require. The ones that don&#39;t end up retrofitting controls after incidents, slowing delivery as governance debt compounds.

<h2>Where does your team stand?</h2>

This moment matters. AI is accelerating, and the organizations that treat it as a capability, not a collection of tools, will pull ahead.

Ready to see where your team stands?

We created a short, practical assessment to help engineering leaders benchmark their current stage and understand what comes next.

<a href="https://resources.coder.com/ai-maturity-model/AI_Maturity_Self_Assessment">Take the AI Maturity Model Self-Assessment</a>

And for a deeper look at the full maturity model, including risks, controls, adoption patterns, and recommended next steps, explore the complete publication:

<a href="https://resources.coder.com/hub/col/resource-center/the-5-stage-maturity-whitepaper">Read The 5 Stage Maturity Model for Agentic AI Software Development Whitepaper</a>

AI is fundamentally changing how software is built. What started as autocomplete and chat-based helpers has rapidly evolved into agents that can draft tests, repair code, update documentation, and trigger full workflows with minimal human input. Take Coder's AI Maturity Assessment and read the AI Maturity Model whitepaper to learn how to govern your organization's AI usage.


The Hidden Risks of AI in Engineering (And How to Get Ahead)

The autonomous driving industry operates at the intersection of cutting-edge AI research and mission-critical safety requirements. Organizations developing autonomous vehicle technology face unique development challenges that traditional software environments weren&#39;t designed to handle. From processing petabytes of sensor data to deploying AI models that must perform flawlessly in real-world scenarios, these companies need development infrastructure that can scale, secure, and accelerate their innovation cycles.

<h2>The GPU imperative: Why cloud makes sense</h2>

Autonomous driving organizations have universally embraced a fundamental truth: GPU-accelerated computing isn&#39;t optional, it&#39;s essential. Modern perception models require massive computational resources, with <a href="https://blogs.nvidia.com/blog/gtc-digital-self-driving-ai-infrastructure/">some organizations processing over 1.6 petabytes of sensor data daily from just 50 vehicles</a>.

Training perception models with multicamera inputs can easily exceed the limits of even high-end GPU memory, requiring sophisticated distributed training approaches. For most autonomous driving organizations, maintaining the necessary GPU infrastructure on-premises would require massive capital expenditure and ongoing operational complexity.

Cloud adoption solves this elegantly. Organizations can access the latest GPU hardware without the burden of procurement, maintenance, or rapid depreciation cycles. This approach allows teams to scale compute resources dynamically based on project needs, whether training new perception models or running large-scale simulation workloads.

<h2>Security without compromise: Air-gapped development</h2>

Perhaps the most critical requirement for autonomous driving organizations is maintaining strict security controls while leveraging cloud resources and exploring agentic AI. These teams handle extremely sensitive intellectual property, from proprietary algorithms to detailed mapping data, that must be protected from external access.

<a href="https://coder.com/cde/premium">Air-gapped development environments</a> provide the solution. Unlike traditional cloud development platforms, air-gapped systems create completely isolated network environments where code, data, and models never leave the organization&#39;s security perimeter. This enables teams to leverage cloud-scale compute resources while maintaining the security posture required for autonomous vehicle development.

<h2>Accelerating innovation with pre-configured environments</h2>

Autonomous driving organizations aren&#39;t building traditional web applications, they&#39;re developing complex AI systems that require specialized toolchains, frameworks, and dependencies. Setting up development environments for computer vision, sensor fusion, and deep learning workloads can take weeks when done manually.

Development environment <a href="https://coder.com/docs/admin/templates">templates</a> that can be version-controlled and deployed consistently across teams eliminate this friction entirely. Instead of spending time configuring TensorFlow, PyTorch, CUDA drivers, and specialized autonomous driving frameworks, developers can provision fully-configured workspaces through infrastructure-as-code definitions. These declarative templates can include:

<ul>
<li>Pre-installed AI/ML frameworks optimized for autonomous driving workloads</li>
<li>Configured data pipelines for sensor data processing</li>
<li>Integrated simulation environments for testing algorithms</li>
<li>Standardized toolchains for model deployment and optimization</li>
</ul>

This infrastructure-as-code approach ensures that every developer gets an identical, production-ready environment while allowing DevOps teams to maintain and update configurations centrally.

<h2>Real-time testing: From cloud to edge</h2>

One of the most unique aspects of autonomous driving development is the need for real-time testing on actual vehicles. Code developed in cloud environments must ultimately run on edge computing systems installed in trucks, cars, and other autonomous vehicles.

Modern <a href="https://coder.com/cde">cloud development environments</a> support this workflow through deployment pipelines that can push code directly to edge devices for real-world testing. This capability is essential for autonomous driving companies testing algorithms on trucks and cars in real-world conditions.

<h2>The cultural factor: Attracting top talent</h2>

Beyond technical requirements, autonomous driving organizations compete fiercely for top AI and robotics talent. A <a href="https://ngvtalent.com/talent-demand-report/">2025 industry report</a> analyzing over 1,500 open roles across 40 leading companies highlights strong demand for expertise in machine learning, computer vision, and sensor processing. Providing access to state-of-the-art cloud development environments isn’t just operationally beneficial, it signals that an organization is at the forefront of innovation, fostering a culture that appeals to top engineers.

<h2>How Coder enables autonomous driving innovation</h2>

Coder provides the cloud development environment platform that addresses these specific requirements for autonomous driving organizations. With support for air-gapped deployments, GPU-accelerated workspaces, and infrastructure-as-code templates, Coder enables teams to focus on breakthrough algorithm development rather than environment management.

Autonomous vehicle companies are using Coder to accelerate hardware-in-the-loop (HIL) simulations and test track engineering. These teams run real-time, embedded system development inside the vehicles themselves, often on remote test tracks where the car is the server. Coder lets engineers access and update massive codebases on demand, without needing to return to a data center or wait for traditional CI pipelines. When a vehicle makes a mistake, engineers can analyze the incident, update the software, and deploy changes immediately. What once took days now takes minutes, unlocking faster iteration, lower compute waste, and a safer path to autonomy.

<blockquote>
Coder handles components of development environments in such a way that we can focus on what really matters to us. Coder allows us to focus on solving the problems that are unique to our business while providing an enjoyable and easy to use platform for our developers to do their work.
</blockquote>

Platform Engineer, Wayve Technology Ltd

Autonomous vehicle companies are using Coder to accelerate hardware-in-the-loop (HIL) simulations and test track engineering. These teams run real-time, embedded system development inside the vehicles themselves, often on remote test tracks where the car is the server.

Why Cloud Development Environments Are Critical for Autonomous Driving Pioneers

<h2>The Growing Need for Efficient Cloud Cost Management</h2>

Large enterprises face a common challenge today: the rising costs of cloud infrastructure, especially when deployed at scale across multiple business units. Many organizations struggle to track and allocate cloud costs effectively to individual business units, which can lead to wasted resources, inefficient cloud usage, and a lack of accountability.

<h3>Key Points</h3>

<ul>
<li>Enterprise cloud costs can spiral without effective monitoring and accountability.</li>
<li>The need for accurate chargeback models grows as more business units within the enterprise adopt cloud resources.</li>
</ul>

<h2>Coder: Your Centralized Cloud Development Environment</h2>

Coder is a self-hosted platform that enables Global 2000 enterprises to deploy centralized development environments at scale. Coder streamlines and standardizes developer environments across various business units securely, while leveraging the cloud infrastructure of the enterprise. Coder Premium is built for enterprises with hundreds or thousands of users and multiple platform teams, offering support for a single Coder deployment in a multi-tenant environment.

<h3>Key Features of Coder Premium</h3>

<ul>
<li>Organizations and Groups: Coder&#39;s structure of organizations and groups maps to the business units and teams within an enterprise. This makes it easy to assign groups of users to specific cloud resources and track usage per business unit.</li>
<li>Templates: Workspaces are created from Terraform templates, which not only provide standardized environments but also the necessary cloud resources for developers to perform their tasks.</li>
<li>Role-Based Access Control (RBAC): Workspace templates can be restricted to certain groups, ensuring that access is tightly controlled and aligned with the enterprise’s security and governance policies.</li>
</ul>

<h2>Applying an Enterprise Chargeback Model to Coder</h2>

Below is how a chargeback model can be implemented using Coder’s architecture. The chargeback model ensures that each business unit is responsible for the cloud costs incurred by their developers teams using internal infrastructure through Coder workspaces.

<h3>Mapping Key Coder Constructs to Chargeback</h3>

<ul>
<li>Organizations → Business Units: Coder’s organizations naturally represent the enterprise’s various business units. Each organization can be mapped to a specific cost center within the enterprise.

<ul>
<li>Groups → Teams within Business Units: These groups, nested under Organizations, are mapped from the enterprise’s identity provider, allowing further granularity in tracking cloud usage at the team level within a business unit.

<ul>
<li>Templates → Standardized Workspaces: Workspaces built from templates are provisioned with specific cloud resources. By tagging these resources, enterprises can track usage and costs associated with each business unit.</li>
<li>Tags for Cost Reporting: As workspaces are provisioned, tagging allows for cloud cost reports to be generated. This provides clear visibility into which business units are using cloud resources and the corresponding charges.</li>
</ul></li>
</ul></li>
</ul>

<h2>Tracking Cloud Costs with Workspaces and Templates</h2>

Since Coder templates provision workspaces with the required cloud infrastructure, tagging such resources enables tracking of cloud costs. This could include:

<ul>
<li>A breakdown of resource consumption by organization and group.</li>
<li>Associating costs with workspaces based on the organization or group that requested them.</li>
<li>Integration with existing cloud cost monitoring solutions (e.g., AWS Cost Explorer, Microsoft Cost Management, or Google Cloud’s billing tools) to ensure accurate chargeback reporting.</li>
</ul>

<h2>The Business Value of Coder’s Centralized Solution</h2>

Implementing Coder into your software supply chain brings broad impact to your business and bottom line.

<h3>Benefits for Enterprises</h3>

<ul>
<li>Centralized Management: Coder allows enterprises to maintain centralized control over development environments, ensuring standardization and governance at scale.</li>
<li>Cost Accountability: The chargeback model holds business units accountable for their cloud consumption, driving more efficient resource usage.</li>
<li>Scalability: Coder’s model is inherently scalable, making it an ideal choice for global enterprises with many teams and business units, all while maintaining control over cloud costs.</li>
<li>Developer Efficiency: With standardized, ready-to-use workspaces, developers can be up and running quickly, reducing time spent configuring environments. This increases developer productivity and shortens time-to-market.</li>
<li>Cross-Business Collaboration: The unified platform enables business units to collaborate seamlessly without needing to maintain their own separate development infrastructures.</li>
</ul>

<h2>Conclusion: Coder as a Strategic Investment</h2>

By implementing Coder with a well-structured chargeback model, enterprises can maximize the value of their cloud infrastructure. Coder not only provides a scalable solution for managing cloud development environments, but also enables clear accountability and cost efficiency across business units.

The combination of centralized control, scalable cloud resources, and granular cost reporting makes Coder an essential tool for any enterprise looking to optimize cloud development infrastructure.

If you’re new to Coder, we invite you to start a free <a href="https://www.coder.com/trial">30-day trial of Coder Premium</a>. If you’re a current Coder customer and wish to learn more about Coder Premium, please contact your Customer Success Manager.

The chargeback model ensures that each business unit is responsible for the cloud costs incurred by their developers teams using internal infrastructure through Coder workspaces.

Coder & Enterprise Chargeback Models

This framework provides design principles and architectural best practices for building and operating a highly reliable, efficient and scalable Coder deployment. Built upon the six pillars of the AWS Well-Architected, Coder’s Well-Architected is intended for prospects and customers looking to provide a sustainable cloud development environment solution to their internal developer groups. This document is written for Coder’s operators, whose mission is to support their end-users, who may be developers, data scientists, or business analysts.

<h2>In the Coder Well-Architected Framework, we use these terms:</h2>

<ul>
<li>A CDE (Cloud Development Environment) is an on-demand, ephemeral development environment that is hosted in the public cloud or on-premises. The developer connects to the CDE to access their development environment, either via an in-browser IDE, or through a desktop IDE.</li>
<li>An IDE (Integrated Development Environment) is a text editor developers use to write their code. The Coder workspace exposes the IDE in-browser. Alternatively, a desktop IDE can be used to connect to the Coder workspace.</li>
<li>A KPI (Key Performance Indicator) is a quantifiable metric used to measure the success of an organization. In this case, it is the success of your engineering organization, from a developer productivity and experience perspective.</li>
<li>A <a href="https://coder.com/docs/v2/latest/workspaces">workspace</a> is the development environment Coder users work inside of. They are provisioned using Terraform, inside of the customer infrastructure. Each workspace will have one associated user.</li>
<li><a href="https://coder.com/docs/v2/latest/templates">Templates</a> are a Coder construct consisting of Terraform files, run by the Coder provisioner to create workspaces on behalf of users. Templates may be one or multiple files that represent the underlying infrastructure that hosts the workspace. The Coder server is the control plane of the Coder application. It proxies workspace connects, runs workspace provisioning jobs, makes database calls, and serves the web interface.</li>
<li>A <a href="https://coder.com/docs/v2/latest/admin/provisioners">provisioner</a> is a Terraform runner in the Coder context. It is responsible for start/stop/delete operations on workspaces. One or more can be run at a time, and can be run separately for network isolation purposes. Templates can be tagged to be run and built by specific provisioners.</li>
<li>A <a href="https://coder.com/docs/v2/latest/admin/workspace-proxies">workspace proxy</a> is a server responsible for proxying browser and CLI-based connections to Coder workspace IDEs and terminals. Proxies can be run across regions to serve globally distributed users.</li>
</ul>

<h3>In a Coder deployment, there are two personas:</h3>

<ul>
<li>The end-user is someone who uses Coder to create and access development environments. They could be developers, analysts, or data scientists. The end-user consumes a license seat and has login access to Coder. They are typically a member of a user group that works on a project or specific set of projects. </li>
<li>The operator is responsible for running and maintaining the Coder deployment, either at an application and/or infrastructure level. Operators may be part of a platform engineering or developer experience group. Depending upon the size of your organization, there may be 1-4 operators that provide support to end-users and implement new versions, features of Coder. Operators may consume a license seat, and typically have elevated privileges in Coder, such as User/Template Admin, and/or Owner roles.</li>
</ul>

<h3>Single-region Coder Enterprise deployment</h3>

<a href="https://www.datocms-assets.com/19109/1725975283-single-region-arch-v2.png" target="_blank">Open full-size in a new window</a>
<img src="https://www.datocms-assets.com/19109/1725975283-single-region-arch-v2.png" style="max-width:100%; border-radius:15px;" />

<h3>Multi-region Coder Enterprise deployment</h3>

<a href="https://www.datocms-assets.com/19109/1725975260-multi-region-arch-vertical.png" target="_blank">Open full-size in a new window</a>
<img src="https://www.datocms-assets.com/19109/1725975260-multi-region-arch-vertical.png" style="max-width:100%; border-radius:15px;" />

a. Understand your developer community - When evaluating a CDE, it is important to understand the needs of your developer community, both from a tooling and experience perspective. Ask yourself the following questions:

<ul>
<li>How do developers set up their computing environment when starting on a new project?</li>
<li>How do developers authenticate to other services (version control, package repositories)?</li>
<li>What IDEs are prevalent within the company?</li>
<li>What languages, tools, and dependencies do our developers use?</li>
<li>Can we containerize the development environments?</li>
</ul>

b. Start small - When building templates, start with the simplest possible workspace, before layering on additional infrastructure and use-cases. As with any application, it&#39;s best to build the smallest working unit of the code before adding complexity.

c. Consider workspaces to be ephemeral - CDEs drive value because the environments they create are highly consistent and reproducible. If your environment no longer works, delete and recreate it. You no longer have to limit yourself to a single machine for your development environment. Create multiple workspaces, each unique to a specific project. Keep in mind that workspace disks can also be persisted.

d. Perform changes as code - Operate Coder as you would any highly available application, and use automated deployment methods (such as CI/CD, infrastructure-as-code tooling) to iterate on both the Coder deployment and your workspace templates.

e. Gain insights by implementing observability - Establish KPIs tied to your business outcomes, such as daily active users, or workspace utilization, to inform decision making and improve the return on your investment.

a. Evaluate your organization’s security needs - Pre-configure development tools to point to internal package repositories, and consider blocking access to public repositories at the network layer.

b. Protect data in-transit and at rest - Encrypt network traffic end-to-end using TLS certificates, and encrypt the PostgreSQL database to protect sensitive data such as user access tokens. Workspace disks can also be encrypted if necessary.

c. Implement role-based access control on templates - Templates enable your developers to create infrastructure in a self-service manner. Use <a href="https://coder.com/docs/v2/latest/admin/rbac">role-based access control</a> to limit which users and <a href="https://coder.com/docs/v2/latest/admin/groups">groups of users </a> have access to specific templates. For example, you may need to segment certain business units–such as full-time employees and third-party contractors–from one another, to prevent unapproved access to infrastructure and code.

d. Isolate provisioners to specific clouds/clusters - Run a provisioner deployment inside each cloud or cluster you plan to use for workspaces. Utilize the native service identity for that cloud or cluster to authorize provisioning. Enforce the smallest set of privileges that allow successful provisioning within each cloud or cluster. This will reduce the blast radius of a compromised provisioner.

e. Enforce workspace updates - Templates enable you to update your fleet of developers with one push, whether that update consists of a patched vulnerability, or a tooling change. Put policies in place to update workspaces immediately upon creating a new template version, using <a href="https://coder.com/docs/v2/latest/templates/general-settings#require-automatic-updates-enterprise">Coder’s template update policy feature</a>.

f. Collect Coder audit logs and transmit them to your SIEM or SOC - <a href="https://coder.com/docs/v2/latest/admin/audit-logs#audit-logs">Audit logs</a> allow you to trace key events like users accessing Coder’s dashboard or workspace in the event of a compromised account or workspace. They are invaluable in incident response.

a. Run Coder in <a href="https://coder.com/docs/v2/latest/admin/high-availability">high availability</a> mode - Run multiple replicas of the Coder server, so in the event of one going down, the other replicas can continue serving dashboard traffic and workspace connections. This also allows upgrades to proceed without taking the Coder service offline.

b. Leverage Prometheus metrics to identify problems - Monitor the health of your Coder deployment and workspaces by querying and analyzing the platform’s <a href="https://coder.com/docs/v2/latest/admin/prometheus">Prometheus metrics</a>. These metrics provide time-series data on endpoint failures and resource utilization that will inform you of possible weaknesses in your network or infrastructure.

c. Implement a failover strategy - Think about the SLA you have in place for other developer tools, such as version control, and determine how much downtime is acceptable. Take into account potential infrastructure failures, and replicate your Coder server and database across regions and zones.

d. Take periodic database snapshots - Take snapshots of the Coder database on a cadence, and before every upgrade. This ensures that you can restore Coder to a known, stable state in case any issues arise. Make sure to store your templates in version control, so that if the database is lost, your templates can be pushed back into Coder seamlessly.

e. Run workspaces on scalable compute - Developer workspaces can demand large amounts of resources, especially when building or compiling code. In addition, there can be times where large numbers of workspaces are being requested. Leverage auto-scaling compute to meet these resource demands efficiently.

f. Run the Coder server on static compute - Ensure the Coder server is run on static compute to prevent end-users from being impacted. Alternatively, if Coder is run on dynamic compute and a scale down event occurs, dashboard and/or workspace connections may be dropped.

g. Enable multiple STUN servers - Coder’s networking uses STUN servers to learn about network address translation (NAT) between users and their workspaces to allow direct, encrypted tunnels. These direct tunnels generally have more stable latency and are resilient to Coder server or workspace proxy instances going down (either planned or unplanned). If users connect to workspaces over a corporate network or VPN, deploy two or more STUN servers inside the corporate network and configure Coder to use them.

h. Allow UDP traffic between users and workspaces - Coder’s direct, encrypted tunnels run over UDP on ephemeral ports. If firewalls block UDP then direct connections will not be possible and tunnels use Coder server and/or workspace proxies as relays. Such relays provide slower connections and consume server-side resources.

a. Keep workspaces close to users - To minimize connection latency (and improve the developer experience), deploy workspaces in the regions close to where the end-users are located.

b. Run workspace proxies near your users - The Coder server can proxy workspace connections, but not all of your end-users will be closely located to the region where it is run. Take advantage of workspace proxies to localize the connection proxying to both developer and workspace.

c. Run workspaces near your data and services - Where possible, deploy workspaces near your code repositories and data sources, to take advantage of lower latencies when cloning project repositories and downloading large data sets. Coder enables you to deploy workspaces in both your on-premise and public cloud infrastructure.

d. Run your database in the same region as the Coder server - Optimize database latency by keeping the Coder server close to the database, ideally in the same region. This will ensure a snappy user experience when navigating the dashboard, and interacting with workspaces, templates. For the best experience, keep latency under 10ms or less between Coder server and database.

a. Automate workspace shutoff - Prevent workspaces from running in perpetuity and running up your cloud bill. Enable <a href="https://coder.com/docs/v2/latest/workspaces#autostart-and-autostop">auto stop</a> to ensure workspaces are shut down after a specified period of inactivity. <a href="https://coder.com/docs/v2/latest/workspaces#autostop-requirement-enterprise">Enforce nightly/weekly shutdowns</a> to avoid continuous use of outdated workspaces.

b. Share compute across workspaces - When running Kubernetes-based workspaces, use the resource requests/limits to bin pack multiple workspaces on a single node to share compute and optimize cost. Software development workloads tend to have short bursts of resource utilization during compile and test, with longer periods of lower utilization while writing code. As such, the impact of sharing resources is negligible from a developer experience perspective.

c. Allocate resource quotas - Set <a href="https://coder.com/docs/v2/latest/admin/quotas">quota allowances </a>for your developer groups to control how many workspaces of a given template each user can create. Determine how much a particular resource costs, and define such costs on the template to count against the allocated quota.

d. Tag and label workspaces - Label and tag your workspace resources in the templates, so they can be filtered for costs in your cloud console. For example, you may want to label workspaces by business unit or use-case for chargeback purposes. This will give you greater insight into the efficiency of your workspaces, and you can leverage cloud-native billing solutions that are currently available on the market.

By leveraging Coder’s Well-Architected framework, enterprises will be able to provide their developer community with a highly secure and reliable cloud development environment platform. In addition, putting these best practices into practice will help you achieve your business objectives for improved developer productivity and information security.

Related Content:

<ul>
<li><a href="https://coder.com/ebooks-and-reports/reports/cde-adoption-report">The Cloud Development Environment Adoption Report</a></li>
<li> <a href="https://coder.com/blog/cde-adoption-report-cloud-development-environments-the-next-frontier-of-programmi">Cloud Development Environments: The Next Frontier of Programming Productivity</a></li>
<li> <a href="https://coder.com/ebooks-and-reports/reports/introducing-cdes-to-your-enterprise">Introducing CDEs to Your Enterprise</a></li>
</ul>

This framework provides design principles and architectural best practices for building and operating a highly reliable, efficient and scalable Coder deployment.

Coder's Well Architected Framework

Coder's  Well-Architected Framework

Encrypting network traffic with TLS has become a standard practice with more applications moving to the cloud. It is how many organizations secure their Coder instance when deploying on top of Kubernetes. This is usually accomplished by terminating TLS at the load balancer level. 

However, with the release of <a href="https://coder.com/blog/coder-v1-25">Coder for Docker</a>, the process to enable TLS is quite different, but just as important nonetheless. In this post, we’ll discuss how you can access your Coder for Docker deployment over HTTPS with a reverse proxy.

<h2>Understanding a reverse proxy</h2>

In some ways, a reverse proxy acts just like a <a href="https://www.hypr.com/proxy/">regular proxy</a>. It acts as a middleman, communicating with web servers on behalf of client machines. Yet, it comes with a few important caveats. 

First, instead of masking outgoing connections, a reverse proxy masks the incoming traffic. When provided with a URL, such as <a href="coder.com">coder.com</a>, the reverse proxy will handle where the request is taken, even with a multi-server configuration.

Second, a reverse proxy enables you to run services on a variety of ports, without having to expose those ports to a user-facing network. In this case, Coder for Docker runs on port 7080. By using a reverse proxy, you only need to open ports 80 (HTTP) and 443 (HTTPS) to have traffic routed to Coder.

<h2>How it works</h2>

In this example, we’ll make use of an <code>nginx</code> container to serve as the reverse proxy alongside the Coder container. We’ll also need to include our SSL certificate and key files in the <code>nginx</code> configuration file to enable TLS.

To get started, you&#39;ll need
- A machine with Docker Engine and Docker Compose installed
- A domain name
- An SSL/TLS certificate

If you don’t have a certificate, <a href="https://coder.com/docs/coder/latest/guides/tls-certificates/docker-tls#optional-step-1-validate-the-letsencrypt-dns">our documentation</a> covers how to procure one via LetsEncrypt. 

Running an <code>nginx</code> container requires you to have an <code>nginx.conf</code> file on the host machine. To account for this, we’ll create one locally and define the server name, ports, and headers. See an example below:

<pre><code class="yaml">worker_processes 1;

events {
 worker_connections 1024;
}

http {
 default_type application/octet-stream;
 map $http_upgrade $connection_upgrade {
 default upgrade;
 &#39;&#39; close;
 }

 server {
 listen 80;
 listen [::]:80;
 server_name &lt;your-domain.com&gt;;

 error_page 500 502 503 504 /50x.html;
 location = /50x.html {
 root /usr/share/nginx/html;
 }

 location / {
 proxy_pass http://coder:7080;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection &quot;Upgrade&quot;;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 }
 }

 server {
 listen 443 ssl;
 server_name &lt;your-domain.com&gt;;
 ssl_certificate /letsencrypt/etc/letsencrypt/live/&lt;your-domain.com&gt;/cert.pem;
 ssl_certificate_key /letsencrypt/etc/letsencrypt/live/&lt;your-domain.com&gt;/privkey.pem;
 ssl_session_cache shared:SSL:1m;
 ssl_session_timeout 5m;
 ssl_ciphers HIGH:!aNULL:!MD5;
 ssl_prefer_server_ciphers on;
 location / {
 proxy_pass http://coder:7080;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection &quot;Upgrade&quot;;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 }
 }

 sendfile on;
 keepalive_timeout 65;
 proxy_connect_timeout 90;
 proxy_send_timeout 90;
 proxy_read_timeout 90;
}

</code></pre>

Once the server configuration is set, we can define our multi-container application with Docker Compose. All that’s needed is a single <code>.yaml</code> file. Example below:

<pre><code class="yaml">version: ‘3’
services:
 nginx:
 container_name: nginx
 hostname: reverse
 image: nginx
 ports:
 - 80:80
 - 443:443
 volumes:
 - &quot;/nginx:/etc/nginx&quot;
 - &quot;~/letsencrypt:/letsencrypt/&quot;
 coder:
 hostname: coder
 image: codercom/coder:1.27
 container_name: coder
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 - ~/.coder:/var/run/coder
 ports:
 - 7080:7080
 environment:
 - DEVURL_HOST=*.your-domain.com
</code></pre>

A few things to note: first, we’ve defined the <code>ports</code> key to publish ports 80 and 443 on the host network. Second, we’ve added the <code>volumes</code> key to create a bind mount volume. This will mount our local directories of <code>/nginx</code> and <code>~/letsencrypt</code> into the nginx container. Both directories contain the nginx configuration and certificate files, respectively.

Now that we have our Docker Compose and <code>nginx</code> configuration files in place, we can start the containers! You’ll simply need to run <code>docker-compose up -d</code> to run both containers simultaneously. You should now be able to access your Coder instance from your domain.

For more detailed information on the steps above, see our <a href="https://coder.com/docs/coder/latest/guides/tls-certificates/docker-tls">documented guide</a>.

Learn how to configure TLS on Coder for Docker.

AI-native Development

Secure Environments for 2,500+ Developers

Eric Paulsen

Explore the latest from Eric

Why I Ditched OpenClaw and Built a More Secure AI Agent on Blink + Mac Mini

From Enterprise Search to Intelligent Agents: How Blink Enables Conversational AI at Scale

The Hidden Risks of AI in Engineering (And How to Get Ahead)

Why Cloud Development Environments Are Critical for Autonomous Driving Pioneers

Coder & Enterprise Chargeback Models

Coder's Well-Architected Framework

Deploying Coder with Docker and HTTPS

Related content

Using Claude Code with Coder Workspaces

Introducing Coder Agents

Self-Hosted Doesn’t Always Mean What It Implies