Railway był w 2026 roku domem moich produktów: QuizBase, RoundKit, platformy do gier szkoleniowych i jednego narzędzia wewnętrznego. W listopadzie 2026 wyprowadziłem z niego wszystko. Nie przez jedną awarię, tylko przez serię zdarzeń i to, jak firma się po nich zachowywała. Opisuję tę historię z perspektywy klienta i produktowca, bo pokazuje coś, co dotyczy każdego, kto sprzedaje usługę: jak szybko można stracić zaufanie, które budowało się latami.
Dlaczego w ogóle wybrałem Railway?
Bo był wygodny i nadal uważam, że jest. W maju pisałem o tym, ile kosztuje własne API, i Railway był tam pozytywnym bohaterem: wysyłasz kod, platforma sama go buduje i uruchamia, płacisz za zużycie, a nie za serwer, który stoi bezczynnie. Dla kogoś, kto buduje produkty, nie pisząc kodu, to ogromna ulga.
Za tę wygodę płaci się czymś więcej niż rachunkiem. Oddajesz platformie kontrolę nad tym, czy Twój produkt działa. Dopóki platforma jest niezawodna, to dobra transakcja. W 2026 roku przestała nią być.
Co się działo z Railway w 2026 roku?
Najpierw fakty, każdy z podlinkowanym źródłem:
| Kiedy | Co się stało | Co to znaczyło dla klientów |
|---|---|---|
| 11.2025 - 05.2026 | Pięć opublikowanych raportów z poważnych awarii w pół roku | Seria, nie pojedynczy wypadek |
| 19-20.05 | Google Cloud zawiesił konto Railway. Około 8 godzin awarii całej platformy | Panel, API i część aplikacji niedostępne |
| 20-22.10 | Włam: ktoś mógł odszyfrować zmienne środowiskowe części klientów, czyli hasła do baz i klucze API | Railway zalecił wszystkim wymianę wszystkich kluczy, budowanie wstrzymane we wszystkich regionach |
| 28.10 | Wdrożenia zawieszone na etapie startu | Kolejne godziny bez możliwości wydania poprawki |
| 3.11 | Agenci AI inżyniera Railway sondowali infrastrukturę konkurenta. Współzałożyciel przeprosił | Pytanie o kulturę bezpieczeństwa w firmie, która trzyma moje sekrety |
| od 4.11 | Część sieci i operatorów blokuje adresy IP Railway | Aplikacje nieosiągalne dla części użytkowników |
Do tego moje własne liczenie: na stronie statusu Railway naliczyłem w październiku około 36 zgłoszeń, we wrześniu około sześciu.
Czy to była wina Railway?
Formalnie przy części zdarzeń winny jest ktoś inny. W maju konto zawiesił Google, w listopadzie blokady wywołał, według Railway, ruch podszywający się pod ich adresy. Tylko że dla klienta to nie ma żadnego znaczenia.
Najlepiej ujął to sam Railway w raporcie po majowej awarii: „Railway owns our vendor choices, and we ultimately own this one”, czyli „to Railway wybiera dostawców i to my ostatecznie za to odpowiadamy”. Dalej: „We take full responsibility for the architectural decisions that allowed a single upstream provider action to cascade into a platform-wide outage”. Pełna odpowiedzialność za architekturę, w której decyzja jednego dostawcy kładzie całą platformę.
Zgadzam się z tym zdaniem w stu procentach i właśnie dlatego nie uniewinniam Railway. Płacę platformie za to, żeby wybrała partnerów i zbudowała infrastrukturę tak, by mnie to nie dotyczyło. Jeśli zawieszenie jednego konta w Google wyłącza mi produkcję na osiem godzin, to jest wada produktu, który kupiłem, a nie pech.
U mnie majowa awaria zostawiła konkretne ślady: zadania cykliczne QuizBase uruchamiały się po kilka razy tego samego dnia, raport dzienny przychodził kilka razy z różnymi liczbami, a ja szukałem i łatałem błąd w swoim kodzie, którego tam nie było.
Ile kosztuje zdanie „wymieńcie wszystkie klucze”?
Najwięcej kosztował mnie włam z października. Railway poinformował, że ktoś mógł dostać się do zaszyfrowanych zmiennych i część z nich odszyfrować. Według wstępnych szacunków dotyczyło to do 1,85% przestrzeni roboczych, ale zalecenie było jedno dla wszystkich: wymieńcie wszystkie klucze. Założyciel Railway napisał na X, że z nadmiaru ostrożności.
Brzmi rozsądnie, dopóki nie policzysz, co to znaczy w praktyce. U mnie: hasła do wszystkich baz, sekrety logowania w trzech aplikacjach (czyli wylogowanie wszystkich użytkowników), klucze API, hasła do kopii zapasowych, klucze do wysyłki maili, hasło do zewnętrznej bazy. Każdą zmianę trzeba wprowadzić w kilku miejscach naraz i sprawdzić, że nic nie przestało działać. Część wymaga klikania w panelach innych dostawców i część z nich wciąż na mnie czeka.
Wymiana sekretów ma też skutki uboczne, których nie widać od razu. W QuizBase jeden klucz był zaszyfrowany starym sekretem, więc po rotacji przez ponad sześć godzin nikt nie mógł się zalogować. W platformie gier szkoleniowych konta z weryfikacją dwuetapową wymagają osobnej naprawy. To wiele godzin pracy, które poszły na sprzątanie po cudzym włamie zamiast na rozwój produktów.
Nie dostałem za to ani przeprosin skierowanych do klientów, ani rabatu, ani rekompensaty. Cennik bez zmian, a mój plan nie miał umowy o poziomie usług, która dawałaby jakiekolwiek zwroty. „Z nadmiaru ostrożności” przeniosło cały koszt incydentu na klientów.
Jak komunikacja zjada zaufanie?
Pojedyncza awaria nie odbiera zaufania. Każda platforma kiedyś padnie i rozsądny klient to wie. Zaufanie traci się w tym, co dzieje się po awarii.
W maju Railway opublikował obszerny raport: przebieg godzina po godzinie, wzięcie odpowiedzialności, lista zmian w architekturze. Tak powinno się to robić. W październiku, przy dużo poważniejszym zdarzeniu, było już krótko: wymieńcie klucze. W listopadzie przeprosiny padły, tyle że wobec konkurenta, którego infrastrukturę sondowali agenci AI pracownika. Klienci, którzy w tym czasie rotowali sekrety, gestu nie dostali.
Najmocniej widać to na X, gdzie klienci zwykle piszą o problemach. Na profilu ze statusem Railway komentarze jeszcze kilka dni temu były włączone, dziś są wyłączone. Pod wpisami głównego konta obserwuję, jak znikają komentarze ludzi, którzy masowo piszą, że już się wyprowadzili, dokąd i za ile. Rozumiem odruch, ale to najgorszy możliwy sygnał. Klienci i tak o tym rozmawiają, tylko już gdzie indziej, a firma traci jedyne miejsce, w którym mogła im odpowiedzieć.
Jako produktowiec patrzę na zaufanie jak na konto. Każdy incydent to wypłata. Dobra komunikacja i gest wobec klientów to wpłata. Railway przez ten rok głównie wypłacał, a w drugiej połowie roku przestał wpłacać. W pewnym momencie saldo spada poniżej zera i klient przestaje liczyć, tylko podejmuje decyzję.
Czego ta historia uczy mnie jako produktowca?
Klient płaci za spokój, nie za serwer. Railway sprzedawał mi to, że nie muszę myśleć o infrastrukturze. Każda awaria i każda nocna rotacja kluczy odbierała dokładnie tę wartość, za którą płaciłem. Dlatego tak łatwo było policzyć, że własny serwer, z całym dodatkowym wysiłkiem, wychodzi lepiej.
Odpowiedzialność za dostawców jest Twoja. Zdanie Railway o wyborze dostawców działa w obie strony. Moi klienci nie wiedzą, czym jest Railway. Gdy QuizBase nie odpowiada, to awaria QuizBase, nie Railway. Skoro Railway odpowiada za swoich dostawców przed swoimi klientami, to ja odpowiadam za swoich przed moimi. Dlatego się wyprowadziłem.
Gest kosztuje mniej niż odejście klienta. Nie wiem, czy kredyt w wysokości miesięcznego rachunku zatrzymałby mnie na stałe. Pewnie przesunąłby decyzję o kilka miesięcy i dał Railway czas na naprawę. Brak gestu sprawił, że migrację zrobiłem dzień po rotacji kluczy.
Zawsze miej plan wyjścia. Uratowało mnie to, że od początku nie trzymałem wszystkiego u jednego dostawcy. Domeny i ruch szły przez Cloudflare, kod leżał na GitHubie, kopie baz robiłem poza Railway. Dzięki temu cała przeprowadzka zajęła mniej niż dobę, a największa przerwa dla użytkowników trwała 1 minutę i 40 sekund. Opisuję ją krok po kroku w tekście o tym, jak przeniosłem cztery aplikacje na VPS z Coolify.
Ta sama logika dotyczy każdego dostawcy, od którego zależy firma, także dostawców AI. Pytanie „co zrobimy, gdy ten dostawca zawiedzie?” warto zadać przed wdrożeniem, nie po awarii. Piszę o tym szerzej przy metodzie oceny ryzyka AI.
Czy Railway jeszcze odzyska klientów?
Może. Majowy raport pokazał, że firma umie przyznać się do błędu i zaplanować poprawki. Jeśli dowiezie architekturę niezależną od jednego dostawcy i wróci do szczerej komunikacji, część klientów da jej drugą szansę. Życzę im tego, bo produkt jest dobry.
Ja już nie wrócę, przynajmniej nie z produkcją. Przekonałem się, że wygoda platformy jest warta tyle, ile jej niezawodność, a odpowiedzialność za to, czy moje produkty działają, i tak spada na mnie.
Jeśli Twoja firma stoi przed podobną decyzją, czyli zależy od dostawcy, któremu przestaje ufać, i nie wie, ile kosztowałoby wyjście, to dobry temat na konsultację. Policzymy ryzyko, koszt zmiany i realny plan wyjścia.