Self-Hosted AI Coding Agent — Complete Guide

An AI coding agent becomes genuinely self-hosted only when more than its desktop interface runs on your hardware. For code to stay inside your environment, the application, model inference, embeddings, logs, tools, and repository must all remain behind your boundary. A safe deployment starts with an isolated test repository, a non-admin sandbox, restricted egress, a right-sized local model, and human approval for every consequential write.

Four deployment states people call “self-hosted”

1. Local application with a hosted model

The agent interface and tools run on your computer, but selected code and prompts travel to an API provider. This is local execution, not fully local inference.

2. Self-hosted application with a private endpoint

Your team operates the application and connects it to a model endpoint in a VPC, private cloud, or on-premises gateway. The data path can be tightly controlled, but it still depends on the endpoint's hosting and logging design.

3. Fully local inference

The application, model weights, embeddings, logs, and tools remain on owned hardware. Only this state justifies “code does not leave the environment,” and only after checking telemetry, crash reporting, package managers, connectors, and update services.

4. Air-gapped deployment

No network route exists. Images, packages, models, vulnerability data, and updates enter through an approved offline process. A local model with an active network connection is not air-gapped.

Reference architecture

Developer
   ↓
Eigent / coding-agent harness
   ↓
Policy and approval gate
   ↓
Sandboxed repository tools ── Git, tests, linters, scanners
   ↓
Private model endpoint ── local logs and evaluation store

Eigent's application repository is Apache-2.0. Its source quickstart may connect to Eigent cloud, while the repository points standalone users to a separate Local Deployment route (Eigent repository). Use and verify the standalone path when data isolation is the goal.

Other harnesses can fit different workflows. OpenHands offers an MIT-licensed core with Docker, VM, local, and cloud backends (OpenHands repository). Cline provides an Apache-2.0 IDE/CLI agent with approvals (Cline repository). Aider provides an Apache-2.0 Git-native terminal loop (Aider repository).

The open-source AI coding-agent comparison separates these harnesses by interface, maintenance status, deployment model, and approval design.

Choose an AI coding agent harness

Do not choose by interface alone. Validate how the tool scopes files, executes commands, stores prompts, sends telemetry, manages secrets, and records tool calls.

Size hardware from the workload, not a fake minimum

There is no honest universal “8 GB is enough” rule. Hardware depends on the model artifact, quantization, context length, concurrent agents, repository index, and required latency.

Ollama supports NVIDIA GPUs, Apple Metal, and an experimental Vulkan path. Its scheduler checks available VRAM, and its process view shows whether a model is on GPU, CPU, or split across them (Ollama GPU documentation, Ollama FAQ). For team serving, vLLM is a production-oriented option, but accelerator and image support change; use the current vLLM installation documentation.

Open weights do not guarantee laptop deployment. Kimi K2's official model card lists one trillion total parameters, illustrating how a downloadable model can still require substantial infrastructure (Kimi K2 model card).

A sandbox-first deployment procedure

1. Threat-model before installation

Classify source code, secrets, customer data, build artifacts, and logs. List who can start a task, which actions the agent may take, and what failure would be unacceptable.

NIST SP 800-218A extends secure software development guidance for generative AI and is aimed at producers and acquirers of AI systems (NIST). Use it as a governance reference, not as proof that a tool or deployment is “NIST compliant.”

2. Create an isolated runtime

Run the agent under a dedicated non-admin identity in a container or VM. Deny access to the home directory, SSH keys, cloud credentials, browser profiles, password managers, and production mounts.

OpenHands explicitly warns that an unsandboxed local agent has full filesystem access (OpenHands repository). That risk applies conceptually to any coding agent with shell authority.

3. Clone a synthetic test repository

Use code with no customer data or secrets. Mount only that directory. Add canary files outside the mount and verify the agent cannot read them.

4. Deploy the standalone application path

Follow the current Eigent Local Deployment documentation referenced by its official repository, not a cloud-connected quickstart (Eigent repository). Record the exact commit, images, dependencies, and configuration used.

5. Connect one local model

Choose a model that fits the measured hardware and task. Confirm process placement, latency, context handling, and output quality. Treat a hosted endpoint as a non-local quality baseline, clearly labeled.

6. Restrict network egress

Block outbound traffic, then observe what fails. Inspect DNS, update checks, telemetry, crash reporting, package managers, browser tools, MCP servers, and model downloads. Document every exception.

7. Create scoped tools

Start with read/write access to the repository and an allowlist of build, test, lint, and formatting commands. Deny deployment, identity changes, cloud administration, arbitrary package installation, and external messaging.

8. Add approval gates

Require approval for file writes, command execution, dependencies, network use, and any action outside the repository. Deterministic policy should block prohibited operations even if the model asks persuasively.

9. Run an evaluation set

Use the same tasks for every model and harness: bug fix, multi-file refactor, test creation, dependency update, code explanation, and refusal to alter out-of-scope files. Score correctness, test pass rate, review time, attempted boundary violations, latency, and cost.

10. Introduce secrets through a broker

Only after the synthetic evaluation passes should the agent receive narrowly scoped, short-lived credentials. Keep secrets outside prompts and logs. Prefer a broker that grants one action rather than a reusable administrator token.

Security risks unique to agentic coding

A 2026 security analysis highlights indirect prompt injection, confused-deputy behavior, and cascading failures in long-running agent systems, recommending sandboxing and deterministic controls for high-consequence actions (research paper). Coding agents are exposed to these risks through issues, README files, comments, dependency metadata, webpages, and tool output.

Controls should include:

• untrusted-content labels for repository and web text;
• strict separation between reading instructions and granting permissions;
• query, row, time, and output limits;
• allowlisted package registries and dependency review;
• immutable logs of prompts, tool calls, diffs, and approvals;
• human review before merge, release, or deployment;
• rollback through Git and reproducible environments.

Self-hosting reduces one external data boundary. It makes your team responsible for patching, runtime security, key management, monitoring, and incident response.

Extending the deployment to an air gap

An air-gapped agent needs more than a local inference checkbox.

1. Mirror approved container images, packages, model artifacts, and vulnerability data.
2. Verify hashes and signatures before offline import.
3. Maintain an inventory and software bill of materials.
4. Disable automatic updates, telemetry, and connectors that assume internet access.
5. Provide offline package and model registries.
6. Define a signed export path for patches and reports.
7. Schedule offline security updates and emergency revocation procedures.
8. Test that the environment has no route through DNS, proxies, management interfaces, or model tooling.

Air gaps increase update and operational burden. They do not eliminate insider risk, malicious dependencies, unsafe imported documents, or model errors.

Compliance and evidence

No self-hosted coding agent makes a team automatically compliant with GDPR, HIPAA, SOC 2, ISO 27001, export controls, or contractual confidentiality. Compliance depends on the deployment, people, policies, contracts, and evidence.

Document model and dataset licenses, the SBOM, access policy, approval matrix, log retention, backups, disaster recovery, vulnerability response, and rollback. Treat prompt and tool logs as potentially sensitive because they can contain source fragments and secrets.

When a hosted coding agent is better

Use a hosted agent when the team cannot operate model infrastructure, needs a mature remote environment, values vendor support, or can legally send the required context to the provider. A well-governed hosted service can be safer than a neglected self-hosted deployment.

Use self-hosting when data boundaries, source inspection, model choice, offline operation, or custom policy justify the engineering and security ownership.

Operate the AI coding agent boundary, not just the model

Eigent can provide the inspectable orchestration layer for a private coding workflow, but the sandbox, model runtime, permissions, logs, and update process determine whether it is truly self-hosted. Start with understanding a large codebase inside a synthetic repository and expand only after the controls hold. Download Eigent to begin the isolated evaluation.