Self-hosted AI coding assistants: a complete Goatfied deployment guide

A practical guide to self-hosting Goatfied — architecture, model routing, network and data controls, and the tradeoffs between self-hosted and managed for security-sensitive teams.

For a lot of teams, "we'd love to use an AI coding assistant" runs straight into "…but our code can't leave our network." Self-hosting is the answer, and it's a first-class option in Goatfied rather than an afterthought. This guide walks through how a self-hosted deployment is structured, the controls it gives you, and how to decide between self-hosted and managed.

Self-hosted vs managed: the honest tradeoff

Neither is universally right. The decision usually comes down to where your constraints are:

**Choose self-hosted** when code residency, network isolation, or a compliance boundary means source and prompts must stay inside your perimeter, and you have the ops capacity to run it.
**Choose managed** when you want the fastest path to value and your security posture allows a trusted vendor boundary. You trade some control for zero infrastructure work.

Goatfied supports both with the same product surface, so the choice is about operations and policy, not features.

Architecture of a self-hosted deployment

A self-hosted Goatfied deployment has three layers you operate:

1. **The editor / client** — where engineers work. It talks only to your control plane, never to third-party endpoints you haven't allowed.

2. **The control plane** — orchestrates the agent loop: planning, retrieval, validation, and PR creation. This is where policy lives.

3. **Model routing** — the control plane routes inference to the model backends _you_ configure: a self-hosted open-weights model, a private cloud endpoint, or an approved vendor API. Nothing is hard-wired to a single provider.

Because the agent loop, retrieval, and validation all run inside your boundary, source code and prompts don't traverse anything you haven't explicitly permitted.

Network and data controls

The controls that matter for a security-sensitive team:

**Egress allowlisting.** The control plane only reaches the model backends and services you configure. Default-deny egress is the safe posture.
**Data residency.** Repositories, transcripts, and command logs stay on infrastructure you own. The audit trail — branch, transcript, command log per run — lives in your environment.
**Secrets isolation.** Model credentials and repo tokens live in your secret store, injected at runtime, never baked into images or logs.
**Policy controls.** Explicit verification steps and gate requirements (compile, lint, test) are enforced centrally, so autonomous execution stays within the rules you set.

A reference deployment shape

A common, boring-in-a-good-way setup:


[ Engineers ] --> [ Goatfied control plane (in-VPC) ]

                          |  routes inference to:

                          +--> self-hosted open-weights model (GPU nodes), and/or

                          +--> approved private/vendor model endpoint

                          |

                          +--> [ your Git host + CI ] (in-perimeter)

Run the control plane in your VPC/cluster.
Give it egress only to the model backend(s) and your Git/CI.
Point model routing at whichever backends your policy allows — you can mix a private open-weights model for sensitive repos with an approved API for the rest.

Operational checklist

Before you roll it out:

[ ] Control plane deployed inside your network boundary.
[ ] Egress default-deny, with an explicit allowlist for model + Git/CI endpoints.
[ ] Model backend(s) configured and health-checked.
[ ] Secrets sourced from your vault, not the image.
[ ] Compile/lint/test gates defined so the agent loop can't mark unvalidated changes "done."
[ ] Audit log retention (branches, transcripts, command logs) wired to your logging stack.
[ ] Rollback path tested — small, reversible diffs are only useful if you've verified the revert flow.

Why the compile-first design helps security teams

Self-hosting protects your data; the agent loop protects your `main`. Because every change is gated on compile, lint, and targeted tests and carries a full transcript, a self-hosted Goatfied gives security and platform teams something they rarely get from AI tooling: automation that's both _inside the perimeter_ and _auditable by construction_. You can answer "what did the agent do, and why did it pass?" from the logs, not from trust.

The takeaway

Self-hosting an AI coding assistant isn't just about keeping code in-network — it's about keeping the whole workflow, including its audit trail, under your control. Goatfied is designed so the editor, control plane, retrieval, and validation all run where you decide, with model routing you own. For teams whose main blocker has been "the code can't leave," that's the difference between "no" and "yes, with controls."

[The Goatfied agent loop: how we ship code that compiles first try](/blog/goatfied-agent-loop-compiles-first-try)
[Why we open-sourced Goatfied (and what we kept proprietary)](/blog/why-we-open-sourced-goatfied-and-what-we-kept-proprietary)