OpenClaw: aktualizacja i backup krok po kroku

Zacznij od sprawdzenia, co właściwie masz zainstalowane

Numer wersji pokazuje openclaw --version. Szerszy obraz daje openclaw status: system operacyjny wraz z informacją o dostępnej aktualizacji, osiągalność gateway i usługi, listę agentów i sesji, konfigurację providerów oraz problemy runtime.

Jeśli w statusie coś już wygląda podejrzanie, uruchom openclaw doctor jeszcze przed aktualizacją. Update i tak odpali doctora w trakcie, ale wtedy trudniej odróżnić problem, który był wcześniej, od takiego, który przyniosła nowa wersja.

Zapisz sobie numer wersji, z której startujesz. Bez niego rollback do znanego dobrego stanu zamienia się w zgadywanie.

openclaw --version
openclaw status
openclaw doctor

openclaw update robi więcej niż podmianę pakietu

Dokumentacja opisuje openclaw update jako komendę, która wykrywa typ instalacji (npm, pnpm, Bun lub git), pobiera najnowszą wersję, uruchamia openclaw doctor i restartuje gateway. To dlatego jest to droga zalecana zamiast ręcznego instalowania pakietu.

Zanim coś się zmieni, możesz zobaczyć plan działania przez openclaw update --dry-run. Przydaje się szczególnie na maszynie produkcyjnej, gdzie restart gatewaya oznacza chwilową ciszę na wszystkich kanałach.

Ręczne alternatywy istnieją: npm i -g openclaw@latest, pnpm add -g openclaw@latest, bun add -g openclaw@latest. Wtedy uruchomienie doctora i restart usługi zostają po Twojej stronie.

openclaw update --dry-run
openclaw update

Kanały wydań i auto-updater — wybierz, jak szybko chcesz zmiany

OpenClaw ma cztery kanały wydań. Domyślny stable aplikuje aktualizacje po wbudowanym opóźnieniu z deterministycznym jitterem, żeby rollout rozłożył się w czasie. Beta sprawdza w stałym interwale i aplikuje od razu.

Extended-stable pokazuje podpowiedź o aktualizacji przy starcie i co 24 godziny przy włączonym checkOnStart, ale nigdy nie aplikuje niczego sam. Dev to trwały ruchomy checkout gałęzi main z GitHuba — też bez automatycznego aplikowania. Kanał przełączasz flagą, na przykład openclaw update --channel extended-stable.

Auto-updater konfiguruje się w ~/.openclaw/openclaw.json, kluczami update.channel i update.auto.enabled. Plik jest w formacie JSON5, więc dopuszcza komentarze i klucze bez cudzysłowów.

Uwaga na schemat: gateway akceptuje tylko konfiguracje, które w pełni do niego pasują. Nieznane klucze, złe typy albo niepoprawne wartości sprawiają, że gateway odmawia startu, a odrzucony zapis ląduje obok jako openclaw.json.rejected.<timestamp>.

{
  update: {
    channel: "stable",
    auto: { enabled: true }
  }
}

• stable — rozłożone w czasie, domyślne
• beta — sprawdza w interwale i aplikuje natychmiast
• extended-stable — tylko powiadamia, nigdy nie aplikuje sam
• dev — checkout gałęzi main, bez auto-apply

Backup przed każdą aktualizacją — jedna komenda

Dokumentacja aktualizacji stawia sprawę prosto: najpierw kopia, potem update. Komenda openclaw backup create z flagą --verify tworzy archiwum i od razu je waliduje, więc nie dowiadujesz się o uszkodzonym pliku dopiero przy odtwarzaniu.

Backup obejmuje katalog stanu, aktywny plik konfiguracyjny, katalog credentials, katalogi workspace, profile auth, stan sesji i bazy SQLite. Bazy zrzucane są przez online backup API SQLite i kompaktowane offline przez VACUUM, więc nie trzeba zatrzymywać gatewaya na czas kopii.

Przydatne flagi: --dry-run (podgląd), --json (wyjście maszynowe), --no-include-workspace (pominięcie katalogów workspace), --only-config (sam aktywny plik konfiguracyjny). Flaga --agent <id> nie należy do backup create — używa się jej przy podkomendach openclaw backup sqlite, żeby wskazać bazę konkretnego agenta. Osobny zestaw podkomend openclaw backup sqlite obsługuje create, list, verify i restore snapshotów baz.

mkdir -p ~/Backups/openclaw
openclaw backup create --output ~/Backups/openclaw --verify

Workspace to osobna sprawa niż katalog stanu

Domyślny workspace agenta to ~/.openclaw/workspace. Przy ustawionym OPENCLAW_PROFILE innym niż default ścieżka staje się ~/.openclaw/workspace-<profile>, a zmienna OPENCLAW_WORKSPACE_DIR nadpisuje obie. To samo da się ustawić kluczem agents.defaults.workspace.

FAQ projektu zaleca trzymanie workspace w prywatnym repozytorium git i backupowanie go gdzieś prywatnie — to łapie pamięć agenta razem z plikami AGENTS.md, SOUL.md i USER.md. Historia zmian w gicie bywa cenniejsza niż samo archiwum, bo widzisz, kiedy agent zmienił zdanie na swój temat.

Czego nie commitować: katalogu ~/.openclaw. Zawiera poświadczenia kanałów, sesje, tokeny i zaszyfrowane payloady sekretów. Workspace i stan to dwie różne lokalizacje i obie trzeba backupować, ale tylko jedna nadaje się do repozytorium.

Warstwa higieny na koniec: dokumentacja bezpieczeństwa zaleca uprawnienia 600 na ~/.openclaw/openclaw.json i 700 na samym katalogu ~/.openclaw. OpenClaw działa w modelu zaufania personal-assistant, a nie w modelu izolacji wielodostępowej.

chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/openclaw.json

Gdy aktualizacja pójdzie źle: doctor, rollback, odrzucony config

Po każdej aktualizacji warto przelecieć zestaw kontrolny: openclaw doctor, openclaw health, openclaw gateway status --deep --json oraz openclaw plugins list --json. Doctor uruchomiony po aktualizacji wykrywa i naprawia większość problemów migracyjnych automatycznie, a openclaw doctor --fix stosuje naprawy — między innymi usuwa nieaktualne cienie OAuth per-agent i przywraca ostatnią poprawną kopię konfiguracji.

Jeśli gateway odmawia startu z komunikatem o niepoprawnej konfiguracji, sprawdź openclaw config file (pokaże aktywną ścieżkę) i openclaw config validate. Odrzucone lub nadpisane wersje leżą obok configu jako pliki *.rejected.<timestamp> i *.clobbered.* — można je porównać i wyciągnąć to, co było dobre.

Rollback do znanej dobrej wersji robi się flagą --tag. Przy instalacjach pakietowych najpierw sprawdź, jakie wersje istnieją, potem przećwicz na sucho, a dopiero na końcu wykonaj. Przy checkoutach źródłowych ścieżka jest inna: git fetch --all --tags, git checkout --detach <tag-lub-commit>, pnpm install && pnpm build, openclaw gateway restart.

Jedna szczera uwaga: publiczne agregatory changelogów wymieniają breaking changes z 2026 roku (relokacja konfiguracji pluginu xAI, deprecjacja starych helperów pluginów, migracja schematu storage na SQLite), ale podają przy tym wymagania Node sprzeczne z oficjalną dokumentacją instalacji. Przed aktualizacją produkcyjną sprawdź changelog w repozytorium projektu, a nie w zewnętrznym zestawieniu.

npm view openclaw versions --json
openclaw update --tag <znana-dobra-wersja> --dry-run
openclaw update --tag <znana-dobra-wersja>

Przeprowadzka agenta na inny serwer

Migracja sprowadza się do przeniesienia całego katalogu ~/.openclaw, a nie samego openclaw.json. Na starej maszynie zatrzymujesz gateway i pakujesz katalog stanu, na nowej instalujesz CLI (i Node, jeśli trzeba), przenosisz archiwum przez scp, rsync -a albo dysk zewnętrzny i rozpakowujesz w katalogu domowym.

Po rozpakowaniu weryfikujesz: openclaw doctor, openclaw gateway restart, openclaw status. Dokumentacja podaje jasne kryteria udanej migracji — gateway działa, kanały pozostają połączone bez ponownego parowania, dashboard pokazuje istniejące sesje, a pliki workspace są na miejscu.

Dwie rzeczy, które lubią się posypać: właścicielstwo plików po transferze między użytkownikami oraz ustawienia profilu. Osobne profile, na przykład ~/.openclaw-work, trzeba archiwizować oddzielnie — nie wjadą razem z domyślnym katalogiem stanu.

Jeśli nie chcesz pilnować aktualizacji, kopii i migracji ręcznie, alternatywą jest hosting zarządzany — ClawLabs uruchamia agenta w chmurze EU (Hetzner) w około 60 sekund, od 399 zł miesięcznie, z własnymi kluczami API (BYOK) i DPA na żądanie. Wtedy backup i podbijanie wersji są po stronie dostawcy.

openclaw gateway stop
cd ~ && tar -czf openclaw-state.tgz .openclaw
# na nowej maszynie, po transferze:
cd ~ && tar -xzf openclaw-state.tgz
openclaw doctor
openclaw gateway restart
openclaw status