OpenClaw 24/7 na VPS: bezpieczna instalacja

Na laptopie OpenClaw milknie, gdy tylko zamkniesz klapę: wiadomości z WhatsAppa się piętrzą, zaplanowane zadania czekają, aż wrócisz. Na serwerze odpowiada dalej. Haczyk w tym, że bramka to nie widżet czatu. Trzyma dane logowania do twoich kanałów i, jeśli nie włączysz sandboksa, uruchamia narzędzia prosto na hoście. Przeniesienie jej na zawsze włączoną maszynę ma sens tylko wtedy, gdy razem z nią przeprowadza się model bezpieczeństwa.

Ten poradnik robi to w około 20 minut na świeżym VPS z Ubuntu 24.04.

Ostatnio sprawdzono 2026-10-04: OpenClaw 2026.9.8 (npm), Node 24.21 LTS, Ubuntu 24.04.

Czego potrzebujesz

• VPS z Linuksem. My używamy naszego planu AI-Agent: 4 vCPU, 4 GB RAM, 40 GB dysku, 10 $ miesięcznie. Dokumentacja OpenClaw wspomina o 6 GB RAM, ale chodzi o budowanie ich obrazu Dockera ze źródeł; pakiet npm nie wymaga budowania.
• Klucz API od dostawcy modeli i konta komunikatorów, które chcesz podłączyć.
• Klucz SSH na laptopie. Jeśli jeszcze go nie masz: logowanie kluczem SSH.

Plan z NAT sprawdzi się tu dobrze, a może nawet lepiej. Bramka nigdy nie potrzebuje otwartego portu przychodzącego: WhatsApp, Discord i Telegram (domyślnie long polling) łączą się na zewnątrz, a do panelu dochodzisz przez SSH. Własne IPv4 bierz tylko wtedy, gdy potrzebny kanał dostarcza wiadomości webhookiem albo planujesz publiczny reverse proxy.

1. Użytkownik, który nie jest rootem

OpenClaw uruchamia narzędzia jako użytkownik, do którego należy bramka. Jeśli to root, jako root wykona się też każde polecenie, które postanowi uruchomić zagubiony albo zmanipulowany przez prompt injection model. Dokumentacja OpenClaw nazywa uruchamianie bramki jako root niebezpiecznym i nieobsługiwanym. Utwórz osobnego użytkownika bez sudo:

# jako 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   # klucz dodany przy zamówieniu
loginctl enable-linger claw

Ostatnia linia jest ważniejsza, niż wygląda. OpenClaw instaluje użytkownikową usługę systemd, a bez lingeringu zatrzymuje się ona po wylogowaniu. To najczęstsze „wczoraj działało” na serwerach.

2. Node 24 i OpenClaw

OpenClaw 2026.9.8 wymaga Node >=24.16.0 <25 albo >=26.1.0. Pakiet nodejs z Ubuntu jest starszy, więc bierzemy 24 LTS z NodeSource:

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

Oficjalna jednolinijkowa komenda (curl -fsSL https://openclaw.ai/install.sh | bash) też działa i sama instaluje Node. Na serwerze wolimy dwa jawne kroki: widać, co gdzie ląduje, a plik binarny trafia do /usr/bin zamiast do katalogu domowego, do którego agent może pisać.

3. Onboarding jako użytkownik agenta

Zaloguj się jako claw przez SSH, nie przez su. Tylko prawdziwe logowanie uruchamia menedżer użytkownika systemd, którego potrzebuje usługa:

# z laptopa (plan NAT: dodaj -p <twój port SSH>)
ssh claw@<server>

openclaw onboard --install-daemon
openclaw gateway status

Kreator sprawdzi dostęp do modelu, zapisze ~/.openclaw/openclaw.json, wygeneruje token bramki i zainstaluje usługę. Jeśli systemctl --user narzeka na magistralę, ustaw export XDG_RUNTIME_DIR=/run/user/$(id -u) i spróbuj ponownie.

Potem zamknij pliki. Zalecenie samego OpenClaw to 700 na katalog stanu i 600 na konfigurację:

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

openclaw security audit --fix stosuje bezpieczną część poprawek: ostrzejsze uprawnienia plików i listy dozwolonych zamiast otwartych zasad grupowych. Nie zmienia adresu nasłuchu i nie stawia firewalla; ekspozycja sieciowa to dalej twoje zadanie.

4. Trzymaj bramkę na loopback

Bramka serwuje API WebSocket i panel na jednym porcie, 18789, domyślnie przypiętym do 127.0.0.1. Zostaw to tak. Minimalna konfiguracja, która zapisuje to wprost:

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

Token wygeneruj przez openssl rand -hex 32 albo openclaw doctor --generate-gateway-token. Bramka odrzuca puste tokeny i przykładowe wartości, a audyt ostrzega poniżej 24 znaków.

Czego nie robić: ustawiać bind na "lan" i otwierać portu. Dokumentacja mówi wprost: nigdy nie wystawiaj bramki bez uwierzytelniania na 0.0.0.0 i nie przekierowuj portu szeroko nawet z tokenem. Kto zdobędzie ten token, staje się operatorem procesu, który wykonuje polecenia na twoim serwerze.

Po stronie firewalla: zezwól na SSH i nic więcej.

# jako root
ufw allow OpenSSH
ufw enable
ufw status verbose

W naszych planach NAT panel pokazuje zewnętrzny port SSH, ale wewnątrz serwera sshd dalej nasłuchuje na 22. Zezwól na OpenSSH (port 22), a nie na numer portu zewnętrznego, inaczej ufw enable odetnie ci dostęp. Więcej w poradniku UFW.

5. Panel przez SSH

Z laptopa otwórz tunel i zostaw go włączonego:

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

Otwórz http://127.0.0.1:18789/ i wklej token bramki. Domyślny sshd w Ubuntu pozwala na lokalne przekierowanie; jeśli go utwardzałeś, AllowTcpForwarding local to ustawienie, które dopuszcza -L i blokuje przekierowania zdalne. Jeśli tunel pada z administratively prohibited, sprawdź właśnie tę linię.

Tailnet też się sprawdzi: Tailscale Serve trzyma bramkę na loopback i sam zarządza dostępem. Obie drogi są w porządku. Publiczny port nie.

6. Parowanie, sandbox i kto może z nim rozmawiać

Kanały czatu to drugie wejście. Domyślnie kanały z wiadomościami prywatnymi każą nieznanym nadawcom najpierw się sparować; zatwierdzasz to na serwerze:

openclaw pairing approve <channel> <code>

W grupach wymagaj wzmianki, żeby agent nie odpowiadał na każdą wiadomość w pokoju. Utwardzona konfiguracja bazowa OpenClaw ustawia dla każdego kanału dmPolicy: "pairing" i groups: { "*": { requireMention: true } }.

Dwa uczciwe zastrzeżenia. Po pierwsze: parowanie decyduje, kto może uruchomić turę, a nie co trafi do kontekstu modelu; przekazana wiadomość czy pobrana strona nadal mogą pokierować turą, którą uruchomiłeś ty. Po drugie: narzędzia głównej sesji działają na hoście, dopóki nie włączysz sandboksa (agents.defaults.sandbox.mode: "non-main" izoluje wszystko poza twoją główną sesją). Sandbox jest domyślnie wyłączony, a jego domyślny backend to Docker, więc przed włączeniem zainstaluj Dockera: Docker na VPS. Jeśli kanał z botem dzielą osoby, którym nie ufasz, użyj osobnej bramki, najlepiej na osobnym serwerze.

7. Aktualizacje i kopie zapasowe

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

W ~/.openclaw są konfiguracja, dane logowania kanałów (łącznie z sesją WhatsAppa), profile uwierzytelniania modeli i transkrypcje sesji. Stracisz je — trzeba będzie wszystko sparować od nowa; wyciekną — ktoś inny będzie tobą na WhatsAppie. Rób kopie i trzymaj je poza serwerem: pobierz przez scp albo użyj restic z szyfrowaniem.

Lista kontrolna

Gdzie tu EQVPS

Proces Node uruchomi wielu dostawców. My dodajemy płatność kryptowalutą bez KYC, plan NAT pasujący do bramki tylko na loopback i serwer MCP, przez który agent może sam zarządzać swoimi serwerami. Jeśli podłączasz do niego OpenClaw, najpierw przeczytaj zabezpieczenia MCP: token, którym można zamawiać serwery, zasługuje na tę samą ostrożność co token bramki. Szerzej o agentach na VPS — w poradniku o agentach AI.

Nasze zdanie: te 20 minut to różnica między asystentem a otwartą powłoką z interfejsem czatu. Nawet jeśli pominiesz resztę, zrób kroki 1, 4 i 5.