← Zurück zum Blog

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

August 3, 2026 · KI-Entwicklung · ca. 6 Min. Lesezeit

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

Ihr Team will OpenCode für PR-Reviews im privaten Netz — bleibt aber bei der Frage „Reichen 4GB VPS?“ hängen. Wir haben identische opencode serve + PR-Review-Workloads auf drei Linux-VPS (4/8/16GB) gemessen: Peak-RAM, Swap, End-to-End-Zeit. **Fazit: 4GB für leichte API-Reviews knapp; 8GB Team-Minimum; 16GB bei parallelen Multi-Repo-Reviews + MCP.**

Letzte Woche kam ein 12-köpfiges Backend-Team auf uns zu: Sie wollen OpenCode für PR-Code-Review im Firmennetz — kein GitHub Copilot Cloud-Review, Code-Diffs dürfen das private Netz nicht verlassen. Der Ops-Leiter legte drei VPS-Angebote auf den Tisch — 4 GB, 8 GB, 16 GB — und fragte: „Welche Stufe kaufen wir?"

Das ist keine „Was ist OpenCode?"-Frage, sondern: Wie viel Infrastruktur braucht ein selbst gehosteter Review-Service wirklich? Wir haben identische opencode serve + PR-Review-Workloads auf drei Linux-VPS (Ubuntu 22.04, 2 vCPU, nur RAM unterschiedlich) gefahren und Peak-RAM, Swap-Ereignisse und End-to-End-Zeit gemessen. Fazit vorweg:

  • 4 GB: persönliche Tests / leichte Single-Repo-Reviews — läuft, aber swap-intensiv
  • 8 GB: die Mindestlinie für tägliche Team-Reviews
  • 16 GB: parallele Multi-Repo-Reviews + MCP + lange Sessions — Produktions-Default

Was bei lokalem Deployment wirklich läuft

Viele denken, opencode serve sei nur ein leichter Web-Service — der Prozess selbst ist bescheiden (idle ~150–250 MB RSS). Aber bei Code Review führt der Agent eine Kette lokaler Operationen auf dem Server aus:

Operation Typischer Speicherverbrauch
git clone / git diff großer Repos 200 MB–1 GB (repo-abhängig)
LSP-Sprachserver (TypeScript, Go usw.) 300 MB–800 MB/Instanz
npm test / pytest Subprozesse 500 MB–2 GB
MCP-Server (filesystem, github usw.) 100 MB–500 MB/Instanz
SQLite-Session-DB (langfristiges Wachstum) bis 1–2 GB (#16729)

Server-Sizing geht also nicht um opencode serve --port 4096 allein — sondern um Peak-Speicher der Review-Subprozesse.

Zwei Deployment-Modi

OpenCode bietet zwei Self-Hosted-Einstiege (offizielle Doku):

opencode serve (Headless-API-Server)

OPENCODE_SERVER_PASSWORD=your-secret opencode serve \
  --hostname 0.0.0.0 \
  --port 4096
  • OpenAPI-3.1-Endpunkte (/doc für Swagger)
  • TUI-Clients verbinden via opencode attach http://host:4096
  • Ideal für CI-Webhook-Trigger und Team-Review-Gateways

opencode web (Browser-UI)

OPENCODE_SERVER_PASSWORD=your-secret opencode web \
  --hostname 0.0.0.0 \
  --port 4096
  • Öffnet automatisch Browser-UI
  • Gut für manuelles Einfügen von PR-Diffs
  • Produktion: Nginx/Caddy Reverse Proxy + HTTPS

Sicherheits-Baseline: OPENCODE_SERVER_PASSWORD immer setzen; 0.0.0.0 nie ohne Auth und Firewall ins Internet stellen.

Testumgebung

Punkt Spezifikation
VPS Drei Ubuntu 22.04, 2 vCPU, 40 GB SSD, 4/8/16 GB RAM
OpenCode 2026.7, verbunden mit Anthropic Claude Sonnet API
Test-Repos ① TypeScript-Monorepo (pnpm, ~120 Pakete) ② Go-Microservice (mit Docker Compose)
Review-Task Simulierter PR: Agent liest Diff → lint → Unit-Tests → Critical/Warning/Suggestion
Sampling 3 Läufe pro Szenario, Median; free -m + /proc/PID/status für Peaks

Drei-Stufen-RAM-Vergleich

Szenario S1: Leichter Single-Repo-PR (3 Dateien, keine Tests)

Config Peak-RAM Swap Review-Zeit
4 GB 2,1 GB leicht (~80 MB) 38s
8 GB 2,1 GB keiner 36s
16 GB 2,1 GB keiner 35s

4 GB gerade noch nutzbar — Swap bereits sichtbar.

Szenario S2: Mittlerer PR + lint + Unit-Tests

Config Peak-RAM Swap Review-Zeit
4 GB 3,8 GB stark (~1,2 GB) 2m 48s
8 GB 3,6 GB keiner 1m 12s
16 GB 3,6 GB keiner 1m 08s

4 GB verdoppelt die Latenz — 8 GB ist der Wendepunkt.

Szenario S3: Parallele 2-Repo-Review + MCP filesystem

Config Peak-RAM Swap Review-Zeit
4 GB OOM Kill — fehlgeschlagen
8 GB 7,2 GB häufig (~2 GB) 4m 15s
16 GB 6,8 GB keiner 2m 02s

8 GB läuft, aber ruckelt; 16 GB ist die Komfortzone.

Szenario S4: Lange Session (48 h durchgehend, 20+ Reviews)

Config Prozess-RSS SQLite-DB System-Swap
4 GB 1,4 GB 890 MB dauerhaft 2 GB+
8 GB 1,1 GB 1,2 GB 1,15 GB (entspricht #16729)
16 GB 980 MB 1,2 GB keiner

DB-Aufblähung ist ein gemeinsames Problem. Retention in opencode.json aktivieren:

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

4 GB: wann man es ertragen kann

Gut für:

  • Solo-Entwickler mit gelegentlichen kleinen PRs
  • Nur Cloud-API, keine lokalen Tests
  • 2–3× langsamere Reviews und gelegentliche OOM-Neustarts akzeptieren

Nicht gut für:

  • Gemeinsamer Team-Review-Server
  • MCP oder parallele Reviews
  • 24/7-Dauerbetrieb

Spartrick: 4-GB-VPS on-demand — bei PR-Webhook systemctl start opencode, nach Review herunterfahren. Günstiger als 24/7 mit 16 GB, aber Cold Start 15–30 Sekunden.

8 GB: Mindestlinie für kleine Teams

8 GB ist unsere Startempfehlung für die meisten Teams:

  • opencode serve + 1 LSP + vollständiger Single-Repo-Review-Flow parallel
  • Peaks typisch 5–7 GB, 1–2 GB für OS übrig
  • VPS monatlich ~12–24 $ (Hetzner, Vultr, DigitalOcean)

Beachten:

  • Parallele Review-Sessions auf 1–2 begrenzen
  • Wöchentlicher Neustart + DB-VACUUM
  • OPENCODE_DIAGNOSTICS=1 für Speichertrends

16 GB: Produktions-Default

Direkt 16 GB bei:

  • 3+ Entwickler teilen ein Review-Gateway
  • Parallele Reviews über 2+ Repos
  • MCP aktiv (GitHub, Jira, filesystem)
  • npm test / docker compose zur PR-Validierung nötig
  • 24/7 ohne häufige Wartung

16-GB-VPS ~24–48 $/Monat — um Größenordnungen günstiger als ein Teilzeit-Reviewer.

Neben RAM: was noch zählt

Dimension Empfehlung
CPU 2 vCPU Minimum; 4 vCPU für parallele Reviews
Disk 40 GB+ SSD; SQLite-DB und git clones brauchen Platz
Netzwerk HTTPS-Ausgang zu Modell-APIs; Eingang auf private IPs beschränken
OS Ubuntu 22.04 LTS oder Debian 12; Bun-Runtime in OpenCode enthalten
Backup Regelmäßige Backups von ~/.local/share/opencode/

Hybrid: VPS + Cloud-Mac

Bei iOS-/Xcode-Build-Validierung hilft kein Linux-VPS-RAM für xcodebuild. Zwei gängige Hybrid-Muster:

  1. Linux-VPS (8 GB) für opencode serve — allgemeines Code-Review
  2. Cloud-Mac-mini (16 GB+) für iOS-Reviews via MCP oder Webhook

Unser Claude-Code-RAM-Benchmark testete M4-Mac-mini-Stufen — OpenCodes Agent-Subprozess-Modell ähnelt Claude Code stark.

5-Minuten-Deploy-Checkliste

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

# 2. API-Key konfigurieren (env-file, nicht Klartext in der Kommandozeile)
cat > /etc/opencode.env <<'EOF'
ANTHROPIC_API_KEY=sk-ant-...
OPENCODE_SERVER_PASSWORD=your-strong-password
OPENCODE_SERVER_USERNAME=review-bot
EOF

# 3. systemd-Service erstellen
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. Starten
sudo systemctl enable --now opencode-serve

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

Schnelle Auswahl-Tabelle

Situation Empfehlung Monatlich
Solo, gelegentlich kleine PRs 4-GB-VPS (on-demand) 4–8 $
2–5 Personen, ein Repo 8-GB-VPS 12–24 $
5+ Personen, parallele Multi-Repo 16-GB-VPS 24–48 $
Inkl. iOS/Xcode-Review 16-GB Cloud-Mac-mini stündlich/monatlich
Hohe Compliance (Code on-prem) 16 GB on-prem + lokale Modelle Hardware einmalig

Fazit

Der Speicher-Engpass bei Self-Hosted OpenCode Review ist nicht opencode serve selbst — sondern die git-, LSP-, Test- und MCP-Subprozesse, die der Agent beim Review startet. 4 GB funktioniert, fühlt sich aber eng an; 8 GB ist die Team-Mindestlinie; 16 GB die wartungsarme Produktionswahl. Für iOS-Code-Review oder Xcode-MCP: Cloud-Mac-mini — mehr Linux-VPS-RAM löst xcodebuild nicht.

Sonderangebot →