Self-Hosting and Data Control

What changes when you self-host

When you use a managed (closed-source) coding agent, every interaction flows through the vendor's servers: the task description, your codebase context, the model's reasoning, the files it creates. The vendor sees all of it (or at least has the ability to). They might log it, analyze it for usage patterns, or use it to improve their service.

When you self-host OpenCode, the flow is different. The OpenCode agent itself runs on your infrastructure. Your code doesn't leave your network (unless you explicitly send it to an LLM provider). Your task descriptions and the agent's reasoning stay local. The only thing that might leave your network is the actual model call—if you're using Claude via the Anthropic API, for example, you send the prompt to Anthropic and get back a response. But you control exactly what goes into that prompt and what you do with the response.

Three self-hosting patterns

Pattern 1: Self-hosted agent + managed model provider (most common)

You run OpenCode on your machine or your server. When it needs to call a model, it calls Anthropic's API or OpenAI's API over the internet. Your code and reasoning stay local. The model prompts (which may contain snippets of your code for context) go to the provider's servers.

This is the most common pattern because it's the easiest: you don't have to manage or fine-tune a large language model. You get a sophisticated, production-ready model (Claude, GPT-4, etc.) via API. The tradeoff is that the prompts you send to the API contain your code context.

Pattern 2: Self-hosted agent + self-hosted model (maximum privacy)

You run OpenCode on your infrastructure. You also run a local LLM (Ollama, vLLM, or another inference server) on the same machine or internal network. Prompts never leave your network. Your code is never seen by any external service.

This is the most private approach, but it requires managing a language model. If you're using Llama 2 or Mistral locally, you get lower latency and full privacy, but often lower code-reasoning quality than Claude or GPT-4. And you have to maintain the model server.

Pattern 3: Hybrid (code stays local, reasoning goes to cloud)

You run OpenCode locally. But before sending a prompt to the model provider, you strip out sensitive information—secrets, certain file paths, proprietary algorithms. You send a sanitized version to the cloud model, get back code suggestions, then apply them locally.

This is a middle ground: better privacy than sending raw code context, but not as private as keeping everything local. Useful if you're required to protect certain information but okay sending most of your code to an external API for reasoning.

Self-hosting on your laptop: the fastest way to start

The easiest self-hosting setup is running OpenCode on your development machine:

git clone https://github.com/sst/opencode.git
cd opencode
npm install

Then configure it to use a local model with Ollama:

OPENCODE_PROVIDER=ollama
OPENCODE_MODEL=llama2-13b
OLLAMA_BASE_URL=http://localhost:11434

Or configure it to use a cloud provider:

OPENCODE_PROVIDER=anthropic
OPENCODE_MODEL=claude-3-5-sonnet-20241022
ANTHROPIC_API_KEY=${your_key}

Run it:

npx opencode "add a dark mode toggle to the settings page"

That's it. Your code stays on your machine. The agent runs on your machine. The only thing that leaves is the prompt to the model API (if using a cloud provider).

Self-hosting in production: deployment patterns

For teams or CI/CD pipelines, you'd run OpenCode on a server. Common setups:

Docker container in Kubernetes. Package OpenCode in a container, deploy it to your Kubernetes cluster. The container can be restricted to a specific namespace and RBAC role, so it only has access to the code repositories you specify. The container can pull its credentials (API keys, SSH keys to access your repos) from your secrets manager.

EC2/VM with a systemd service. Run OpenCode as a service on a VM. Use IAM roles (AWS) or managed identities (Azure) to grant it access to your code repositories and secrets manager. Configure it to pull code from GitHub/GitLab via SSH keys.

GitHub Actions / GitLab CI integration. Run OpenCode as a step in your CI/CD pipeline. This is useful for automating code generation or fixes as part of your build process.

In any of these setups, the key is: OpenCode runs somewhere you control, has access only to the repositories and permissions you grant, and communicates with the outside world only as configured.

What data stays local vs. what goes to the provider

If you're using self-hosted OpenCode with a cloud model provider (the most common pattern):

Stays local:

• Your entire codebase (unless you explicitly send it to the model)
• Task descriptions and feedback you give OpenCode
• The agent's internal reasoning (intermediate thoughts, attempted file modifications)
• Git history and branch information

Goes to the model provider:

• The prompt you send to call the model (which includes context like file snippets, recent changes, test failures)
• The model's response (reasoning and tool calls)

If you use a local model instead:

Stays local:

• Everything above, plus the prompts and responses (because the model is local)

Goes nowhere:

• Nothing leaves your network

The compute cost of self-hosting

Self-hosted models (Ollama, vLLM) run on your hardware. This means:

• No API costs per token. You pay for the model inference once when you set it up, not per request.
• Compute costs on your machine. A 13B parameter model needs significant RAM and (ideally) GPU. Running Llama 2 13B locally might use 16-32 GB RAM and is much faster with a GPU (which costs).
• Longer response times. Local models are slower than cloud APIs. A task that takes 10 seconds with Claude might take 2 minutes with Llama 2 on a laptop.

For low-frequency use (a few tasks per week), a local model is fine—the slower speed is worth the privacy. For high-frequency use (many tasks per day in CI/CD), cloud APIs are often faster and the cost is usually lower than running large GPUs locally.

A concrete example: compliance-driven self-hosting

A financial services company has strict data residency requirements: code cannot leave their data center. They choose:

• Run OpenCode on an internal Linux server
• Run a vLLM instance on the same server with a fine-tuned Mistral model
• Configure OpenCode to use that local vLLM instance
• OpenCode has read-only access to specific Git repositories
• All prompts and model responses stay on the internal network

The tradeoff: slower code generation than using Claude API (vLLM is faster than local Ollama, but slower than cloud), and they have to maintain the vLLM server and fine-tune the model for their codebase. But zero data leaves the building—compliance requirement met.

Common mistake

Thinking self-hosting is always better because "your data stays local." If you use self-hosted OpenCode with Claude API, your code context (snippets of your codebase sent as prompt context) is still going to Anthropic. Self-hosting the agent isn't the same as self-hosting the model. If privacy from the model provider is the goal, you need to self-host both the agent and the model, which is more expensive and slower. Know what you're trading off.