Self-Hosted Coding Agents: Architecture & Deployment

Your source code is probably the most sensitive asset your company owns, and most AI coding tools ask you to ship it over the public internet to a vendor’s servers before a single suggestion comes back. That’s fine for a weekend project. For a regulated codebase with internal package registries, VPN-only databases, and an audit team that wants a record of everything, it’s a non-starter. A self-hosted AI coding agent flips the model: it runs where your code already lives, inside infrastructure you control.

This guide covers what a self-hosted coding agent is, when to reach for a fully local open-source setup versus a platform you run in your own cloud, and how to deploy one inside your VPC without giving up governance or auditability.

What is a self-hosted AI coding agent?

A self-hosted AI coding agent is an autonomous system that reads, writes, and tests code entirely within infrastructure you own. The reasoning loop, the sandbox, and the connection to your repository all stay inside your network perimeter, and that guarantee is strongest when inference also runs on a model you host yourself rather than a commercial API.

An agent is not the same as a local model: running an open-weight model on a GPU box is just inference. An agent wraps that inference in an execution loop. Anthropic describes agents as systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks. The model proposes; the agent acts, observes the result, and tries again.

Self-hosting changes where every part of that loop runs: inference on an open-weight model on your own GPUs, or a provider API key routed through a gateway you control, while orchestration and sandboxing stay put. When teams search for the “best self-hosted AI for coding,” they’re really asking which setup keeps the whole loop, not just the model, inside the boundary they’re responsible for.

Why run a coding agent in your own cloud

The pitch for cloud-based assistants is real: zero infrastructure and instant onboarding. Teams still run the agent themselves because of three pressures a vendor abstraction can’t solve.

• Data control. Organizations under GDPR, HIPAA, or internal data-classification policies often can’t send proprietary source code to an external API at all. Running the agent in your own cloud keeps that decision, and the governance and audit trail behind it, in your hands, though it doesn’t guarantee compliance on its own.
• Access to internal systems. A hosted agent can’t reach your private artifact registry, VPN-only staging database, or SSO provider. One running inside your network can pull from your internal package mirror and run real integration tests against staging.
• Avoiding lock-in. Owning the deployment means owning the model choice, the sandbox type, and the network policy.

This is the framing behind running an agent in your own cloud rather than someone else’s. Our self-hosted deployment runs inside your own cloud account behind your VPC, on a single VM with no external services; your code, credentials, and data never leave your network. Self-hosting isn’t free: you trade someone else’s convenience for compute you provision and toolchains you patch, and the payoff depends on how sensitive your code is.

How a self-hosted coding agent works

The request-response cycle runs end-to-end inside your private network, whether the trigger is a Jira ticket or a Sentry alert.

1. Task ingestion. Work comes from a GitHub issue, a Linear ticket, a Slack command, or a direct API call.
2. Environment provisioning. The repo clones into a sandboxed environment over your internal network, using scoped, platform-managed credentials.
3. Code analysis. The agent reads the relevant files and loads any rule files defining your conventions, architecture, and test requirements.
4. Inference. It sends a structured prompt to a model, open-weight on your own GPU or commercial through an API gateway you control.
5. Generation and execution. The model returns code, the agent writes it to the sandbox, runs your tests, and iterates on failures for several cycles with no human in the seat.
6. Output. Once the change passes, the agent opens a pull request with the diff and description for a human to review.

The detail that makes this safe is isolation: every step runs inside a contained sandbox, so a destructive command from the model hits a disposable environment, not your host. The agent gaining “ground truth” from the environment at each step, as Anthropic puts it, is what separates a real agent from autocomplete.

Architecturally, this breaks into three layers: orchestration routes tasks and reacts to webhooks (a Sentry error opens a bug-fix task, a merged PR triggers a docs update), agent logic runs the plan-execute-verify reasoning and is model-agnostic by design, and the sandbox is where code actually runs, isolated and disposable. For the isolation tier, our write-up on building secure sandboxes with Docker and NixOS walks through the container-versus-VM tradeoffs.

Open-source vs. self-hosted platform: when each fits

“Self-hosted” covers two different setups, and conflating them is where buying decisions go wrong: a fully local, open-source toolchain you assemble yourself, or a platform you run in your own cloud that handles orchestration, isolation, and governance for you. Both keep code in your environment; they diverge on everything above the model.

The open-source route gives you maximum control and no licensing cost, at the price of integration work:

• Tabby is an open-source, self-hosted coding assistant that runs as a server, loads a code model, and serves completions over HTTP to IDE plugins, with an agent mode added since.
• OpenCode is a terminal-native coding agent that reads and edits files, runs shell commands, and connects to many model providers, including local endpoints you host yourself.
• Aider is a terminal-based AI pair-programming tool that edits your local git repo from the command line and connects to OpenAI, Anthropic, or self-hosted models via an OpenAI-compatible API. No GUI, no cloud mode.

These shine for one developer at their editor with a model on local hardware. They get heavier above a single repo, where multi-repo coordination, event triggers, SSO, and a shared audit trail become the job, and that's the gap a self-hosted platform fills.

We sit in the right-hand column. We support multiple coding-agent harnesses and models, so you can run Claude Code, Cursor, Codex, or OpenCode against your repos and swap them per task, while orchestration, sandboxing, and audit stay consistent underneath. A single engineer wanting local completions is better served by an open-source tool; a security team logging every agent action across forty repositories is where the platform tier earns its keep.

Governance, Audit, and Control

Keeping code on-premises is necessary but not sufficient. A network boundary stops your code from leaving, but tells you nothing about what an agent did inside it at 3 a.m. on a Saturday.

Governance is the difference between “the code stayed in our network” and “we can prove what the agent changed, where, and on whose authority.” Three controls do most of the work:

• An audit trail of every agent action: the commands run, the files read, the model calls made, not just the final PR. Our self-hosted deployment pairs that trail with SSO through your identity provider, so agent runs share the same access model as the rest of your stack.
• Human approval gates. The agent proposes a change as a pull request; a person still merges it. The plan-execute-verify loop ends at a diff, not in production.
• Scoped, least-privilege access. The sandbox gets exactly the credentials a task needs and nothing more, so a misbehaving run cannot reach beyond its lane.

This is where the orchestration layer does more than schedule jobs: it enforces who can trigger what and how results get reviewed. The NIST AI Risk Management Framework offers a vocabulary for the govern, map, measure, and manage functions that an audit trail and approval gates are meant to satisfy.

How to Deploy a Self-Hosted Coding Agent in Your VPC

Once you’ve settled on the platform tier, deployment is more about wiring than infrastructure heroics. Our self-hosted option runs on a single VM within your own cloud account, the same way it does on AWS and Azure today, with GCP in early access.

Step 1: Stand up the deployment in your cloud. We run as a single process on a single VM behind your VPC, with no external services to manage, and then wire in SSO via your identity provider (Okta, Microsoft Entra ID).

Step 2: Connect your Git provider. Point the agent at GitHub, GitLab, or Bitbucket, all supported as Tembo integrations, with read and write access scoped to the repositories you select.

Step 3: Bring your own keys. Configure the model providers you want with your own API keys, or point to open-weight models you host. Because we’re model-agnostic, you can run different harnesses and models per task instead of committing to one.

Step 4: Write a rule file. Add a tembo.md file, our rule and context file, to each repo root with build commands, test commands, and security guardrails:

# Project Context
Python 3.12 FastAPI service with PostgreSQL.

## Commands
- pip install -r requirements.txt
- pytest --cov=app tests/
- ruff check .

## Security
IMPORTANT: Never hardcode secrets or API keys.
IMPORTANT: All SQL must use parameterized queries.

Notice the Security block: rule files aren’t just build instructions; they’re where you encode the guardrails the agent must follow on every run, not just the first.

Step 5: Run in an isolated sandbox. Every automation run executes in its own sandbox, with container- or VM-level isolation depending on how much system access a task needs. A destructive command stays contained there, though scope secrets and network rules tightly, since blast radius still depends on egress and what internal services the sandbox can reach.

Step 6: Set up automations and test small. Define automations that trigger on events or schedules: a PR-review run on every pull request, a weekly dependency scan, a bug-fix run when Sentry flags a new error. Start with one low-risk issue and tighten the rules as you go.

Because each run is event-driven and isolated, you can grow from “fix this one ticket” to “review every PR across the org” without changing the security model. Automated PR review is a common first workflow; our guide to AI code review tools covers how it fits into the rest of your pipeline.

Challenges and Maintenance Considerations

Self-hosting is an ongoing commitment, not a one-time install. Going in clear-eyed about the costs keeps the project from stalling six months in.

• Compute scales with usage. Every task spins up a sandbox, clones a repo, installs dependencies, and runs tests, and large monorepos with heavy suites burn real CPU and memory, so right-sizing is a recurring task.
• Model evaluation matters as much as upgrades. A newer model can write better code or quietly regress in a domain you care about, so test new versions against a representative task set first.
• Patching and drift are now yours to manage. Runtimes, dependencies, and custom Nix shells need versioning and testing on a cadence. Coding standards change too, so stale tembo.md files quietly enforce last year’s conventions; review them quarterly and keep any internal-registry or staging-database access scoped to the least privilege.

Conclusion

Self-hosting an AI coding agent is a bet that control is worth more than convenience, and for any team with real compliance pressure, it usually is. The question isn’t whether to keep code in your network; it’s which tier does the job: a local open-source toolchain for editor-level work, or a platform you run in your own cloud for orchestration, governance, and an audit trail across the team.

If you’re weighing the platform route, our self-hosted deployment runs supported coding-agent harnesses inside your own VPC, model-agnostic and fully audited, with hands-on help to stand it up. Start on the free tier with a $10 one-time usage allowance on one repository and the option to add prepaid balance anytime, or book a demo to talk through an air-gapped or VPC deployment with your security team.

Frequently asked questions

What is a self-hosted AI coding agent? It’s an autonomous coding system whose full loop, reasoning, sandboxed execution, and repo access run inside infrastructure you own, so source code never leaves your environment unless you explicitly route it out.

What is the best self-hosted AI for coding? It depends on the scope. For one developer who wants local completions or terminal-driven edits, open-source tools like Tabby, Aider, or OpenCode that run against a model on your own hardware fit well. For a team that needs multi-repo orchestration, SSO, and a central audit trail, a self-hosted platform is a better fit.

Can a self-hosted coding agent run air-gapped or in a VPC? Yes. The defining trait of self-hosting is that the agent runs within your network, whether that’s a VPC in your cloud account or a fully isolated network environment. Our deployment runs on a single VM behind your VPC, on AWS and Azure today, with GCP in early access.

Is self-hosting more secure than a cloud coding assistant? It removes one risk by keeping code off a vendor’s servers, but it doesn’t remove the need for governance. Audit trails, approval gates, and least-privilege sandboxing are what turn a network boundary into an actual control.