Migracja n8n z Proxmoksa na VPS: kompletny poradnik krok po kroku (2026)

Migrujesz n8n z lokalnej maszyny wirtualnej na Proxmoksie na zewnętrzny VPS i nie wiesz, od czego zacząć? Ten poradnik przeprowadzi Cię przez cały proces — od backupu danych, przez konfigurację Docker i Caddy z automatycznym SSL, aż po najczęstsze problemy (DNS, firewall, FTP w trybie pasywnym), na jakie natkniesz się w praktyce.

n8n to popularna platforma do automatyzacji workflow, którą coraz więcej firm i freelancerów przenosi z prywatnej infrastruktury (Proxmox, domowe serwery) na komercyjne VPS-y, żeby zyskać stabilne, publiczne IP, lepszą dostępność i łatwiejsze skalowanie. Poniżej znajdziesz sprawdzoną, przetestowaną w praktyce procedurę migracji.

Spis treści

1. Dlaczego migrować n8n z Proxmoksa na VPS
2. Czego potrzebujesz przed migracją
3. Krok 1: Identyfikacja sposobu instalacji n8n
4. Krok 2: Backup danych n8n
5. Krok 3: Przygotowanie nowego VPS
6. Krok 4: Instalacja Dockera na VPS
7. Krok 5: Przeniesienie danych na VPS
8. Krok 6: Konfiguracja reverse proxy Caddy z automatycznym SSL
9. Krok 7: Konfiguracja DNS (rekord A)
10. Krok 8: Firewall na VPS
11. Krok 9: Test i weryfikacja migracji
12. Krok 10: Cutover — przełączenie produkcyjne
13. Najczęstsze problemy i jak je rozwiązać
14. FAQ — najczęściej zadawane pytania
15. Podsumowanie

Dlaczego migrować n8n z Proxmoksa na VPS

Proxmox to świetne narzędzie do wirtualizacji lokalnej, ale ma swoje ograniczenia w kontekście uruchamiania produkcyjnych automatyzacji:

• Zależność od domowego/firmowego łącza internetowego — jeśli internet czy prąd w miejscu, gdzie stoi serwer Proxmox, padnie, wszystkie webhooki i triggery n8n przestają działać.
• Dynamiczne IP — większość łączy domowych ma zmienne adresy IP, co komplikuje konfigurację DNS i certyfikatów SSL.
• Brak łatwego skalowania — VPS pozwala w kilka minut zwiększyć zasoby (CPU, RAM), czego nie da się tak łatwo zrobić z domowym sprzętem.
• Bezpieczeństwo i uptime — profesjonalne centra danych oferują redundancję zasilania, łącza i monitoring, których nie odtworzysz w warunkach domowych.

Migracja na VPS to w praktyce przeniesienie tych samych danych (workflowy, dane logowania, historia wykonań) na nowe środowisko — nie musisz budować niczego od zera, jeśli podejdziesz do tego metodycznie.

Czego potrzebujesz przed migracją

Zanim zaczniesz, przygotuj:

• Dostęp SSH do obecnej maszyny VM na Proxmoksie oraz do docelowego VPS
• Nowy VPS ze statycznym, publicznym adresem IP (to kluczowa różnica względem środowiska domowego)
• Domenę (lub subdomenę), pod którą n8n będzie dostępny — jeśli już jej używasz, będziesz tylko przepinać rekord DNS
• Dostęp do panelu DNS domeny (może być inny niż panel, w którym kupiłeś VPS — o tym więcej w sekcji o problemach)
• Encryption key n8n — to najważniejszy element całej migracji, bez niego nie odszyfrujesz danych logowania (credentiali) zapisanych w workflowach

Krok 1: Identyfikacja sposobu instalacji N8N

Najpierw sprawdź, jak n8n jest uruchomiony na obecnej maszynie:

# Czy działa w Dockerze?
docker ps | grep n8n

# Czy jako usługa systemd (instalacja przez npm)?
systemctl status n8n

Sprawdź też, jaki typ bazy danych jest używany. Domyślnie n8n korzysta z SQLite (pojedynczy plik database.sqlite), ale może być też skonfigurowany z PostgreSQL lub MySQL — to wpływa na sposób backupu.

Jeśli n8n działa w Dockerze, sprawdź lokalizację jego danych:

docker inspect <ID_KONTENERA> --format '{{range .Mounts}}{{.Source}} -> {{.Destination}}{{"\n"}}{{end}}'

To pokaże dokładną ścieżkę na hoście, w której przechowywane są dane n8n (zwykle zamontowaną jako /home/node/.n8n wewnątrz kontenera).

Krok 2: Backup danych N8N

Folder danych n8n (domyślnie ~/.n8n lub inna ścieżka wskazana w docker-compose.yml) zawiera kilka kluczowych elementów:

• database.sqlite — baza z workflowami, danymi logowania (credentiale) i historią wykonań
• config — plik z konfiguracją, w tym encryption key (jeśli nie ustawiłeś go ręcznie jako zmienną środowiskową, n8n wygenerował go automatycznie i zapisał właśnie tutaj)
• binaryData/ — pliki binarne generowane/przetwarzane przez workflowy
• Ewentualne foldery git/ i ssh/, jeśli korzystałeś z funkcji source control

Dlaczego trzeba zatrzymać n8n przed backupem

SQLite podczas aktywnego zapisu może trzymać dane częściowo w plikach tymczasowych (write-ahead log). Kopiowanie bazy „na żywo”, w trakcie działania n8n, grozi skopiowaniem jej w niespójnym stanie. Cała operacja zatrzymania i spakowania zajmuje zwykle kilkanaście sekund, więc przestój jest minimalny:

cd /ścieżka/do/projektu
docker compose stop

tar -czvf n8n_backup.tar.gz ./nazwa_folderu_danych docker-compose.yml

docker compose start

Wskazówka: rób backup w momencie niskiego ruchu (np. w nocy), jeśli Twoje workflowy obsługują webhooki działające w czasie rzeczywistym — kilkunastosekundowy przestój może wtedy oznaczać utratę pojedynczego zdarzenia przechodzącego akurat w tym momencie.

Jeśli używasz PostgreSQL lub MySQL zamiast SQLite, zrób dodatkowo osobny zrzut bazy:

pg_dump -U uzytkownik -h localhost nazwa_bazy > backup_bazy.sql

Krok 3: Przygotowanie nowego VPS

Zamów VPS ze statycznym publicznym adresem IP. Po otrzymaniu dostępu SSH, zaktualizuj system:

sudo apt update && sudo apt upgrade -y

Sprawdź swoje publiczne IP — będzie potrzebne do konfiguracji DNS:

curl -4 ifconfig.me

Krok 4: Instalacja Dockera na VPS

Najbardziej niezawodny sposób instalacji Dockera, szczególnie na nowszych lub rzadziej wspieranych wersjach dystrybucji Linuksa, to oficjalny skrypt instalacyjny:

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

Jeśli ręczne dodawanie repozytorium APT kończy się błędem (co bywa częste na najnowszych wydaniach Debiana czy Ubuntu, zanim Docker doda dla nich oficjalne wsparcie), skrypt get.docker.com rozwiązuje ten problem automatycznie, dobierając kompatybilne repozytorium.

Sprawdź instalację:

docker --version
docker compose version

Jeśli plugin compose nie zainstalował się razem ze skryptem, dodaj go osobno:

sudo apt install -y docker-compose-plugin

Krok 5: Przeniesienie danych na VPS

Prześlij spakowany backup na nowy serwer:

scp n8n_backup.tar.gz uzytkownik@adres_vps:/home/n8n/

Rozpakuj go w docelowym folderze:

mkdir -p /home/n8n
cd /home/n8n
tar -xzvf n8n_backup.tar.gz

Ustaw poprawne uprawnienia do plików

Obraz Docker n8n domyślnie uruchamia procesy jako użytkownik node z UID/GID 1000. Sprawdź, czy Twoje pliki mają taki właśnie właściciel:

stat -c '%u:%g' ./nazwa_folderu_danych/database.sqlite

Jeśli wynik to 1000:1000, ustaw taki sam właściciel na nowym serwerze (nie musisz tworzyć użytkownika o konkretnej nazwie — liczy się tylko numeryczny UID/GID):

sudo chown -R 1000:1000 ./nazwa_folderu_danych

To jeden z najczęstszych błędów przy migracji — pominięcie tego kroku skutkuje błędami dostępu do bazy przy starcie kontenera.

Krok 6: Konfiguracja reverse proxy Caddy z automatycznym SSL

Caddy to serwer proxy, który automatycznie generuje i odnawia certyfikaty SSL (Let’s Encrypt), bez ręcznej konfiguracji certbota czy nginx. To znacznie prostsze rozwiązanie niż klasyczny nginx + certbot dla małych i średnich wdrożeń n8n.

Stwórz wspólną sieć Docker, przez którą Caddy i n8n będą się ze sobą komunikować:

docker network create caddy-net

Konfiguracja n8n (nano/home/n8n/docker-compose.yml):

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    environment:
      - N8N_PROTOCOL=https
      - N8N_HOST=twoja-domena.pl
      - N8N_PORT=5678
      - WEBHOOK_URL=https://twoja-domena.pl/
      - N8N_EDITOR_BASE_URL=https://twoja-domena.pl
    volumes:
      - ./nazwa_folderu_danych:/home/node/.n8n
    networks:
      - caddy-net

networks:
  caddy-net:
    external: true

Konfiguracja Caddy (nano/home/caddy/docker-compose.yml):

services:
  caddy:
    image: caddy:latest
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - caddy-net

volumes:
  caddy_data:
  caddy_config:

networks:
  caddy-net:
    external: true

Caddyfile ( nano/home/caddy/Caddyfile):

twoja-domena.pl {
    reverse_proxy n8n:5678
}

Uruchom najpierw Caddy, potem n8n:

cd /home/caddy && docker compose up -d
cd /home/n8n && docker compose up -d

Uwaga: nie musisz jawnie dodawać N8N_ENCRYPTION_KEY w zmiennych środowiskowych, jeśli klucz jest już zapisany w przeniesionym pliku config — n8n odczyta go automatycznie stamtąd. To nawet bezpieczniejsze niż trzymanie klucza w plikach compose.

Krok 7: Konfiguracja DNS (rekord A)

W panelu DNS domeny (uwaga: to może być inny panel niż ten, w którym kupiłeś VPS albo hosting — o tej pułapce więcej w sekcji problemów) dodaj rekord:

Sprawdź na serwerze propagację, pytając bezpośrednio serwer autorytatywny (pomija cache):

dig +short n8n.twoja-domena.pl @8.8.8.8

Jeśli używasz Cloudflare: koniecznie ustaw rekord na tryb „DNS only” (szara chmurka), a nie „Proxied” (pomarańczowa chmurka) — w trybie proxy Let’s Encrypt nie będzie mógł zweryfikować domeny metodą HTTP-01, co uniemożliwi wystawienie certyfikatu SSL przez Caddy.

Krok 8: Firewall na VPS

Większość dostawców VPS ma dwie niezależne warstwy firewalla: jedną wewnątrz systemu (np. ufw), drugą w panelu webowym dostawcy (chmurowy firewall na poziomie sieci). Obie trzeba skonfigurować.

Firewall systemowy (jeśli dostępny):

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Firewall w panelu dostawcy VPS: sprawdź sekcję „Firewall” / „Security Groups” w panelu i dodaj analogiczne reguły Accept dla portów 22 (SSH), 80 (HTTP) i 443 (HTTPS), z regułą Drop na końcu dla pozostałego ruchu.

Krok 9: Test i weryfikacja migracji

Po uruchomieniu obu kontenerów sprawdź logi:

docker compose logs -f

Szukaj potwierdzenia poprawnego uzyskania certyfikatu SSL oraz informacji o aktywacji Twoich workflowów. Następnie wejdź na https://twoja-domena.pl i zweryfikuj:

• czy logowanie do panelu działa
• czy wszystkie workflowy są widoczne i mają status aktywny (jeśli takie miały być)
• czy dane logowania (credentiale) w node’ach odszyfrowują się bez błędu — to bezpośrednie potwierdzenie, że encryption key został poprawnie przeniesiony
• czy historia wykonań (Executions) jest zachowana

Krok 10: Cutover — przełączenie produkcyjne

Gdy wszystko działa poprawnie na nowym VPS:

1. Zatrzymaj n8n na starej maszynie (Proxmox), żeby uniknąć podwójnego przetwarzania webhooków przez workflowy aktywne w obu miejscach jednocześnie
2. Upewnij się, że DNS w pełni się propagował (możesz to sprawdzić globalnie przez serwisy typu dnschecker.org)
3. Monitoruj logi na nowym VPS przez pierwsze godziny i dni, zwracając szczególną uwagę na workflowy z webhookami od zewnętrznych systemów
4. Po kilku dniach stabilnej pracy możesz bezpiecznie wyłączyć i skasować starą maszynę wirtualną, zachowując backup jeszcze przez jakiś czas jako zabezpieczenie

Najczęstsze problemy i jak je rozwiązać

DNS wskazuje na stary adres mimo zmiany rekordu

Sprawdź, czy edytujesz strefę DNS we właściwym panelu. Domena i VPS bywają kupione u dwóch różnych dostawców — zmiana rekordu w panelu dostawcy VPS nic nie da, jeśli faktyczne nameservery domeny wskazują na innego rejestratora. Sprawdź to komendą:

dig NS twoja-domena.pl @8.8.8.8

Przeglądarka pokazuje błąd połączenia, mimo że serwer odpowiada poprawnie

Jeśli curl z samego serwera zwraca 200, a zewnętrzne narzędzia (np. serwisy sprawdzające status HTTP) też to potwierdzają, ale przeglądarka na Twoim komputerze nadal nie może się połączyć — to niemal zawsze cache DNS w Twoim domowym routerze lub systemie operacyjnym, trzymający stary adres IP dłużej niż wskazuje TTL rekordu. Rozwiąż to, czyszcząc cache DNS lokalnie (ipconfig /flushdns na Windows) i restartując router. Test na innej sieci (np. dane mobilne w telefonie) szybko potwierdzi tę diagnozę.

Certyfikat SSL nie chce się wygenerować („Timeout during connect”)

Zwykle oznacza to, że porty 80/443 nie są osiągalne z zewnątrz — sprawdź obie warstwy firewalla (systemowy i w panelu dostawcy) oraz upewnij się, że domena nie jest za proxy Cloudflare w trybie „Proxied”.

Node FTP w workflow „wisi” bez odpowiedzi po migracji

To bardzo częsty problem po zmianie adresu IP serwera, na którym działa n8n. Typowa przyczyna to tryb pasywny FTP (PASV): serwer FTP w odpowiedzi na połączenie zwraca adres IP i port, na które klient (n8n) ma się połączyć w celu transferu danych. Jeśli po drodze jest firewall blokujący ten dodatkowy zakres portów, albo serwer FTP błędnie zwraca swój wewnętrzny adres zamiast publicznego, połączenie zawiesza się bez wyraźnego błędu.

Zdiagnozuj to, testując bezpośrednio z poziomu VPS:

curl -v --user 'login:haslo' ftp://adres.serwera.ftp/

Jeśli otrzymasz błąd typu „421 Service not available” zaraz po nawiązaniu połączenia — może to oznaczać automatyczną, tymczasową blokadę nowego adresu IP przez mechanizmy ochronne serwera (np. Fail2ban), niezależną od jawnej listy dozwolonych adresów IP w panelu hostingowym. W takiej sytuacji warto skontaktować się z supportem dostawcy hostingu FTP i poprosić o sprawdzenie automatycznych blokad na poziomie serwera, nie tylko panelu.

Workflow z komendami SSH/Docker przestaje działać po migracji

Jeśli workflow wykonuje polecenia SSH odwołujące się do konkretnej nazwy kontenera Docker (np. docker exec nazwa_kontenera ...), sprawdź czy ta nazwa nie zmieniła się na nowym serwerze — zależy ona od nazwy folderu projektu Docker Compose:

docker ps

Sprawdź też, czy dane logowania w credentialu SSH nie wskazują wciąż na adres starej maszyny.

FAQ — najczęściej zadawane pytania

Czy migracja n8n z Proxmoksa na VPS wymaga przestoju?

Sam proces kopiowania danych wymaga jedynie krótkiego zatrzymania n8n na czas backupu (zwykle kilkanaście sekund). Docelowe przełączenie ruchu (cutover) możesz zaplanować na moment niskiego ruchu, minimalizując wpływ na aktywne automatyzacje.

Czy stracę swoje workflowy i dane logowania podczas migracji?

Nie, jeśli poprawnie przeniesiesz cały folder danych n8n (w tym plik bazy SQLite oraz plik config z encryption key). To właśnie encryption key odpowiada za możliwość odszyfrowania zapisanych danych logowania (credentiali) — jego utrata jest najczęstszą przyczyną nieudanych migracji.

Czy muszę używać dokładnie tej samej wersji n8n na nowym serwerze?

Zalecane jest zainstalowanie tej samej wersji, co na maszynie źródłowej, żeby uniknąć nieoczekiwanych zmian w schemacie bazy danych podczas automatycznej migracji przy starcie nowszej wersji.

Dlaczego certyfikat SSL nie działa mimo poprawnej konfiguracji Caddy?

Najczęstsze przyczyny to: DNS jeszcze się nie propagował, porty 80/443 są zablokowane przez firewall (systemowy lub dostawcy VPS), albo domena jest ukryta za proxy Cloudflare, co blokuje standardową weryfikację HTTP-01.

Co zrobić, jeśli po migracji integracja FTP w n8n przestała działać?

Sprawdź tryb połączenia FTP (pasywny/aktywny) oraz czy nowy adres IP VPS nie został automatycznie zablokowany przez mechanizmy zabezpieczeń serwera FTP. Rozważ też migrację na SFTP, jeśli docelowy serwer to wspiera — eliminuje to problemy związane z dodatkowymi portami transferu danych w klasycznym FTP.

Podsumowanie

Migracja n8n z Proxmoksa na VPS to proces, który przy odpowiednim przygotowaniu można przeprowadzić bez utraty danych i z minimalnym przestojem. Kluczowe elementy sukcesu to: pełny backup folderu danych (łącznie z encryption key), poprawna konfiguracja uprawnień plików po stronie nowego serwera, prawidłowe ustawienie DNS we właściwym panelu zarządzania domeną, oraz skonfigurowanie firewalla na obu jego warstwach (systemowej i dostawcy VPS). Większość problemów napotykanych w praktyce — błędy DNS, blokady firewalla, zawieszające się połączenia FTP — wynika z tych samych, powtarzalnych przyczyn, które opisaliśmy w sekcji najczęstszych problemów powyżej.