OpenCode Review Self-Hosted Server Sizing: 4GB vs 8GB vs 16GB

Last week a 12-person backend team asked us to evaluate a setup: they want OpenCode for PR code review on their private network—no GitHub Copilot cloud review, code diffs must never leave the VPC. Their ops lead dropped three VPS quotes on the table—4GB, 8GB, 16GB—and asked which tier to buy.

This isn't a "what is OpenCode" question. It's about how much infrastructure a self-hosted review service actually needs. We ran identical opencode serve + PR review workloads on three Linux VPS instances (Ubuntu 22.04, 2 vCPU, RAM-only difference) and measured peak memory, swap events, and end-to-end latency. Bottom line first:

• 4GB: personal trials / single-repo lightweight reviews—works but swap-heavy
• 8GB: the minimum viable line for small-team daily reviews
• 16GB: parallel multi-repo + MCP + long sessions—recommended production default

What actually runs in a local deployment

Many assume opencode serve is just a lightweight web service—and the process itself is modest (idle ~150–250MB RSS). But when OpenCode performs code review, the agent executes a chain of local operations on the server:

Operation	Typical memory impact
git clone / git diff on large repos	200MB–1GB (repo-size dependent)
LSP language servers (TypeScript, Go, etc.)	300MB–800MB/instance
npm test / pytest subprocesses	500MB–2GB
MCP servers (filesystem, github, etc.)	100MB–500MB/instance
SQLite session database (long-term growth)	up to 1–2GB (#16729)

So server sizing isn't about opencode serve --port 4096 alone—it's about peak subprocess memory during review tasks.

Two deployment modes

OpenCode offers two self-hosted entry points (official docs):

opencode serve (headless API server)

OPENCODE_SERVER_PASSWORD=your-secret opencode serve \
  --hostname 0.0.0.0 \
  --port 4096

• Exposes OpenAPI 3.1 endpoints (/doc for Swagger)
• TUI clients connect via opencode attach http://host:4096
• Ideal for CI webhook triggers and team-wide review gateways

opencode web (browser UI)

OPENCODE_SERVER_PASSWORD=your-secret opencode web \
  --hostname 0.0.0.0 \
  --port 4096

• Opens a browser interface automatically
• Good for engineers pasting PR diffs manually
• Production: add Nginx/Caddy reverse proxy + HTTPS

Security baseline: always set OPENCODE_SERVER_PASSWORD; never expose 0.0.0.0 to the public internet without auth and firewall rules.

Test environment

Item	Spec
VPS	Three Ubuntu 22.04, 2 vCPU, 40GB SSD, 4/8/16GB RAM
OpenCode	2026.7, connected to Anthropic Claude Sonnet API
Test repos	① TypeScript monorepo (pnpm, ~120 packages) ② Go microservice (with Docker Compose)
Review task	Simulated PR: agent reads diff → runs lint → runs unit tests → outputs Critical/Warning/Suggestion
Sampling	3 runs per scenario, median values; free -m + /proc/PID/status for peaks

Three-tier memory comparison

Scenario S1: Single-repo lightweight PR (3 files changed, no tests)

Config	Peak memory	Swap	Review time
4GB	2.1 GB	light (~80MB)	38s
8GB	2.1 GB	none	36s
16GB	2.1 GB	none	35s

4GB is barely usable—swap already appearing.

Scenario S2: Medium PR + lint + unit tests

Config	Peak memory	Swap	Review time
4GB	3.8 GB	heavy (~1.2GB)	2m 48s
8GB	3.6 GB	none	1m 12s
16GB	3.6 GB	none	1m 08s

4GB doubles latency—8GB is the inflection point.

Scenario S3: Parallel 2-repo review + MCP filesystem

Config	Peak memory	Swap	Review time
4GB	OOM Kill	—	failed
8GB	7.2 GB	frequent (~2GB)	4m 15s
16GB	6.8 GB	none	2m 02s

8GB runs but stutters; 16GB is the comfort zone.

Scenario S4: Long session (48 hours continuous, 20+ reviews)

Config	Process RSS	SQLite DB	System swap
4GB	1.4 GB	890 MB	sustained 2GB+
8GB	1.1 GB	1.2 GB	1.15 GB (matches #16729)
16GB	980 MB	1.2 GB	none

Database bloat is a shared problem over time. Enable retention in opencode.json:

{
  "retention": {
    "days": 30
  }
}

4GB: when you can tolerate it

Good for:

• Solo developers reviewing their own small PRs occasionally
• Cloud API only, no local test execution
• Accepting 2–3× slower reviews and occasional OOM restarts

Not good for:

• Shared team review server
• MCP or parallel reviews
• 24/7 always-on service

Cost trick: use 4GB VPS on-demand—start systemctl start opencode on PR webhook, shut down after review. Cheaper than 24/7 16GB, but cold start takes 15–30 seconds.

8GB: small-team floor

8GB is our starting recommendation for most teams:

• Runs opencode serve + 1 LSP + full single-repo review flow concurrently
• Peaks typically 5–7GB, leaving 1–2GB for the OS
• VPS monthly cost ~$12–24 (Hetzner, Vultr, DigitalOcean tier)

Watch out for:

• Cap parallel review sessions at 1–2
• Weekly service restart + database VACUUM
• Set OPENCODE_DIAGNOSTICS=1 to monitor memory trends

16GB: production default

Go straight to 16GB when:

• 3+ engineers share one review gateway
• Parallel reviews across 2+ repos
• MCP enabled (GitHub, Jira, filesystem)
• Need npm test / docker compose to validate PRs
• 24/7 always-on without frequent maintenance

16GB VPS runs ~$24–48/month—orders of magnitude cheaper than a part-time human reviewer.

Beyond RAM: what else matters

Dimension	Recommendation
CPU	2 vCPU minimum; 4 vCPU for parallel reviews
Disk	40GB+ SSD; SQLite DB and git clones consume space
Network	Outbound HTTPS to model APIs; inbound restricted to private IPs
OS	Ubuntu 22.04 LTS or Debian 12; Bun runtime bundled with OpenCode
Backup	Regular backups of ~/.local/share/opencode/

Hybrid: VPS + cloud Mac

If reviews involve iOS / Xcode build validation, no amount of Linux VPS RAM will run xcodebuild. Two common hybrid patterns:

1. Linux VPS (8GB) runs opencode serve for general code review
2. Cloud Mac mini (16GB+) handles iOS-specific reviews via MCP or webhook

Our Claude Code RAM benchmark tested M4 Mac mini tiers in detail—OpenCode's agent subprocess model mirrors Claude Code closely, so conclusions transfer.

5-minute deploy checklist

# 1. Install OpenCode
curl -fsSL https://opencode.ai/install | bash

# 2. Configure API key (use env-file, not command-line plaintext)
cat > /etc/opencode.env <<'EOF'
ANTHROPIC_API_KEY=sk-ant-...
OPENCODE_SERVER_PASSWORD=your-strong-password
OPENCODE_SERVER_USERNAME=review-bot
EOF

# 3. Create systemd service
sudo tee /etc/systemd/system/opencode-serve.service <<'EOF'
[Unit]
Description=OpenCode Review Server
After=network.target

[Service]
EnvironmentFile=/etc/opencode.env
ExecStart=/usr/local/bin/opencode serve --hostname 127.0.0.1 --port 4096
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target
EOF

# 4. Start
sudo systemctl enable --now opencode-serve

# 5. Nginx reverse proxy (optional, add HTTPS)
# location /opencode/ { proxy_pass http://127.0.0.1:4096/; }

Quick sizing table

Your situation	Recommended	Monthly cost
Solo, occasional small PRs	4GB VPS (on-demand)	$4–8
2–5 person team, single repo	8GB VPS	$12–24
5+ person team, parallel multi-repo	16GB VPS	$24–48
Includes iOS/Xcode review	16GB cloud Mac mini	hourly/monthly
High compliance (code stays on-prem)	16GB on-prem + local models	one-time hardware

Conclusion

The memory bottleneck in self-hosted OpenCode Review isn't opencode serve itself—it's the git, LSP, test, and MCP subprocesses the agent spawns during review. 4GB works but feels cramped; 8GB is the small-team floor; 16GB is the low-maintenance production choice. If you also need iOS code review or Xcode MCP, look at cloud Mac mini—a bigger Linux VPS won't solve xcodebuild.