Găzduiește OpenClaw 24/7 pe un VPS: configurare sigură

Pe un laptop, OpenClaw tace din clipa în care închizi capacul: mesajele de pe WhatsApp se adună la coadă, sarcinile programate așteaptă să te întorci. Pe un server, răspunde mai departe. Problema e că gatewayul nu e un widget de chat. Ține datele de acces ale canalelor tale și, dacă nu-l pui într-un sandbox, rulează unelte direct pe host. Să-l muți pe o mașină pornită non-stop merită doar dacă muți odată cu el și modelul de securitate.

Ghidul ăsta face asta în aproximativ 20 de minute, pe un VPS Ubuntu 24.04 proaspăt.

Verificat ultima dată pe 2026-10-04 cu OpenClaw 2026.9.8 (npm), Node 24.21 LTS și Ubuntu 24.04.

De ce ai nevoie

• Un VPS Linux. Noi folosim planul AI-Agent: 4 vCPU, 4 GB RAM, 40 GB disc, $10/lună. Documentația OpenClaw menționează 6 GB de RAM, dar asta e pentru construirea imaginii lor Docker din sursă; pachetul npm nu cere niciun build.
• O cheie API de la furnizorul modelului tău și conturile de chat pe care vrei să le conectezi.
• O cheie SSH pe laptop. Dacă n-ai încă una: autentificarea cu cheie SSH.

Un plan NAT e în regulă aici și, probabil, chiar mai potrivit. Gatewayul nu are niciodată nevoie de un port de intrare deschis: WhatsApp, Discord și Telegram (implicit cu long polling) se conectează spre exterior, iar la dashboard ajungi prin SSH. Ia un IPv4 dedicat doar dacă un canal de care ai nevoie livrează prin webhook sau dacă vrei să pui în față un reverse proxy public.

1. Un utilizator care nu e root

OpenClaw rulează uneltele ca utilizatorul care deține gatewayul. Dacă acel utilizator e root, atunci e root și fiecare comandă pe care un model confuz sau victimă a unui prompt injection decide s-o ruleze. Documentația OpenClaw numește rularea gatewayului ca root nesigură și nesuportată. Creează un utilizator dedicat, fără sudo:

# as root
apt update && apt -y upgrade
adduser --disabled-password --gecos "" claw
install -d -m 700 -o claw -g claw /home/claw/.ssh
install -m 600 -o claw -g claw ~/.ssh/authorized_keys /home/claw/.ssh/authorized_keys   # the key you added at order time
loginctl enable-linger claw

Ultima linie contează mai mult decât pare. OpenClaw instalează un serviciu systemd de utilizator, iar fără lingering serviciul se oprește când ieși din sesiune. E cel mai frecvent „ieri mergea” pe servere.

2. Node 24 și OpenClaw

OpenClaw 2026.9.8 cere Node >=24.16.0 <25 sau >=26.1.0. Pachetul nodejs din Ubuntu e mai vechi, așa că ia 24 LTS de la NodeSource:

# as root
curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs
node -v          # v24.16.0 or newer
npm install -g openclaw@latest
openclaw --version

Comanda oficială de o linie (curl -fsSL https://openclaw.ai/install.sh | bash) merge și ea și îți instalează Node. Pe un server preferăm cei doi pași expliciți: vezi ce ajunge unde, iar binarul stă în /usr/bin, nu într-un director home în care agentul poate scrie.

3. Configurarea inițială ca utilizatorul agentului

Intră ca claw prin SSH, nu cu su. O autentificare reală pornește managerul de utilizator systemd de care are nevoie serviciul:

# from your laptop (NAT plans: add -p <your SSH port>)
ssh claw@<server>

openclaw onboard --install-daemon
openclaw gateway status

Asistentul verifică accesul la model, scrie ~/.openclaw/openclaw.json, generează un token pentru gateway și instalează serviciul. Dacă systemctl --user se plânge de bus, setează export XDG_RUNTIME_DIR=/run/user/$(id -u) și rulează din nou.

Apoi restrânge accesul la fișiere. Recomandarea OpenClaw e 700 pe directorul de stare și 600 pe configurație:

chmod 700 ~/.openclaw && chmod 600 ~/.openclaw/openclaw.json
openclaw security audit --deep

openclaw security audit --fix aplică partea sigură a corecturilor: permisiuni mai stricte pe fișiere și allowlisturi în loc de politici de grup deschise. Nu reface legarea și nu pune nimic după firewall în locul tău; expunerea în rețea rămâne treaba ta.

4. Ține gatewayul pe loopback

Gatewayul servește API-ul WebSocket și dashboardul pe un singur port, 18789, legat implicit de 127.0.0.1. Lasă-l acolo. O configurație minimă care spune asta explicit:

// ~/.openclaw/openclaw.json
{
  gateway: {
    mode: "local",
    bind: "loopback",
    port: 18789,
    auth: { mode: "token", token: "paste-output-of-openssl-rand-hex-32" },
  },
}

Generează tokenul cu openssl rand -hex 32 sau openclaw doctor --generate-gateway-token. Gatewayul refuză tokenurile goale și valorile-exemplu, iar auditul avertizează sub 24 de caractere.

Ce să nu faci: să setezi bind la "lan" și să deschizi portul. Documentația e directă: nu expune niciodată gatewayul fără autentificare pe 0.0.0.0 și nu-l redirecționa larg nici măcar cu token. Cine pune mâna pe tokenul ăla devine operatorul unui proces care poate rula comenzi pe serverul tău.

La firewall, permite SSH și nimic altceva:

# as root
ufw allow OpenSSH
ufw enable
ufw status verbose

Pe planurile noastre NAT, dashboardul arată un port SSH extern, dar în interiorul serverului sshd ascultă tot pe 22. Permite OpenSSH (portul 22), nu numărul portului extern, altfel ufw enable te încuie afară. Mai multe în ghidul UFW.

5. Ajungi la dashboard prin SSH

De pe laptop, deschide un tunel și lasă-l să ruleze:

ssh -N -L 18789:127.0.0.1:18789 claw@<server>
# NAT plan: ssh -N -p <your SSH port> -L 18789:127.0.0.1:18789 claw@<host>

Deschide http://127.0.0.1:18789/ și lipește tokenul gatewayului. sshd-ul implicit din Ubuntu permite redirecționarea locală; dacă l-ai întărit, AllowTcpForwarding local e setarea care permite -L și blochează redirecționările la distanță. Dacă tunelul pică cu administratively prohibited, asta e linia de verificat.

Merge și un tailnet: Tailscale Serve ține gatewayul pe loopback și se ocupă de acces. Ambele variante sunt în regulă. Un port public nu e.

6. Pairing, sandbox și cine poate vorbi cu el

Canalele de chat sunt cealaltă cale de intrare. Implicit, canalele cu mesaje directe îi pun pe expeditorii necunoscuți să facă întâi pairing; tu îi aprobi de pe server:

openclaw pairing approve <channel> <code>

Pentru grupuri, cere o mențiune, ca agentul să nu răspundă la fiecare mesaj din cameră. Configurația de bază întărită a OpenClaw folosește dmPolicy: "pairing" și groups: { "*": { requireMention: true } } pe fiecare canal.

Două rezerve cinstite. Întâi, pairingul controlează cine poate declanșa o tură, nu ce ajunge în contextul modelului: un mesaj redirecționat sau o pagină web descărcată pot încă să ghideze o tură declanșată de proprietar. Apoi, uneltele rulează pe host pentru sesiunea principală, dacă nu pornești sandboxing (agents.defaults.sandbox.mode: "non-main" pune în sandbox totul în afară de propria ta sesiune principală). Sandboxingul e oprit implicit, iar backendul lui implicit e Docker, deci instalează întâi Docker dacă îl pornești: Docker pe un VPS. Dacă oameni în care nu ai încredere sunt pe același canal cu botul, folosește un gateway separat, ideal pe un server separat.

7. Actualizări și backup-uri

openclaw update
openclaw gateway status
openclaw backup create --output ~/backups/openclaw --verify

~/.openclaw ține configurația, datele de acces ale canalelor (inclusiv sesiunea WhatsApp), profilurile de autentificare la model și transcrierile sesiunilor. Dacă îl pierzi, refaci pairingul pentru tot; dacă se scurge, altcineva devine tu pe WhatsApp. Fă-i backup și ține backup-ul în afara serverului: copiază-l la tine cu scp sau folosește restic, cu criptare.

Listă de verificare

Unde se potrivește EQVPS

Multe hosturi pot rula un proces Node. Ce adăugăm noi e plata cripto fără KYC, un plan NAT potrivit pentru un gateway doar pe loopback și un server MCP pe care agentul tău îl poate folosi ca să-și gestioneze propriile servere. Dacă legi OpenClaw de el, citește întâi MCP guardrails: un token care poate comanda servere merită aceeași grijă ca tokenul gatewayului. Pentru o privire mai largă asupra rulării agenților pe un VPS, vezi ghidul pentru agenți AI.

Părerea noastră: cele 20 de minute de mai sus fac diferența dintre un asistent și un shell deschis cu interfață de chat. Fă pașii 1, 4 și 5 chiar dacă îi sari pe restul.