Migracja z Heroku: kiedy odejść i dokąd przenieść aplikację
Heroku to świetny start dla startupu: szybki deploy, zero devops, fokus na produkcie. Ale przychodzi moment, gdy koszty rosną szybciej niż przychody, a ograniczenia platformy blokują rozwój. Ten artykuł pomaga rozpoznać ten moment i wybrać najlepszą ścieżkę migracji.
Kiedy Heroku zaczyna przeszkadzać
Heroku to genialne narzędzie do walidacji pomysłu. git push heroku main i aplikacja działa. Nie musisz wiedzieć, czym jest VPC, security group czy load balancer. Płacisz za prostotę i to jest uczciwa wymiana, na początku.
Problem pojawia się, gdy startup rośnie. Rachunki za Heroku rosną nieliniowo: każdy dodatkowy dyno, addon do bazy danych, Redis z większą pamięcią to skok cenowy. Konfiguracja, która w AWS kosztowałaby 200 USD miesięcznie, na Heroku może kosztować 800-1200 USD.
Sygnały, że czas na zmianę
Koszty rosną szybciej niż przychody. Performance-M dyno na Heroku to ~250 USD/mies. Za te pieniądze w AWS uruchomisz dwa kontenery t3.medium z load balancerem i auto-skalowaniem. Jeśli Twój miesięczny rachunek Heroku przekracza 500 USD, prawdopodobnie przepłacasz.
Potrzebujesz niestandardowej konfiguracji. Specyficzne wersje systemu operacyjnego, custom libraries, długotrwałe procesy, WebSockets bez timeoutu. Heroku ma swoje ograniczenia, których nie obejdziesz.
Wymagania compliance. RODO wymaga, aby dane osobowe obywateli EU były przetwarzane na terenie EOG. Heroku przez długi czas oferowało serwery tylko w US i EU (Dublin). Jeśli potrzebujesz konkretnej lokalizacji (np. Frankfurt dla klientów z Polski i Niemiec), chmura publiczna daje pełną kontrolę.
Potrzebujesz więcej niż web app. Queues, scheduled jobs, ML pipelines, real-time streaming: w Heroku każda z tych rzeczy to drogi addon lub hack. W chmurze to natywne, zarządzane usługi.
Dokąd z Heroku: porównanie opcji
VPS (Hetzner, DigitalOcean, OVH)
Dla kogo: startupy z prostą architekturą (monolith + baza + cache), budżet <200 PLN/mies.
Zalety: najniższy koszt, pełna kontrola, serwery w Polsce/Europie.
Wady: samodzielna administracja (aktualizacje, backupy, monitoring, security patches), brak auto-skalowania, single point of failure bez dodatkowej konfiguracji.
Kiedy wybierasz VPS: masz kompetencje ops w zespole lub gotowość na naukę, nie potrzebujesz SLA >99.9%, architektura jest prosta i przewidywalna.
AWS (ECS, EKS, App Runner)
Dla kogo: startupy i scale-upy, które potrzebują skalowalności i managed services.
Zalety: pełen ekosystem usług (RDS, ElastiCache, SQS, S3), auto-skalowanie, globalna infrastruktura, program AWS Activate (kredyty do 100 000 USD).
Wady: krzywa uczenia się (VPC, IAM, networking), complexity cost, łatwo o niespodziewane rachunki bez cost management.
Kiedy wybierasz AWS: potrzebujesz managed databases z repliką i backupem, planujesz skalowanie powyżej jednego serwera, masz lub planujesz DevOps w zespole.
GCP (Cloud Run, GKE)
Dla kogo: startupy z ML/data workloads lub te preferujące simplicity Google’a.
Zalety: Cloud Run to najbliższy odpowiednik Heroku: serverless containers z prostym CLI. BigQuery i Vertex AI dla data teams.
Wady: mniejszy ekosystem zarządzanych usług niż AWS, mniej polskich klientów (mniejsza społeczność), mniej dostawców wsparcia.
Kiedy wybierasz GCP: Twoja aplikacja to głównie API + baza + ML, lubisz prostotę Cloud Run, zespół ma doświadczenie z GCP.
Railway, Render, Fly.io (neo-PaaS)
Dla kogo: startupy, które chcą odejść z Heroku ale nie są gotowe na full cloud.
Zalety: prostota zbliżona do Heroku, niższe ceny, lepsze DX.
Wady: wciąż vendor lock-in, ograniczona elastyczność, młode platformy z mniejszą stabilnością.
Kiedy wybierasz neo-PaaS: nie masz DevOps w zespole, budżet nie przekracza 300 USD/mies., prostota jest ważniejsza niż kontrola.
Jak przeprowadzić migrację
Krok 1: Audit obecnej infrastruktury
Zanim cokolwiek migrujesz, zmapuj to co masz:
- Ile dynos i jakiego typu?
- Jakie addony (Heroku Postgres, Redis, Mailgun, Papertrail)?
- Jakie zmienne środowiskowe i sekrety?
- Jak wygląda proces deploy (pipeline, review apps)?
- Jakie domeny i certyfikaty SSL?
- Jaka jest baza danych: rozmiar, extensions, wersja PostgreSQL?
Krok 2: Konteneryzacja
Jeśli Twoja aplikacja działa na Heroku, konteneryzacja jest prosta. Heroku buildpacki mają odpowiedniki w Dockerfile lub Cloud Native Buildpacks. Stwórz Dockerfile, który odwzorowuje środowisko Heroku:
- Ten sam runtime (Ruby, Node, Python w odpowiedniej wersji)
- Te same zależności systemowe
- Ten sam entrypoint (Procfile → CMD w Dockerfile)
Testuj kontener lokalnie zanim przejdziesz dalej. Jeśli działa lokalnie w Docker, zadziała w chmurze. Więcej o konteneryzacji i Docker znajdziesz w naszym wcześniejszym artykule.
Krok 3: Infrastruktura docelowa
Użyj Terraform lub AWS CDK do zdefiniowania infrastruktury jako kod. Minimum to:
- VPC z publicznym i prywatnym subnetem
- ECS Fargate (lub EKS) dla aplikacji
- RDS PostgreSQL (odpowiednik Heroku Postgres)
- ElastiCache Redis (odpowiednik Heroku Redis)
- ALB (load balancer) z certyfikatem SSL
- S3 + CloudFront dla assets
Krok 4: Migracja danych
Najtrudniejszy element. Baza danych wymaga starannego planowania:
- Użyj
pg_dump/pg_restoredla mniejszych baz - Dla baz >50 GB rozważ AWS DMS (Database Migration Service)
- Zaplanuj okno maintenance, ponieważ downtime jest nieunikniony przy migracji bazy
- Przetestuj migrację na kopii zanim zrobisz to na produkcji
Krok 5: DNS cutover
Ostatni krok to przekierowanie DNS z Heroku na nową infrastrukturę. Ustaw niski TTL (60-300s) kilka dni wcześniej. Przełączenie to zmiana rekordu CNAME/A, a propagacja DNS trwa od minut do godzin.
Koszty migracji vs oszczędności
Migracja to inwestycja, która zwraca się w ciągu 3-12 miesięcy. Przykładowy rachunek:
| Element | Heroku (mies.) | AWS po migracji (mies.) |
|---|---|---|
| 2× Performance-M dyno | 500 USD | – |
| Heroku Postgres Standard | 50 USD | – |
| Heroku Redis Premium | 30 USD | – |
| 2× ECS Fargate tasks | – | 60 USD |
| RDS db.t3.medium | – | 45 USD |
| ElastiCache t3.micro | – | 15 USD |
| ALB + networking | – | 25 USD |
| Razem | 580 USD | 145 USD |
Oszczędność: ~435 USD miesięcznie = ~5 200 USD rocznie. Przy koszcie migracji 2 000-3 000 USD (z konsultantem) inwestycja zwraca się w 5-7 miesięcy.
Samodzielnie czy z pomocą
Samodzielna migracja jest możliwa, jeśli w zespole jest osoba z doświadczeniem w AWS/GCP. Liczy się nie tylko postawienie infrastruktury, ale również poprawna konfiguracja bezpieczeństwa (IAM, security groups, encryption), monitoringu i procedur backupu.
Jeśli zespół nie ma doświadczenia z chmurą, warto rozważyć wsparcie specjalisty. Szczegółowy przewodnik migracji z Heroku do AWS opisuje cały proces od strony technicznej: czego się spodziewać, jakie decyzje architektoniczne podjąć i jakich pułapek unikać.
Można też rozważyć podejście etapowe: najpierw przeniesienie aplikacji w trybie lift-and-shift (kontenery na ECS), a później stopniowa optymalizacja (wykorzystanie zarządzanych usług AWS). Taka strategia minimalizuje ryzyko i pozwala zespołowi uczyć się chmury w kontrolowanych warunkach.
Wnioski
Migracja z Heroku to naturalny krok w dojrzewaniu startupu. Nie trzeba się spieszyć. Heroku działa i pozwala skupić się na produkcie. Ale warto mieć plan na przyszłość i wiedzieć, gdzie leży próg opłacalności. Dla większości startupów jest to gdzieś między 500 a 1000 USD miesięcznego rachunku za Heroku. Warto też zapoznać się z ogólnym procesem migracji do AWS i kosztami chmury dla startupów, aby podejść do decyzji z pełną wiedzą o kosztach i benefitach.
Kluczowe pytania to:
- Czy masz (lub możesz zdobyć) kompetencje ops?
- Czy potrzebujesz elastyczności wykraczającej poza to, co oferuje PaaS?
- Czy koszty Heroku rosną szybciej niż przychody?
Jeśli odpowiedź na co najmniej dwa z tych pytań brzmi „tak”, czas zacząć planować migrację. Nie na jutro, ale na najbliższy kwartał. Podejście do migracji do chmury AWS: koszty i proces krok po kroku pomoże zaplanować budżet i harmonogram.
Potrzebujesz pomocy z migracją? Sprawdź ofertę Devopsity →
szczegółowy przewodnik migracji z Heroku do AWSDefinicje
- PaaS (Platform as a Service)
- Model chmury, w którym dostawca zarządza infrastrukturą, runtime i middleware, a klient wdraża tylko kod. Heroku, Railway, Render to przykłady PaaS. Prosty w użyciu, ale ograniczający i drogi przy skali.
- Lift and shift
- Strategia migracji polegająca na przeniesieniu aplikacji do nowego środowiska bez zmian w architekturze. Najszybsza i najtańsza opcja migracji, ale nie wykorzystuje pełni możliwości nowej platformy.
- Vendor lock-in
- Uzależnienie od konkretnego dostawcy technologicznego. Migracja jest trudna lub kosztowna ze względu na proprietarne formaty danych, API lub konfigurację.
Źródła
FAQ
Kiedy warto odejść z Heroku?
Najczęstsze sygnały to: miesięczny rachunek przekraczający 500-1000 USD za zasoby, które w chmurze kosztowałyby ułamek tej kwoty; potrzeba niestandardowej konfiguracji (specyficzne wersje, custom buildpacki); wymagania compliance (lokalizacja danych w EU); lub ograniczenia techniczne (brak WebSockets na starszych dynos, 30s timeout).
Ile kosztuje migracja z Heroku do AWS?
Dla typowego startupu (Rails/Node app + PostgreSQL + Redis + background workers) migracja do AWS z pomocą konsultanta kosztuje 10 000-30 000 PLN. Samodzielna migracja jest tańsza finansowo, ale wymaga 2-4 tygodni pracy full-time i niesie ryzyko przestojów.
Czy muszę przepisywać aplikację przy migracji z Heroku?
Nie. Strategia lift-and-shift (konteneryzacja istniejącej aplikacji i uruchomienie na ECS/EKS) nie wymaga zmian w kodzie. Buildpacki Heroku mają odpowiedniki w Docker, takie jak Cloud Native Buildpacks. Jedyne zmiany to konfiguracja zmiennych środowiskowych i połączeń z bazami danych.