Hogyan vidd magaddal az AI kódoló asszisztensedet ingázás közben — biztonságosan
Ha valaha ültél már buszon vagy vonaton azon gondolkodva, hogy "de jó lenne most gyorsan ránézni arra a bugra", ez a poszt neked szól. Bemutatom, hogyan futtathatsz egy OpenCode szervert egy VPS-en (vagy otthoni gépeden), és hogyan érheted el biztonságosan telefonról — anélkül, hogy a laptopodat magaddal kellene cipelned, vagy a kódodat és API kulcsaidat kockáztatnád a nyílt interneten.
Az OpenCode egy nyílt forráskódú, terminálalapú AI kódoló asszisztens — gondolj rá úgy, mint egy önhosztolható alternatívára a zárt, felhő alapú kódoló agentek mellett. A lényege a kliens-szerver architektúra: az opencode serve paranccsal elindítasz egy headless HTTP szervert, ami REST API-t (OpenAPI 3.1 specifikációval) és streamelést biztosít. Ehhez a szerverhez különböző kliensek csatlakozhatnak — a beépített terminál UI (TUI), egy webes felület, vagy egy natív mobilalkalmazás.
Ez a szétválasztás a kulcs: a nehéz munka (repó elérés, tool végrehajtás, modellhívások, fájlkezelés) a szerveren történik, a kliens csak megjeleníti és vezérli azt. Így a szerver akár egy VPS-en vagy egy otthoni gépen fut 24/7, te pedig bármilyen eszközről — akár egy telefonról — csatlakozhatsz hozzá.
Fontos tisztázni: maga a nyelvi modell (Claude, GPT, stb.) nem a te szervereden fut, hanem a szolgáltató (pl. Anthropic) infrastruktúráján — az OpenCode csak a kéréseket közvetíti oda és vissza. Ez azt jelenti, hogy a hardverigény jóval szerényebb, mintha helyben futtatnál egy nagy nyelvi modellt.
Kétféleképpen érheted el a futó szervert:
1. Böngészőn keresztül (opencode web)
Ez elindítja az API szervert és egy beépített webes felületet egyszerre. Ha a szerver publikusan elérhető (a lentebb tárgyalt biztonsági rétegekkel), egyszerűen megnyitod a telefon böngészőjében az URL-t, és ugyanabba a sessionbe csatlakozol, amit korábban a gépeden nyitottál. Nincs szükség appra, nincs SSH — csak egy böngészőlap.
2. Natív mobilalkalmazás
Léteznek dedikált mobilkliensek (Android / iOS), amik közvetlenül az OpenCode API-hoz csatlakoznak. Ezek jellemzően többet tudnak, mint egy böngészős nézet: session lista, streamelt chat, inline diff nézet a kódváltozásokhoz, és tool-hívások jóváhagyása egy koppintással. A kapcsolati adatokat (szerver cím, felhasználónév, jelszó) az app biztonságosan tárolja, és biometrikus feloldást is be lehet kapcsolni küldés előtt.
Bármelyiket választod, a kliens vékony réteg marad — a kódod, a fájljaid és az API kulcsaid mindvégig a szerveren maradnak, nem a telefonon.
Ne futtasd az OpenCode szervert root-ként, és lehetőleg ne is a saját, mindenre jogosult felhasználódként. Hozz létre egy dedikált, korlátozott jogú Linux usert kifejezetten erre a célra:
sudo useradd -m -s /bin/bash -d /home/opencode opencode
sudo -u opencode -iEnnek az az előnye, hogy ha valami visszaél a szerverrel (akár egy rosszul konfigurált tool-hívás, akár egy biztonsági rés), a kár a opencode user jogkörére korlátozódik — nem fér hozzá a rendszer többi részéhez, más felhasználók home mappájához, vagy rendszergazdai funkciókhoz.
Két dolgot kell nézni: a CPU utasításkészletet és a memóriát. Az előbbi a nagyobb buktató: az OpenCode Bun alapú, a Bun pedig előfeltételként AVX-támogatást követel a CPU-tól — enélkül a folyamat el sem indul (részletek a VPS-elvárások szekcióban).
Memória. Mivel a modell-inferencia a szolgáltató szerverén fut, nem nálad, maga a folyamat viszonylag szerény — de nem annyira, mint sok forrás állítja. Saját mérés szerint az OpenCode 1-1,5 GB RSS-t foglal le már alapállapotban is. A terhelést ezután az emeli, amit körülötte futtatsz: nyelvi szerverek (LSP) a projektedhez, tesztek futtatása, git műveletek, nagyobb repók indexelése.
Egy hordozható, telefonról vezérelt use case-hez (nem build szerverként, hanem könnyű, alkalmi vezérlésre) a 2 vCPU / 4 GB RAM ajánlás most már nem becslés, hanem a mért igényre szóló, bőven elegendő tartalék. Ha szorosan akarod méretezni: legalább ~2 GB szabad RAM kell a folyamatnak, és ne olyan gépen futtasd, ami már 80% felett van terhelve. Tárhelyből 20-40 GB bőven elég OS + OpenCode + néhány aktív repó + logok mellé — feltéve, hogy nem tárolsz nagy adathalmazokat vagy build artifactokat ugyanott.
Fontos: a korábban keringő "512 MB elég" számok valótlannak bizonyultak — a mért valóság ~1,2-1,7 GB RSS. Ha pontos képet akarsz a saját munkaterhelésedről, futtasd egy hétig a szervert, és figyeld a free -h / df -h kimenetet.
A fenti számok nem elméletből születtek: élesben futtattam az OpenCode szervert egy 1 vCPU / 1,9 GB-os KVM VPS-en, és a következő kemény tanulságokat szedtem össze.
1. CPU: az AVX-támogatás nem alku tárgya. A Bun nem indul el olyan CPU-n, ami nem támogatja az AVX utasításokat. A tesztgépen (QEMU 2.5 virtuális CPU modell, csak SSE/SSE2) a folyamat egyből összeomlott:
CPU lacks AVX support. Please consider upgrading to a newer CPU.
panic(main thread): Segmentation fault
oh no: Bun has crashed.A grep -o -m1 avx /proc/cpuinfo üres eredménye egyértelmű jel: az OpenCode (és általában a Bun-alapú eszközök) nem fog futni. KVM-es VPS-eknél ez gyakran a virtuális CPU-modell beállításán múlik: az alapértelmezett qemu64-szerű modell csak SSE-ig engedi a vendéget, hiába támogatja a fizikai host (esetünkben AMD EPYC) az AVX/AVX2-t. Ilyenkor a hypervisoren host CPU passthrough kell (-cpu host), és a vendég újraindítása. Előfizetés előtt ellenőrizd, hogy a lscpu | grep -i flags kimenetében ott van-e a sse4_2, avx, avx2.
Érdekesség: az OpenCode hivatalosan is kínál "baseline" (nem-AVX) buildet (opencode-linux-x64-baseline.tar.gz), és a tiszta baseline Bun önmagában futott is a régi CPU-n — de maga a baseline OpenCode bináris ugyanúgy összeomlott. Ne alapozz a baseline buildre nagyon régi CPU esetén.
2. Memória: 1-1,5 GB RSS, ez nem alku tárgya. Mérés szerint az OpenCode már a --version parancsnál is ~1,2-1,7 GB RSS-t foglalt le; a közösségi beszámolók is egybevágnak ("needs 1GB of ram or more" — egy 512 MB-os VPS-en OOM-mal halt meg). Ha a gépeden csak néhány száz MB szabad RAM van, a folyamat állandóan thrash-elni fog.
3. A swap nem menti meg. A tesztgépre 6 GB swapet is tettem — nem segített: a folyamat 1,2-1,5 GB RSS-sel percek alatt sem végzett el egy triviális parancsot, közben százezres nagyságrendű page fault keletkezett, és a gép "elérhető memóriája" 60-100 MB-ra esett. A swap a rövid, átmeneti csúcsokra jó, de egy tartósan nagy munkakészletet nem tud ellátni. Ráadásul ha más szolgáltatások is futnak a gépen (levél, monitoring, konténerek), az OpenCode akár az összes szabad RAM-ot elhasználja, és az OOM-killer idegen folyamatokat is kilőhet.
4. Gyakorlati ellenőrzőlista OpenCode-ra szánt VPS-hez:
grep -o -m1 avx /proc/cpuinfo → legyen találat (illetve sse4_2, avx2 a flags között)free -h → legalább ~2 GB szabad RAM a folyamatnak; kerüld a 80% felett terhelt gépeketMielőtt rátérnénk a futtatásra, érdemes szót ejteni arról, honnan jön a modell, amit az OpenCode meghajt. Az
OpenCode Zen
az OpenCode csapata által üzemeltetett, kurátorolt modell-gateway: egyetlen API kulccsal (OPENCODE_API_KEY, alias OPENCODE_ZEN_API_KEY) érsz el 30+ tesztelt, coding agentekhez optimalizált modellt (Claude, GPT, Gemini, Qwen, DeepSeek, stb.) — nem kell minden szolgáltatónál külön regisztrálni és kulcsot kezelni.
Ezen belül van egy jelenleg érdekes opció: a Big Pickle . Ez egy "stealth" (nem hivatalosan közölt eredetű) reasoning modell, amit az OpenCode csapat egy visszajelzés-gyűjtő időszak alatt ingyenesen kínál — a közösségi konszenzus szerint valószínűleg egy GLM-4.6 alapú modellről van szó, kb. Claude Sonnet 4.5/4.6 szintű kódolási teljesítménnyel, 200K context ablakkal. Ingázós, könnyű vezérlésű használatra kifejezetten praktikus alapértelmezett választás, amíg az ingyenes időszak tart.
Két dolgot érdemes szem előtt tartani vele kapcsolatban:
A konfigban egyszerűen opencode/big-pickle modellazonosítóval hivatkozhatsz rá, az OpenCode Zen providerén keresztül.
Akár OpenCode Zen-t, akár közvetlenül Anthropic/OpenAI kulcsot használsz, a kulcsot nem szabad a kódba vagy verziókezelt configba írni. Két gyakorlati megoldás:
systemd esetén — a korábbi unit fájlban már szerepel az Environment= direktíva, de nagyobb, több kulcsot tartalmazó setuphoz jobb egy külön, szűk jogosultságú fájlt használni:
# /etc/opencode/opencode.env — csak az opencode user olvashassa
sudo mkdir -p /etc/opencode
sudo tee /etc/opencode/opencode.env > /dev/null <<'EOF'
OPENCODE_SERVER_USERNAME=your-user
OPENCODE_SERVER_PASSWORD=change-me-strong-password
OPENCODE_API_KEY=your-opencode-zen-key
EOF
sudo chown opencode:opencode /etc/opencode/opencode.env
sudo chmod 600 /etc/opencode/opencode.env# /etc/systemd/system/opencode.service
[Service]
...
EnvironmentFile=/etc/opencode/opencode.env
ExecStart=/usr/bin/opencode serve --hostname 127.0.0.1 --port 4096sudo systemctl daemon-reload
sudo systemctl restart opencodeDocker Compose esetén — env_file-lal ugyanez a minta, a .env-et pedig ki kell zárni a git repóból (.gitignore):
# docker-compose.yml
services:
opencode:
image: opencode-image
restart: unless-stopped
command: opencode serve --hostname 0.0.0.0 --port 4096
env_file:
- ./opencode.env
ports:
- "127.0.0.1:4096:4096"
volumes:
- ./projects:/projects
deploy:
resources:
limits:
memory: 4G
cpus: "1.5"# opencode.env — ugyanaz a tartalom, mint fentebb
echo "opencode.env" >> .gitignore
docker compose up -dMindkét esetben a lényeg ugyanaz: a titkos érték egy fájlban él, amit a rendszer szintjén (fájljog, .gitignore) védesz, nem pedig a parancssori argumentumokban vagy a repóban — a parancssori argumentumok ugyanis simán megjelennek a ps aux kimenetében is, ami egy megosztott gépen extra kockázat.
Mindkettő jó megoldás arra, hogy a szerver a géped/VPS-ed újraindítása után is automatikusan elinduljon, és a folyamat összeomlása esetén újrainduljon. Íme egy rövid összevetés:
| Szempont | systemd service | Docker |
|---|---|---|
| Erőforrás-korlátozás | systemd unit direktívákkal (MemoryMax, CPUQuota) |
docker run flag-ekkel (--memory, --cpus) |
| Elszigeteltség | Csak a dedikált Linux user szintjén | Teljes konténer-szintű izoláció (fájlrendszer, hálózat) |
| Egyszerűség | Kevesebb mozgó alkatrész, natív Linux eszköz | Extra réteg (image build, konténer élettartam-kezelés) |
| Frissítés | npm update + service restart |
Új image build + konténer csere |
Ha egyszerűségre és minimális overheadre törekszel egy dedikált VPS-en, a systemd az egyszerűbb út. Ha már amúgy is Docker-alapú infrastruktúrát futtatsz, vagy szeretnéd az OpenCode-ot teljesen elszigetelni a host rendszertől, a Docker jobban illeszkedik.
Fontos: mindkét megoldás natívan tud CPU/RAM limitet érvényesíteni — nem kell Docker ahhoz, hogy korlátozd az erőforrás-használatot. A systemd a Linux cgroup v2 alrendszerén keresztül (ami a legtöbb modern disztribúción, pl. Ubuntu 22.04+, alapból elérhető) ugyanolyan kemény limitet tud adni, mint a Docker --memory/--cpus flag-jei.
systemd service példa:
# /etc/systemd/system/opencode.service
[Unit]
Description=OpenCode Server
After=network.target
[Service]
Type=simple
User=opencode
Group=opencode
WorkingDirectory=/home/opencode
Environment=OPENCODE_SERVER_USERNAME=your-user
Environment=OPENCODE_SERVER_PASSWORD=change-me-strong-password
ExecStart=/usr/bin/opencode serve --hostname 127.0.0.1 --port 4096
Restart=on-failure
RestartSec=5
# Erőforrás-limitek
MemoryMax=4G
CPUQuota=150%
[Install]
WantedBy=multi-user.targetsudo systemctl daemon-reload
sudo systemctl enable --now opencode
sudo systemctl status opencodeFigyeld meg, hogy a --hostname 127.0.0.1-re kötjük a szervert — így az csak a géphez helyben elérhető, a publikus hálózati interfészen keresztül nem. Ezt a nginx fogja a külvilág felé megnyitni, kontrollált módon.
Docker alternatíva (röviden):
docker run -d \
--name opencode \
--restart unless-stopped \
--memory=4g \
--cpus=1.5 \
-e OPENCODE_SERVER_USERNAME=your-user \
-e OPENCODE_SERVER_PASSWORD=change-me-strong-password \
-p 127.0.0.1:4096:4096 \
-v /home/opencode/projects:/projects \
opencode-image opencode serve --hostname 0.0.0.0 --port 4096Itt a konténeren belül 0.0.0.0-ra köthetjük, mert maga a -p 127.0.0.1:4096:4096 port-mapping már gondoskodik róla, hogy kívülről csak a loopback interfészen keresztül legyen elérhető.
Ez a rész könnyen homályban marad, pedig gyakorlati szempontból ez határozza meg, mihez fér hozzá az agent, amikor a telefonodról adsz neki utasítást.
A working directory = a session scope. Az OpenCode session nem egy elvont sandboxban fut, hanem abban a könyvtárban, ahonnan a szervert elindítottad (vagy amit a --hostname/projekt-választás során megadtál). A bash, read, write, edit típusú tool-hívások mind ebből a könyvtárból indulva, közvetlenül a szerver gépén (vagy konténerén) futnak — nincs külön elszigetelt "temp" munkakönyvtár, az agent ténylegesen a repód checkoutolt fájljaiban dolgozik, git-tracked állapotban.
WorkingDirectory=/home/opencode (vagy amit beállítasz a unit fájlban) lesz a kiindulási pont — érdemes ide egy fix mappastruktúrát kialakítani, pl. /home/opencode/projects/<repo-nev>/, és a klienssel ezen belül navigálni.-v /home/opencode/projects:/projects mountolással a host gépeden lévő projects mappa lesz elérhető a konténerben /projects alatt — az agent ténylegesen ide ír, ezek a változtatások a host fájlrendszerén landolnak, nem vesznek el a konténerrel együtt.Parancsfuttatás: a bash tool ugyanazzal a jogosultsággal fut, mint amilyen userrel a szervert indítottad — tehát a korábban beállított dedikált opencode user (systemd esetén), illetve a konténeren belüli user (Docker esetén). Ez a gyakorlatban azt jelenti, hogy amit az agent futtatni tud (git push, npm install, tesztek, stb.), az pontosan annyi, amennyi jogosultsága ennek a usernek van — innen a korábbi ajánlás, hogy ne legyen root vagy tág jogú user.
Több repó egyszerre: natívan egy OpenCode session egyetlen könyvtárra van korlátozva — ha másik repóban dolgoznál, vagy másik session-t indítasz más working directory-val, vagy az opencode.json/opencode.jsonc konfigban felveheted a másik repót referenciaként:
{
"references": {
"shared-lib": {
"repository": "github.com/your-org/shared-lib",
"branch": "main"
},
"docs": {
"path": "/home/opencode/projects/docs"
}
}
}Ez read/write hozzáférést ad egy másik könyvtárhoz vagy Git repóhoz anélkül, hogy külön session-t kellene indítani hozzá — hasznos, ha pl. egy shared library-t vagy egy másik szolgáltatás kódját is látnia kell az agentnek a fő repód mellett. Ha rendszeresen több, teljesen független repóval dolgozol egyszerre, praktikusabb lehet külön opencode serve instance-t futtatni repónként (más porton), és a mobil kliens projekt-választójával váltani köztük — ez tisztább határvonalat ad, mint egy session-en belül mindent összekeverni.
Mielőtt belevágsz — kell-e egyáltalán publikus URL? Ha csak a saját telefonodról szeretnéd elérni a szervert, és nincs szükséged arra, hogy bárki más vagy egy tetszőleges eszköz csatlakozzon, a Tailscale (vagy hasonló mesh VPN, pl. WireGuard-alapú) egyszerűbb és kisebb támadási felületű alternatíva: telepíted a VPS-re és a telefonodra is, ugyanahhoz a privát "tailnet"-hez csatlakoznak, és a szerver soha nem kerül ki a nyilvános internetre — nincs nyitott port, nincs nyilvános DNS bejegyzés, nincs scannelhető végpont. A hátránya, hogy a telefonon mindig futnia kell a Tailscale kliensnek, és ha esetleg mást is be akarsz engedni (pl. egy kollégát), azt is fel kell venni a tailnetbe. Ez a poszt innentől a publikusan elérhető, nginx + Let's Encrypt utat mutatja be — ha a Tailscale jobban illik a use case-edhez, a szerver-oldali rész (dedikált user, systemd/Docker, erőforrás-limit) változatlanul érvényes, csak az nginx/Let's Encrypt réteget hagyhatod el.
Az OpenCode szerver önmagában sima HTTP-t beszél — a beépített OPENCODE_SERVER_PASSWORD Basic Auth-ot ad, de ez nem titkosítás. A Basic Auth jelszó gyakorlatilag csak Base64 kódolva utazik a hálózaton, ami nem védelem — bárki, aki lehallgatja a forgalmat (pl. egy nyilvános wifi ponton ingázás közben), egyszerűen visszafejtheti. Emellett minden kérésben ott utazik a kódod és a promptjaid tartalma is, titkosítatlanul.
Ide jön képbe az nginx mint reverse proxy: TLS-t (HTTPS-t) biztosít a nyilvános végpontra, miközben az OpenCode szerver továbbra is csak 127.0.0.1-en fut, kívülről közvetlenül elérhetetlenül. Emellett az nginx:
fail2ban-nal kombinálva a brute-force elleni védelmet,auth_basic) az OpenCode saját jelszavas védelme helyett vagy mellett.Példa működő konfig:
server {
listen 443 ssl http2;
server_name opencode.pelda-domain.hu;
ssl_certificate /etc/letsencrypt/live/opencode.pelda-domain.hu/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/opencode.pelda-domain.hu/privkey.pem;
# Csak erős TLS verziók
ssl_protocols TLSv1.2 TLSv1.3;
location / {
proxy_pass http://127.0.0.1:4096;
proxy_http_version 1.1;
# Szükséges a streameléshez (Server-Sent Events)
proxy_set_header Connection '';
proxy_buffering off;
proxy_cache off;
chunked_transfer_encoding off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
# HTTP -> HTTPS redirect
server {
listen 80;
server_name opencode.pelda-domain.hu;
return 301 https://$host$request_uri;
}Fontos technikai részlet: az OpenCode streamelt válaszokat küld (Server-Sent Events), ezért a proxy_buffering off és a kapcsolódó direktívák nélkül a válaszok "csomósan", nem valós időben érkeznének meg a kliensre.
Ha az nginx szinten szeretnéd az authentikációt kezelni az OpenCode saját Basic Auth-ja helyett:
location / {
auth_basic "OpenCode";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://127.0.0.1:4096;
# ... a fenti proxy beállítások
}Ebben az esetben az OPENCODE_SERVER_PASSWORD környezeti változót kikapcsolhatod — egy HTTP kérés csak egy Authorization fejlécet tud hordozni, így a két auth-réteg (nginx + OpenCode) egyszerre nem működne együtt ugyanarra a kérésre.
A fenti nginx konfig egy valós TLS tanúsítványt feltételez — enélkül a böngésző/kliens vagy hibát dob, vagy (ami rosszabb) a felhasználó megszokja a tanúsítvány-figyelmeztetések elfogadását, ami egy man-in-the-middle támadást is átengedne észrevétlenül.
A
Let's Encrypt
egy ingyenes, automatizált, széles körben elismert hitelesítésszolgáltató (CA), amivel a certbot eszközzel percek alatt kapsz érvényes, a legtöbb kliens által natívan elfogadott tanúsítványt — self-signed cert helyett, ami mobilklienseken gyakran extra konfigurációt (pl. tanúsítvány-ellenőrzés kikapcsolását) igényelne, ami viszont pont azt a védelmet gyengítené, amit a TLS-sel el akarunk érni.
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d opencode.pelda-domain.huA certbot automatikusan beállítja a megújítást is (a tanúsítványok 90 naponta járnak le), így ez egy "állítsd be egyszer, és felejtsd el" jellegű lépés.
A nginx szekcióban már említett fail2ban-hoz itt egy konkrét, működő jail konfig, ami az auth-hibás kéréseket figyeli és ismétlődés esetén ideiglenesen tiltja a forrás IP-t:
sudo apt install fail2ban# /etc/fail2ban/jail.local
[nginx-http-auth]
enabled = true
port = http,https
filter = nginx-http-auth
logpath = /var/log/nginx/error.log
maxretry = 5
findtime = 600
bantime = 3600Ez az nginx-http-auth filter (fail2ban alapból tartalmazza) az nginx error logjában keresi a sikertelen Basic Auth kísérleteket. Ha egy IP 10 percen (findtime) belül 5-nél (maxretry) többször hibázik, 1 órára (bantime) tiltásra kerül. Ha az OpenCode saját OPENCODE_SERVER_PASSWORD-jét használod nginx auth_basic nélkül, a védendő logfájl és filter más lesz — ebben az esetben érdemes az OpenCode szerver saját loggolását (ha van rá access_log-szerű kimenet) vagy magát az nginx proxy_pass mögötti 401-es válaszokat figyelő, kicsit egyedibb filtert írni, mert a nginx-http-auth filter kifejezetten az nginx saját auth_basic moduljának hibaformátumára van hangolva.
sudo systemctl restart fail2ban
sudo fail2ban-client status nginx-http-authAz utolsó parancs megmutatja, hány próbálkozás és hány tiltás történt eddig — jó gyors ellenőrzés arra, hogy tényleg történik-e brute-force kísérlet a szervered ellen.
Az MCP (Model Context Protocol) egy nyílt szabvány, amivel az AI agent strukturált módon érhet el külső eszközöket és adatforrásokat — például egy Git hostingot, egy projektkezelő rendszert, vagy egy adatbázist — anélkül, hogy minden integrációt egyedileg kellene megírni.
Az OpenCode konfigurációjában (opencode.json vagy hasonló) definiálhatsz MCP szervereket, amiket az agent a session során tud hívni. Praktikus szempontból ez azt jelenti, hogy telefonról egy egyszerű promptból nemcsak kódot tud írni/módosítani az agent, hanem például egy ticketet lekérdezni, egy repót átnézni GitHubon, vagy egy build státuszát ellenőrizni — mindezt a szerveren futó, központilag konfigurált MCP kapcsolatokon keresztül, amikhez a hitelesítő adatok szintén a szerveren maradnak, nem a telefonon.
Ez a rész érdemes egy külön, mélyebb posztot — itt csak annyit érdemes megjegyezni, hogy az MCP szerverek konfigurálásakor ugyanaz az elv érvényes, mint a szerver többi részénél: a hitelesítő adatokat (API kulcsok, tokenek) a szerver oldalon tartsd, minimális jogosultsági körrel, és ne a kliens oldalon.
Egy MCP szervert kiemelnék, mert kifejezetten sokat dob a kódolási minőségen, és van egy karbantartási csapdája, amire érdemes elsőre felkészülni: ez a Serena .
Mi ez? A Serena egy nyílt forráskódú MCP eszközkészlet, ami a Language Server Protocol-t (LSP) használva szimbólum szinten ad hozzáférést a kódhoz — nem sima szöveges/regex keresést és sor alapú szerkesztést csinál, hanem érti, hol van definiálva egy függvény, mely helyekről hívják, mi a hívási lánc, stb. Gyakorlatban ez azt jelenti, hogy az agent pontosabban és kevesebb token felhasználásával tud navigálni és szerkeszteni egy nagyobb kódbázisban, mintha csak fájlokat olvasgatna és grep-elne.
Mit tud?
.serena/memories/ alatt), amiket egy következő session-ben újra be tud olvasni — így nem kell mindent nulláról újra felfedeznie minden egyes alkalommal, amikor telefonról elindítasz egy új beszélgetést.Telepítés:
A Serena maga Pythonban készült, és a uv csomagkezelőn keresztül települ (ez az egyetlen előfeltétel):
# uv telepítése, ha még nincs a szerveren
curl -LsSf https://astral.sh/uv/install.sh | sh
# Serena CLI telepítése — ez adja a `serena` parancsot (project create, stb.)
uv tool install --from git+https://github.com/oraios/serena serena-agentMagát az MCP szervert (serena start-mcp-server) nem kell külön telepíteni és futtatva tartani — az OpenCode a lenti config alapján, session indításkor uvx-szel automatikusan lehívja és elindítja igény szerint. A uv tool install lépés kifejezetten a serena CLI-hez kell, amivel a projekteket inicializálod (serena project create).
Hova kerül az MCP konfig?
Az OpenCode kétféle helyen keresi a config fájlt, és ez a Serenánál is számít:
~/.config/opencode/opencode.json (a dedikált opencode user home mappájában) — minden projektre/session-re érvényes, ide érdemes tenni magát a Serena MCP szerver regisztrációját, mert ez nem projekt-specifikus.opencode.json/opencode.jsonc — csak az adott projektre érvényes, felülírja/kiegészíti a globálisat. Ide kerülhetnek projekt-specifikus beállítások (pl. ha egy adott repóhoz más MCP szervert vagy más modellt akarsz).A gyakorlatban a legtöbb esetben elég a Serena regisztrációját egyszer, globálisan felvenni — nem kell minden egyes repóban megismételni, csak a serena project create inicializáló lépést kell lefuttatni projektenként.
Hozzáadás egy projekthez:
Először magát a Serena MCP szervert kell regisztrálni az OpenCode configban (opencode.json):
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"serena": {
"type": "local",
"command": ["uvx", "--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server"],
"enabled": true
}
}
}Ezután a repó gyökerében inicializálni kell magát a projektet Serena számára:
cd /home/opencode/projects/sajat-repo
serena project create --indexEz létrehoz egy .serena/project.yml-t (nyelv-detektálással), és az --index kapcsoló egyből felépíti a szimbólum-indexet is. Az első tényleges használatkor egy ún. onboarding folyamat is lefut, ami feltérképezi a projektet, és ez hozza létre a kezdeti memória fájlokat.
Mit commitoljunk, mit ne? A .serena/ mappán belül nem minden egyforma:
.serena/project.yml ← commitold: csapat-szinten megosztott config
.serena/memories/ ← commitold: az agent által írt projekt-jegyzetek, mindenkinek hasznos
.serena/cache/ ← .gitignore: gépenként újraépülő szimbólum-index cache
.serena/project.local.yml ← .gitignore: helyi, gép-specifikus felülírások (ha van)A project.yml és a memories/ commitolása azért hasznos, mert így a csapat (vagy akár csak a telefonos és a gépes munkameneted) ugyanazt a felépített tudást örökli — nem kell minden eszközön újra onboardingoltatni a Serenát.
A karbantartási csapda: session-enkénti Serena-indulás. Fontos sajátosság, hogy az OpenCode minden egyes session-hez külön Serena MCP szerver-instance-t indít — és ezzel együtt saját LSP (nyelvi szerver) folyamatot is. Ha telefonról naponta több session-t nyitsz-zársz, ezek a folyamatok nem mindig szűnnek meg tisztán: dokumentált problémák közé tartozik zombie Python folyamatok felhalmozódása, illetve súlyosabb esetben (pl. Kotlin nyelvi szerver) 90+ elárvult JVM folyamat és 20+ GB felesleges memóriahasználat, ha a szülő session megszakad anélkül, hogy rendesen leállította volna a gyereket.
Ezt érdemes eleve beépíteni az üzemeltetésbe:
web_dashboard opció a serena_config.yml-ben), amivel át lehet látni és le lehet állítani a futó szerver-instance-okat — kifejezetten azért van, mert sok kliens nem takarít el megfelelően.systemd timer, ami naponta egyszer megkeresi és kitakarítja az elárvult serena/nyelvi szerver folyamatokat):# /usr/local/bin/serena-cleanup.sh
#!/bin/bash
# Elárvult (PPID=1) Serena és nyelvi szerver folyamatok leállítása
pkill -f "serena start-mcp-server" --oldest -0 2>/dev/null
ps -eo pid,ppid,args | awk '$2 == 1 && /serena|language-server/ {print $1}' | xargs -r kill# /etc/systemd/system/serena-cleanup.timer
[Unit]
Description=Napi Serena folyamat-takarítás
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.targetEz egy egyszerű, durva megoldás — nagyobb, több felhasználós setupnál érdemesebb a Serena dashboardját vagy egy finomabb monitorozást bevezetni, de egy személyes, telefonról vezérelt szerverhez ez a napi takarítás elegendő védelem az ellen, hogy hetek alatt felhalmozódjon a memóriát zabáló, elárvult folyamatok mennyisége.
A recept nem bonyolult, csak több apró, egymásra épülő réteg. Az egész előtt viszont győződj meg róla, hogy a kiválasztott gép egyáltalán el tudja futtatni az OpenCode-ot: AVX-támogatás és legalább ~2 GB szabad RAM (a gyors ellenőrzés a VPS-elvárások szekcióban):
127.0.0.1-re kötve, systemd vagy Docker alatt, erőforrás-limittel.A végeredmény: egy szerver, ami folyamatosan fut valahol, és amit biztonságosan, titkosítva, hitelesítve érhetsz el a telefonodról — akár egy ingázás közepén is.