Migracja z Railway

Przenieś usługi z Railway razem z bazą danych i zmiennymi.

Projekt Railway składa się z usług połączonych przez odwołania do zmiennych. Na Nodion usługa z własnym kodem staje się aplikacją, workery korzystające z tego samego kodu stają się jej dodatkowymi procesami, a bazy danych stają się zarządzanymi bazami danych, które podłączasz do aplikacji. Nodion nie odczytuje plików railway.json ani railway.toml; sam Railway wycofuje Config as Code (ostateczny termin: 1 grudnia 2026), więc ustawienia przenosisz ręcznie.

Odpowiedniki usług i ustawień

1. Utwórz projekt i bazy danych

Utwórz projekt, a w nim bazy danych, z których korzysta Twój projekt Railway, w regionie, w którym mają działać aplikacje. Dla Postgres wybierz wersję co najmniej tak nową jak na Railway. Zamiast Redis Nodion oferuje Valkey, który również podłączasz przez REDIS_URL. Pusty Valkey wystarczy tylko do cache lub kolejek, które wcześniej opróżnisz; jeśli potrzebujesz kluczy z Redis, przenieś je, zanim usuniesz projekt Railway. Więcej w sekcji Bazy danych.

2. Skopiuj bazę danych

Bazy danych na Railway są domyślnie prywatne. Aby utworzyć dump, możesz uzyskać do nich dostęp na dwa sposoby. Włącz dostęp publiczny w Settings, Networking; Railway utworzy wtedy proxy TCP i ustawi DATABASE_PUBLIC_URL (dokumentacja Railway), a ruch przez proxy rozliczy jako egress. Możesz też zostawić bazę prywatną i otworzyć tunel przez Railway CLI po powiązaniu projektu poleceniem railway link. Wbudowane w Railway backupy wolumenów można przywrócić tylko w tym samym projekcie, więc do przeniesienia potrzebujesz pg_dump.

Wstrzymaj zapisy wykonywane przez Twoje usługi, a potem utwórz dump zgodnie z przewodnikiem po backupach Railway. Przy dostępie publicznym użyj wartości DATABASE_PUBLIC_URL ze zmiennych usługi bazy danych:

bashpg_dump "postgresql://postgres:PASSWORD@PROXY_HOST:PROXY_PORT/railway" \
  --format=custom --no-owner --file=railway.dump

Jeśli używasz tunelu, najpierw powiąż projekt poleceniem railway link, następnie otwórz tunel i w drugim terminalu utwórz dump przez localhost, podając port wyświetlony przez CLI:

bashrailway link
railway connect postgres --tunnel-only

# second terminal
pg_dump "postgresql://postgres:PASSWORD@localhost:TUNNEL_PORT/railway" \
  --format=custom --no-owner --file=railway.dump

Na Nodion otwórz stronę bazy danych, przejdź do zakładki Overview i kliknij Enable public access. Gdy endpoint przestanie wyświetlać Provisioning, skopiuj URL połączenia (zawsze TLS) i dodaj własny adres IP w Allowed sources. Następnie przywróć dane:

bashpg_restore --verbose --no-owner --no-acl \
  --dbname "postgresql://nodion:PASSWORD@HOST:PORT/DATABASE?sslmode=require" \
  railway.dump

Użyj pg_restore w wersji co najmniej tak nowej jak nowszy z obu serwerów. Sprawdź liczbę wierszy w zakładce Browse, a potem z powrotem wyłącz dostęp publiczny, również na Railway.

3. Utwórz aplikację i jej procesy

Dla każdej usługi z kodem utwórz jedną aplikację z jej repozytorium Git. Jeśli Railway budował przez Railpack lub Nixpacks, użyj strategii Buildpacks (Buildpacks); jeśli znalazł Dockerfile, użyj strategii Dockerfile. Nodion, inaczej niż Railway, nie wybiera strategii za Ciebie; to Ty ją ustawiasz.

Railway wstrzykuje PORT do Twoich usług. Nodion ustawia PORT tylko dla procesu web w aplikacjach z buildpackami; w aplikacjach z Dockerfile aplikacja nasłuchuje na porcie procesu web (jeśli go nie ma, na porcie z EXPOSE obrazu, a w ostateczności na 8080).

Jeśli druga usługa korzystała z tego samego repozytorium, ale miała inne polecenie startowe, na przykład jako worker, dodaj ją w Processes, New process jako kolejny proces tej samej aplikacji i wpisz tam polecenie startowe. Polecenie pre-deploy przenieś do wiersza release: w Procfile (buildpacki) albo do polecenia release aplikacji (Settings, karta Preview environments, w której pole pojawia się po włączeniu środowisk podglądu, albo release_command przez API). Polecenie uruchamia się raz przy każdym wdrożeniu, przed web; jeśli się nie powiedzie, poprzedni release pozostaje aktywny.

4. Przenieś zmienne

Wypisz zmienne usługi jako wiersze KEY=value (Railway CLI):

bashrailway variable list --kv > railway.env

Wklej wiersze w Environment przez Add many. Railway CLI nie wyświetla zapieczętowanych zmiennych (sealed variables) (dokumentacja Railway); ustaw je ręcznie jako sekrety poleceniem nodion env set KEY=value --secret. Sprawdź wartości zawierające cudzysłowy, a wartości wielowierszowe ustaw przez CLI lub API.

Nodion nie obsługuje odwołań takich jak ${{shared.KEY}} czy ${{otherService.KEY}}. Sprawdź każdą zaimportowaną zmienną: musi zawierać faktyczną wartość, a nie tekst odwołania. Tam, gdzie odwołanie wskazywało inną usługę, ustaw zamiast niej wewnętrzną nazwę hosta tej usługi na Nodion (<app>.app.internal) albo podłącz bazę danych.

Następnie usuń zaimportowane zmienne, które wskazują bazę danych Railway (DATABASE_URL, REDIS_URL): zmienna ustawiona przez Ciebie nadpisuje wartość podłączonej bazy danych. Podłącz bazy danych przyciskiem Attach database. Wewnątrz Nodion połączenie działa bez TLS (sslmode=disable); jeśli Twój kod wymusza SSL, wyłącz to dla tego URL.

5. Przenieś zadania cron

Na Railway zadanie cron to osobna usługa, która uruchamia się i kończy działanie (dokumentacja Railway). Na Nodion dodajesz je w zakładce Cron aplikacji, której kodu potrzebuje: harmonogram z pięcioma polami w UTC, polecenie, limit czasu do 30 minut, maksymalnie 8 zadań na aplikację. Zadanie działa z aktywnym release'em i zmiennymi środowiskowymi aplikacji.

6. Wdróż, przenieś domenę, wyłącz Railway

Wdróż aplikację i sprawdź zakładkę Logs. Potem dodaj domenę w zakładce Domains i ustaw dwa rekordy, które pokazuje Nodion: TXT _nodion-challenge.your-domain oraz CNAME (dla domeny głównej: ALIAS) wskazujący domyślną nazwę hosta aplikacji. Certyfikat zostanie wystawiony, gdy CNAME będzie wskazywać na Nodion; licz się z kilkoma minutami bez ważnego certyfikatu i wcześniej obniż TTL. Gdy wszystko działa, usuń projekt Railway; według Railway tej operacji nie można cofnąć.

bashrailway delete --project my-project --yes

Co działa inaczej

• W jednym projekcie nie ma osobnych środowisk production i staging; używaj osobnych aplikacji lub projektów.
• Nie ma współdzielonych zmiennych ani odwołań; wartości bazy danych pochodzą z podłączenia bazy.
• Zadania cron działają w istniejącej aplikacji, a nie jako osobna usługa.
• CLI pobiera logi, ale nie potrafi śledzić ich na bieżąco; na żywo zobaczysz je w zakładce Logs.

Co dalej

Nodion w porównaniu z Railway, Cennik, Aplikacje i Bazy danych.