Medusa Cloud czy własny hosting? Koszty, skalowanie i porównanie z Railway
Remigiusz Mielcarz, , 13 min czytania
Przez ostatnie lata stawialiśmy sklepy i hurtownie na Medusie na własnej infrastrukturze: backend na Railway, baza PostgreSQL i Redis obok, zdjęcia w Cloudflare R2, storefront na Cloudflare. To działa i nadal utrzymujemy takie wdrożenia. W ciągu ostatniego roku zespół Medusy dowiózł jednak Medusa Cloud do poziomu, przy którym przestaliśmy pytać „czy”, a zaczęliśmy liczyć „kiedy się opłaca”. Poniżej to liczenie: ceny, trzy realne scenariusze, skalowanie w szczycie sprzedaży i ograniczenia, o których warto wiedzieć przed decyzją.
W skrócie:
- Medusa Cloud trzyma w jednym miejscu wszystko, co do tej pory składaliśmy z kilku usług u trzech dostawców: backend, panel, storefront, bazę z kopiami zapasowymi, Redis, pliki, e-maile i środowisko podglądu dla każdej zmiany.
- Na samej fakturze za infrastrukturę wychodzi drożej niż Railway z Cloudflare: 99 USD wobec ok. 65 USD dla małego sklepu i ok. 310 USD wobec ok. 147 USD dla hurtowni B2B z ERP.
- Po doliczeniu czasu na utrzymanie rachunek się odwraca. Przy stawce 50 USD za godzinę Medusa Cloud jest tańsza, gdy własna infrastruktura zjada więcej niż 40 minut miesięcznie w małym sklepie i ok. 3,3 godziny w hurtowni.
- Dlatego nowym klientom rekomendujemy Medusa Cloud. Własny hosting zostawiamy dla najmniejszych sklepów, nietypowych wymagań i projektów, w których klient ma własny zespół od infrastruktury.
Jak hostowaliśmy Medusę do tej pory
Typowy sklep, który oddawaliśmy, składał się z siedmiu elementów u trzech dostawców:
- Backend Medusy (API i panel) jako kontener Dockera na Railway, z healthcheckiem i automatycznym restartem.
- Worker do zadań w tle (synchronizacja z ERP, importy, e-maile), w małych sklepach w tej samej usłudze, w większych osobno.
- PostgreSQL na Railway, na wolumenie.
- Redis na Railway: cache, szyna zdarzeń, silnik workflow i blokady Medusy.
- Pliki i zdjęcia w Cloudflare R2 (bez opłat za transfer).
- Storefront w Next.js na Cloudflare Workers.
- E-maile transakcyjne przez Resend.
Do tego dochodzą rzeczy, których nie widać w architekturze, ale ktoś musi je zrobić: nocne kopie bazy z testem odtwarzania, alerty, aktualizacje obrazów PostgreSQL i Redisa, osobne środowisko testowe oraz ręczne skalowanie przed wyprzedażą. Każdy z tych punktów to osobny panel, osobny rachunek i osobne miejsce, w którym coś może się zepsuć.
Czym jest Medusa Cloud
Medusa Cloud to zarządzana platforma hostingowa od zespołu, który tworzy Medusę. Podpinasz repozytorium, a platforma wdraża backend, panel administracyjny i storefront (Next.js, TanStack Start albo SvelteKit), i do każdego środowiska dokłada:
- zarządzaną bazę PostgreSQL (jedna na środowisko),
- Redis z Medusa Cache (od planu Launch),
- magazyn plików S3, globalny CDN, ochronę przed DDoS i certyfikaty SSL,
- środowisko podglądu dla każdego pull requesta, z kopią bazy produkcyjnej, usypiane po 10 minutach bezczynności i usuwane po scaleniu zmiany,
- autoskalowanie i wdrożenia bez przestojów (od planu Launch),
- kopie zapasowe z przywracaniem do punktu w czasie (7 dni w Launch, 14 dni w Scale),
- e-maile transakcyjne (Medusa Emails), wyszukiwarkę (Medusa Search) i logi, a w planie Scale także eksport logów do Sentry, Datadoga czy Grafany (dodatek za 50 USD miesięcznie, od sierpnia 2026).
Regiony są trzy: Europe Central (Frankfurt), US East i Asia Southeast. Medusa nie pobiera prowizji od obrotu i nie limituje liczby zamówień, produktów ani użytkowników panelu.
Platforma jest ogólnodostępna od października 2025 roku i od tego czasu co kilka miesięcy dostaje kolejne klocki: cache (październik 2025), e-maile (listopad 2025), hosting storefrontów na wszystkich planach (styczeń 2026), eksport logów (sierpień 2026) i wyszukiwarkę (wrzesień 2026).
Plany i ceny (stan na 5 października 2026)
| Develop | Launch | Scale | Enterprise | |
|---|---|---|---|---|
| Cena miesięcznie | od 29 USD | od 99 USD | od 299 USD | indywidualnie |
| Serwery aplikacji | 1 współdzielony | 2 współdzielone, autoskalowanie | 2 serwery + osobny worker, autoskalowanie | do ustalenia |
| Godziny obliczeniowe | 600 (twardy limit) | 1 000, potem 0,16 USD/h | 2 800, potem 0,16 USD/h | do ustalenia |
| Baza PostgreSQL | 1 GB | 5 GB, potem 0,50 USD/GB | 10 GB, potem 0,50 USD/GB | do ustalenia |
| Kopie zapasowe | brak | 7 dni, do punktu w czasie | 14 dni, do punktu w czasie | do ustalenia |
| Redis | brak | 250 MB | 250 MB | do ustalenia |
| Transfer | 10 GB | 40 GB, potem 0,125 USD/GB | 100 GB, potem 0,125 USD/GB | do ustalenia |
| E-maile miesięcznie | 1 000 | 10 000, potem 0,70 USD/1 000 | 25 000, potem 0,70 USD/1 000 | do ustalenia |
| Środowiska podglądu | 1 | 3, kolejne 10 USD | 5, kolejne 10 USD | do ustalenia |
| Miejsca w zespole | 1 | 1, kolejne 30 USD | 3, kolejne 30 USD | do ustalenia |
| SLA | brak | brak | brak | 99,99% |
Każdy plan ma jedno stałe środowisko w cenie, kolejne (np. stały staging) kosztuje 60 USD miesięcznie. Pliki: 10 GB w każdym planie, potem 0,025 USD za GB.
Najważniejszy wniosek z tej tabeli: Develop nie jest planem produkcyjnym. Nie ma kopii zapasowych, Redisa, autoskalowania, wdrożeń bez przestojów ani własnej domeny. Realne minimum dla działającego sklepu to Launch za 99 USD.
Porównanie kosztów: trzy realne scenariusze
Ceny Railway, Cloudflare i Resend bierzemy z cenników z października 2026: Railway Pro to 20 USD miesięcznie z 20 USD zużycia w cenie, potem 20 USD za vCPU i 10 USD za GB RAM miesięcznie, 0,15 USD za GB wolumenu i 0,05 USD za GB transferu. Zużycie CPU i RAM przyjmujemy jako średnie, jakie widzimy w działających sklepach. Railway liczy realne zużycie, a nie przydzielone zasoby. Kwoty są netto, w dolarach, tak jak w cennikach dostawców.
Scenariusz 1: sklep B2C na start
Ok. 1 500 zamówień i 150 tys. odsłon miesięcznie, baza 1 GB, 5 GB zdjęć, ok. 5 000 e-maili.
| Własny hosting (Railway + Cloudflare) | Miesięcznie |
|---|---|
| Backend z workerem: 0,25 vCPU (5,00) + 1 GB RAM (10,00) | 15,00 USD |
| PostgreSQL: 0,1 vCPU (2,00) + 0,5 GB RAM (5,00) + wolumen 5 GB (0,75) | 7,75 USD |
| Redis: 0,05 vCPU (1,00) + 0,2 GB RAM (2,00) | 3,00 USD |
| Transfer: 20 GB | 1,00 USD |
| Produkcja na Railway (abonament 20 USD obejmuje 20 USD zużycia) | 26,75 USD |
| Środowisko testowe, mniejsze | 13,70 USD |
| Storefront na Cloudflare Workers (plan Paid) | 5,00 USD |
| Zdjęcia i nocne kopie bazy w R2 (ok. 11 GB) | 0,02 USD |
| E-maile: 5 000 to więcej niż darmowe 3 000 w Resend, więc plan Pro | 20,00 USD |
| Razem | 65,47 USD |
Medusa Cloud, plan Launch: 99 USD. Środowisko testowe zastępują trzy środowiska podglądu w cenie, e-maile (10 000) i hosting storefrontu też są w planie, a zużycie mieści się w limitach. Jeśli ktoś potrzebuje stałego stagingu obok podglądów, rachunek rośnie do 159 USD.
Scenariusz 2: hurtownia B2B zintegrowana z ERP
Ok. 8 000 zamówień i 1 mln odsłon miesięcznie, synchronizacja stanów i cen z ERP co 5 minut, baza 25 GB, 30 GB plików, ok. 25 000 e-maili.
| Własny hosting (Railway + Cloudflare) | Miesięcznie |
|---|---|
| Backend (API): 0,6 vCPU (12,00) + 2 GB RAM (20,00) | 32,00 USD |
| Worker na integracje: 0,4 vCPU (8,00) + 1,5 GB RAM (15,00) | 23,00 USD |
| PostgreSQL: 0,4 vCPU (8,00) + 2 GB RAM (20,00) + wolumen 30 GB (4,50) | 32,50 USD |
| Redis: 0,1 vCPU (2,00) + 0,5 GB RAM (5,00) | 7,00 USD |
| Transfer: 120 GB | 6,00 USD |
| Produkcja na Railway | 100,50 USD |
| Środowisko testowe | 18,65 USD |
| Storefront na Cloudflare Workers (ok. 4 mln żądań, w limicie 10 mln) | 5,00 USD |
| R2: 30 GB plików + 14 dziennych kopii bazy po 5 GB | 2,35 USD |
| E-maile: Resend Pro (50 000 w cenie) | 20,00 USD |
| Razem | 146,50 USD |
Medusa Cloud, plan Scale: 309,50 USD. Do 299 USD dochodzi baza ponad limit (15 GB × 0,50 = 7,50 USD), pliki ponad limit (20 GB × 0,025 = 0,50 USD) i transfer ponad limit (20 GB × 0,125 = 2,50 USD). Osobny worker, 14 dni kopii, 25 000 e-maili i trzy miejsca w zespole są w cenie. Ze stałym stagingiem: 369,50 USD.
Dlaczego nie Launch? W hurtowni z ERP synchronizacja w tle nie powinna dzielić serwera z API, z którego korzystają klienci. Launch ma dwa współdzielone serwery bez osobnego workera, więc przy ciężkich integracjach wybieramy Scale.
Koszt, którego nie ma na fakturze
Porównanie samych faktur jest niepełne, bo własna infrastruktura wymaga pracy, której nie widać w cenniku: konfiguracji i testowania kopii zapasowych, aktualizacji baz, monitoringu, reakcji na alerty i skalowania przed wyprzedażą. Z naszego doświadczenia to ok. 2,5 godziny miesięcznie w małym sklepie i ok. 6 godzin w hurtowni z integracjami. Na Medusa Cloud zostaje ok. 0,5 i 1,5 godziny: głównie przegląd logów i kosztów. Aktualizacje samej Medusy pomijamy po obu stronach, bo w obu modelach robi je zespół wdrożeniowy.
Przy stawce 50 USD za godzinę:
| Miesięcznie | Własny hosting | Medusa Cloud |
|---|---|---|
| Sklep B2C: infrastruktura + utrzymanie | 65,47 + 125 = 190,47 USD | 99,00 + 25 = 124,00 USD |
| Hurtownia B2B: infrastruktura + utrzymanie | 146,50 + 300 = 446,50 USD | 309,50 + 75 = 384,50 USD |
Uczciwiej niż nasze szacunki godzin działa punkt równowagi. Różnica na fakturze to 33,53 USD w sklepie i 163 USD w hurtowni, więc Medusa Cloud wychodzi taniej, gdy własna infrastruktura zajmuje więcej niż ok. 40 minut miesięcznie w sklepie albo ok. 3,3 godziny w hurtowni. Jeśli Twój zespół mieści się w tych widełkach, własny hosting nadal będzie tańszy.
Skalowanie: co się dzieje w szczycie sprzedaży
Weźmy hurtownię ze scenariusza 2 i Black Friday: przez 4 dni (96 godzin) ruch jest pięć razy większy.
Na Railway backend podnosimy z 0,6 do 2,5 vCPU i z 2 do 4 GB RAM, baza dostaje dodatkowy rdzeń, transfer rośnie o 100 GB. Dodatkowy koszt:
- backend: 1,9 vCPU × 20 USD × 96/730 h = 5,00 USD, 2 GB RAM × 10 USD × 96/730 h = 2,63 USD,
- baza: 1 vCPU × 20 USD × 96/730 h = 2,63 USD,
- transfer: 100 GB × 0,05 USD = 5,00 USD,
- razem ok. 15 USD.
Taniej się nie da, ale tę zmianę trzeba zaplanować i przypilnować: repliki serwera konfiguruje się ręcznie, a PostgreSQL działa jako jedna instancja na wolumenie, bez automatycznego przełączenia na zapas. Ktoś musi być pod telefonem.
Na Medusa Cloud autoskalowanie dokłada instancje samo. Przyjmijmy dwie dodatkowe instancje przez 96 godzin (Medusa nie publikuje dokładnego przelicznika godzin obliczeniowych, więc to przybliżenie):
- 192 godziny obliczeniowe × 0,16 USD = 30,72 USD,
- transfer: 100 GB × 0,125 USD = 12,50 USD,
- dodatkowe 8 mln żądań storefrontu × 0,30 USD za milion = 2,40 USD,
- razem ok. 46 USD.
Szczyt na Medusa Cloud kosztuje więc mniej więcej trzy razy więcej niż na Railway, ale w kwotach, które przy obrocie z Black Friday są pomijalne. Do tego wdrożenia nie wyłączają sklepu, więc poprawkę w trakcie wyprzedaży da się wypuścić bez ryzyka przestoju.
Co zyskujesz, mając wszystko w jednym miejscu
Liczby to połowa obrazu. Druga połowa to to, jak się na tym pracuje.
- Jeden dostawca zamiast trzech. Jeden panel, jedna faktura i jedno miejsce, w którym szukasz przyczyny problemu, zamiast przeskakiwania między Railway, Cloudflare i Resend.
- Platforma od twórców silnika. Konfiguracja Redisa, cache i workera jest dopasowana do Medusy przez ludzi, którzy ją piszą. Medusa Cache według Medusy przyspiesza odpowiedzi ok. 2,2 raza.
- Podgląd każdej zmiany. Każdy pull request dostaje własne środowisko z kopią bazy. Klient klika zmianę, zanim trafi na produkcję. To najbardziej odczuwalna zmiana w naszej codziennej pracy.
- Kopie zapasowe, które już są. Przywracanie do punktu w czasie z 7 albo 14 dni bez pisania skryptów i bez pamiętania o teście odtwarzania.
- Skalowanie bez planowania. Autoskalowanie i wdrożenia bez przestojów od planu Launch.
- Dane w UE. Region we Frankfurcie, co przy polskich sklepach upraszcza rozmowę o RODO.
Uczciwie: ograniczenia Medusa Cloud
- Wyższy próg wejścia. Produkcja zaczyna się od 99 USD, a stały staging to kolejne 60 USD. Przy bardzo małym sklepie to odczuwalne.
- Mniej kontroli nad dodatkami. Do Redisa nie ma bezpośredniego dostępu i nie zmienisz jego konfiguracji. Jeśli potrzebujesz własnych ustawień, uruchamiasz własny Redis.
- Pliki są publiczne. Magazyn S3 w Medusa Cloud udostępnia przesłane pliki publicznie, więc prywatne dokumenty (np. faktury, pliki B2B) trzeba trzymać w osobnym magazynie.
- Region jest na zawsze. Wybierasz go przy tworzeniu projektu i nie da się go zmienić.
- Aktualizacje Medusy robisz sam. Platforma nie podbija wersji za Ciebie, a cofnięcie wdrożenia nie cofa migracji bazy. Wtedy potrzebne jest wsparcie Medusy.
- Storefront w monorepo. Hosting storefrontu wymaga repozytorium Turbo albo Nx i jednego z obsługiwanych frameworków (Next.js, TanStack Start, SvelteKit). Front w Astro trzeba hostować gdzie indziej.
- SLA i SOC 2 tylko w Enterprise. Gwarancja 99,99% dostępności, SOC 2 i własna umowa powierzenia danych są w planie Enterprise. Na niższych planach nie ma opublikowanego SLA.
- Nieznane parametry serwerów. Medusa nie publikuje vCPU i RAM za „godziną obliczeniową”, więc przed dużym szczytem warto przetestować obciążenie.
O uzależnieniu od dostawcy: jest niewielkie. Bazę eksportujesz w każdej chwili, a Medusa jest open source (MIT, z wyjątkiem materiałów Enterprise Edition, takich jak RBAC i SSO), więc sklep przeniesiesz na własną infrastrukturę bez przepisywania kodu.
Kiedy własny hosting nadal ma sens
- Sklep jest bardzo mały, a ktoś w firmie i tak dba o serwery. Wtedy kilkadziesiąt dolarów różnicy miesięcznie ma znaczenie.
- Potrzebujesz pełnej kontroli: własnej konfiguracji Redisa, bezpośredniego dostępu do bazy, prywatnych plików albo regionu, którego nie ma w Medusa Cloud.
- Front działa w frameworku spoza listy Medusa Cloud albo poza monorepo.
- Klient ma własny zespół od infrastruktury i swoje standardy (np. AWS z istniejącymi umowami).
W takich przypadkach dalej wdrażamy Railway z Cloudflare albo infrastrukturę klienta. Opisaną wyżej architekturę znamy i utrzymujemy.
Jak przenosimy sklep z Railway na Medusa Cloud
- Zakładamy projekt w regionie Europe Central (Frankfurt), pamiętając, że regionu nie zmienimy.
- Układamy repozytorium jako monorepo (backend i storefront) i podpinamy je do GitHuba.
- Przenosimy zmienne środowiskowe, a adresy Redisa i magazynu plików podmieniamy na te z Medusa Cloud.
- Robimy zrzut bazy z PostgreSQL 16 i importujemy go do środowiska produkcyjnego.
- Przenosimy publiczne pliki z R2 do magazynu Medusa Cloud. Prywatne zostają w osobnym magazynie.
- Testujemy całość na środowisku podglądu, a potem przepinamy domenę.
- Stary stack zostawiamy na kilka dni jako plan awaryjny.
Przy typowym sklepie zajmuje to jeden, dwa dni pracy plus okno na przepięcie domeny.
Nasza rekomendacja
Jeśli budujesz sklep albo hurtownię na Medusie, zacznij od Medusa Cloud: Launch dla większości sklepów, Scale dla hurtowni z ciężkimi integracjami. Zapłacisz więcej za infrastrukturę, a mniej za utrzymanie, które w małych zespołach zwykle i tak spada na kogoś „przy okazji”. Dostajesz też środowiska podglądu, kopie zapasowe i skalowanie, których na własnym hostingu trzeba pilnować samemu.
Własny hosting zostaje świadomym wyborem, a nie domyślną ścieżką. Jeśli chcesz, policzymy obie opcje na danych z Twojego sklepu. Napisz do nas albo zobacz, jak budujemy sklepy na Medusa.js. Więcej o samej platformie znajdziesz w bazie wiedzy: Medusa Cloud.
Źródła
Ceny i fakty sprawdziliśmy 5 października 2026: