DigitalOcean zasłużenie wyrósł na „domyślną chmurę” dla małych i średnich zespołów developerskich: firma powstała w 2012 r. jako odpowiedź na potrzebę prostych i przystępnych usług cloud, a jej pierwszym produktem był Droplet, czyli łatwa do uruchomienia maszyna wirtualna. Dzisiaj DigitalOcean jest już jednak znacznie szerszą platformą, z własnym PaaS-em App Platform i prywatnym rejestrem kontenerów DOCR, co zwiększa wygodę, ale często też podnosi całkowity koszt stosu.

W realistycznym, europejskim scenariuszu z czterema VPS-ami i obiektowym storage’em różnica kosztów jest duża nawet przy dość konserwatywnych założeniach. W przyjętym tu modelu porównawczym miesięczny rachunek wychodzi na poziomie 226 USD po stronie DigitalOcean i 68,45 EUR po stronie Hetznera. Po przeliczeniu kursami z 18 maja 2026 r. daje to około 823,79 zł wobec 290,46 zł, czyli około 533,33 zł oszczędności miesięcznie i około 6,4 tys. zł rocznie.

Drugi argument jest mniej „twardy” finansowo, ale dla wielu polskich firm coraz ważniejszy: jurysdykcja danych. UODO przypomina, że w obrębie EOG nie ma potrzeby stosowania standardowych klauzul umownych przy transferach danych, podczas gdy transfery do państw trzecich wymagają odrębnych podstaw i zabezpieczeń; jednocześnie istnieje decyzja adekwatności dla określonych podmiotów w USA. Mimo tego Parlament Europejski nadal opisuje zależność od nieeuropejskich dostawców chmurowych i software’owych jako strategiczną podatność, wskazując m.in. na ryzyka związane z CLOUD Act i ogólną zależnością od dostawców spoza UE.

Hetzner dobrze wpisuje się w ten kierunek jako europejski operator: posiada własne parki data center w Norymberdze, Falkenstein i Helsinkach, deklaruje zgodność z GDPR dla usług cloud, ma certyfikat ISO/IEC 27001:2022 i wskazuje też na certyfikację BSI C5 Type 2 dla usług chmurowych.

DigitalOcean jako dawny standard

To, że przez lata tyle zespołów wybierało DigitalOcean, nie było przypadkiem. Ich propozycja wartości była bardzo czytelna: prosty interfejs, przewidywalny billing, szybkie uruchamianie VM-ek i dobre doświadczenie dla developerów. W oficjalnej historii firmy sam DigitalOcean podkreśla, że został założony po to, aby dać twórcom i firmom łatwiej dostępne, przystępne cenowo rozwiązania cloud.

Dla startupów, software house’ów i zespołów produktowych ten model był bardzo atrakcyjny z co najmniej trzech powodów:

• niski próg wejścia — Droplety były prostą, zrozumiałą abstrakcją serwera;
• rozsądny katalog usług bazowych — VM, storage, sieć i później także usługi managed;
• przewidywalność — DigitalOcean nadal promuje „simple, predictable pricing” dla Droplets.

Problem polega na tym, że wraz z dojrzewaniem platformy rośnie też pokusa dokładania kolejnych warstw wygody. App Platform jest pełnym PaaS-em, który sam buduje, wdraża i skaluje aplikacje. DOCR jest natywnym prywatnym registry dla obrazów. App Platform dolicza też m.in. outbound transfer ponad pulę oraz dedykowane egress IP; DOCR ma płatne plany zaczynające się od 5 USD miesięcznie. To nie jest wada sama w sobie — to po prostu oznacza, że płacimy za komfort i skrócenie czasu operacyjnego.

Właśnie tutaj pojawia się przestrzeń dla Hetznera. Jeżeli i tak działasz już na Dockerze, masz własny pipeline CI/CD, używasz Coolify albo innego self-hosted control plane, to część „wygodnej marży” amerykańskiej platformy przestaje być konieczna. Wtedy porównanie zaczyna wygrywać nie katalog funkcji, tylko relacja kosztu do zasobu oraz miejsce osadzenia infrastruktury.

Geopolityka, prywatność i jurysdykcja

Dla polskiej firmy pytanie „gdzie fizycznie stoi serwer?” jest dziś tylko połową zagadnienia. Druga połowa brzmi: jakiej jurysdykcji podlega dostawca i jak wygląda ścieżka prawna przetwarzania danych.

Punktem wyjścia jest to, że RODO/GDPR tworzy wspólną ramę ochrony danych w UE i EOG. UODO wprost wskazuje, że przy transferach na terenie EOG nie ma potrzeby stosowania SCC, bo zarówno administratorzy, jak i procesorzy działający w EOG są objęci przepisami rozporządzenia 2016/679. UODO przypomina też równocześnie, że Komisja Europejska wydała decyzję adekwatności dla określonych podmiotów komercyjnych w USA. Innymi słowy: hosting u dostawcy amerykańskiego nie jest dziś automatycznie „nielegalny”, ale model stricte europejski bywa po prostu prostszy, czytelniejszy i łatwiejszy do obrony w compliance lub due diligence.

Tło strategiczne też jest coraz bardziej wyraźne. Parlament Europejski w opracowaniach z 2025 r. stwierdza, że europejski ekosystem cyfrowy pozostaje silnie zależny od nieeuropejskich — przede wszystkim amerykańskich — dostawców software’u i chmury. W tej samej analizie pada teza, że taka zależność tworzy strategiczne podatności, wzmacnia vendor lock-in i może zwiększać długoterminowe koszty. Parlament wskazuje przy tym wprost na ryzyka jurysdykcyjne związane z CLOUD Act.

To ważne rozróżnienie: migracja do Hetznera nie jest certyfikatem absolutnej „suwerenności cyfrowej”, ale jest realnym krokiem w stronę:

• krótszego łańcucha jurysdykcyjnego,
• mniejszej zależności od amerykańskich platform,
• prostszej komunikacji z klientami i działami compliance,
• lepszego dopasowania do europejskiej narracji o ochronie danych i strategicznej autonomii.

Hetzner dostarcza tu bardzo konkretny argument: dla lokalizacji Falkenstein, Norymberga i Helsinki zarówno dane klienta, jak i dane trzymane na serwerze pozostają w UE; spółka zaznacza też, że nie prowadzi własnych data center w USA i Singapurze, a europejskie usługi opiera na własnych parkach data center w Niemczech i Finlandii. Do tego dochodzą deklarowana zgodność z GDPR, certyfikat ISO/IEC 27001:2022 oraz certyfikacja BSI C5 Type 2.

Dla polskiego przedsiębiorcy praktyczny sens jest prosty: jeśli obsługujesz dane klientów z UE, sprzedajesz do sektora regulowanego albo po prostu chcesz ograniczyć liczbę „ale” w rozmowie z prawnikiem, audytorem lub klientem enterprise, europejski operator i europejskie regiony dają przewagę narracyjną i procesową. To nie zastępuje poprawnej konfiguracji bezpieczeństwa, ale porządkuje fundament.

Jeśli chcesz samodzielnie przetestować Hetznera, możesz skorzystać z naszego linka partnerskiego — po rejestracji otrzymasz 20 euro kredytu na start, do wykorzystania na usługi Hetzner Cloud.

Sprawdź Hetzner przez nasz link partnerski

Liczby, które robią różnicę

Żeby porównanie było uczciwe, przyjmuję prosty, konkretny setup.

Założenia:

1. Cztery serwery VPS działają stale przez cały miesiąc.
2. Każdy serwer Hetznera ma publiczne IPv4, więc doliczam oficjalne 0,50 EUR miesięcznie za Primary IPv4.
3. Dobieram parametry jak najbardziej „like for like” dla CPU, RAM i dysku.
4. Obciążenie transferem z samych VPS-ów mieści się w pakietach wliczonych w cenę.
5. Obiektowy storage obejmuje 8 bucketów, łącznie 500 GiB danych i 1 TB publicznego outboundu miesięcznie.
6. Porównuję ceny katalogowe netto, bez lokalnego VAT/sales tax.

Koszt miesięczny liczę następująco:

Poniższa tabela opiera się na oficjalnych cennikach i parametrach DigitalOcean Droplets/Spaces oraz Hetzner Cloud/Object Storage/Primary IPv4. Kurs PLN przyjmuję wg NBP z 18 maja 2026 r.; do przeliczenia USD→EUR pomocniczo używam kursu ECB z tego samego dnia.

Źródła do tabeli: parametry i ceny Droplets, transfer i pooling transferu w zespole, ceny Spaces, aktualne ceny Hetznera od 1 kwietnia 2026 r., opłata za Primary IPv4, limity/specyfikacje CPX22/32/42, kursy walut.

Co ważne, niższy koszt infrastruktury to nie jedyna korzyść na start. Rejestrując się w Hetznerze z naszego linka partnerskiego, otrzymasz 20 euro kredytu do wykorzystania na usługi cloud — więc pierwsze testy możesz wykonać bez dodatkowego obciążania budżetu.

Załóż konto i zdobądź 20 euro

Wynik jest bardzo czytelny: to około 823,79 zł miesięcznie na DigitalOcean wobec około 290,46 zł miesięcznie na Hetznerze. Miesięczna oszczędność wynosi więc około 533,33 zł, czyli około 64,7%. Rocznie mówimy o około 6 400 zł różnicy przy naprawdę zwykłym, nieprzesadnie dużym środowisku.

Warto dodać dwa ważne niuanse:

1. Jeśli obiektowy storage generuje większy publiczny outbound, przewaga Hetznera rośnie, bo DigitalOcean Spaces po przekroczeniu pakietu nalicza 0,01 USD/GiB outboundu, a Hetzner po przekroczeniu pakietu bazowego ma dużo łagodniejszy model egressu.
2. Jeśli build server nie działa stale, tylko jest uruchamiany ad hoc, to DigitalOcean częściowo odzyskuje przewagę dzięki billingowi per-second dla Droplets.

Schemat docelowej topologii dla takiego środowiska może wyglądać tak:

W praktyce taki układ dobrze pasuje do filozofii Hetznera: niskopoziomowa, przewidywalna IaaS z gotowymi aplikacjami startowymi, m.in. dla Coolify i Docker CE, ale bez próby „ukrywania” infrastruktury za warstwą PaaS.

Jak wygląda migracja w praktyce

W naszym przypadku migrowaliśmy Coolify oraz sporą grupę aplikacji produkcyjnych wraz z bazami danych. Sama operacja zamknęła się w około 6–8 godzinach pracy i przebiegła bez większych problemów. To nie znaczy, że każda migracja będzie tak gładka — ale przy dobrze przygotowanym planie jest to osiągalne.

Najważniejsza lekcja brzmi: najpierw migrujesz warstwę sterującą, potem dane, na końcu ruch. Dokumentacja Coolify i Hetznera bardzo dobrze podpowiada, dlaczego. Coolify nie ma wbudowanego „magicznego” mechanizmu przenoszenia aplikacji między hostami; trzeba ręcznie odtworzyć deploymenty, przenieść bazy i wolumeny. Co więcej, backup instancji Coolify nie obejmuje danych aplikacyjnych — obejmuje samą instancję, a APP_KEY i klucze SSH trzeba przenieść osobno. Hetzner z kolei przypomina, że przed wykonaniem finalnego backupu usługa nie powinna już przyjmować zapisów, bo inaczej część danych nie znajdzie się w kopii.

W praktyce dobrze działa następująca sekwencja:

1. Inwentaryzacja
   Spisujesz aplikacje, domeny, wolumeny, bazy, cron-y, kolejki, webhooki, zależności zewnętrzne i wszystkie sekrety.
2. Przygotowanie celu
   Zakładasz projekt w Hetznerze, tworzysz serwery, sieć prywatną, firewalle, Primary IPv4, buckety object storage i — jeśli chcesz — nową instancję Coolify z tej samej wersji co poprzednia. Hetzner ma gotową aplikację Coolify w katalogu Cloud Apps.
3. Backup warstwy control plane
   Zgrywasz backup instancji Coolify, zapisujesz APP_KEY, kopiujesz klucze SSH i konfigurację niezbędną do połączenia z hostami. Bez tego nowy panel może nie odzyskać pełnej zdolności do zarządzania serwerami.
4. Migracja danych aplikacyjnych
   Dla baz danych robisz dumpy i testowe restore’y. Dla wolumenów Dockerowych używasz bezpiecznego procesu backup/restore, a nie „gołego” kopiowania katalogu /var/lib/docker/volumes. Przy bucketach obiektowych robisz synchronizację i od razu testujesz ACL/CORS.
5. Testy na nowym środowisku
   Sprawdzasz start aplikacji, migracje schema, kolejki, joby, uploady, certyfikaty TLS, połączenia do storage’u, logowanie i monitoring.
6. Finalny cutover
   Na chwilę zamrażasz zapisy, wykonujesz ostatni delta-sync, przepinasz DNS/ruch, obserwujesz logi i metryki, a stare środowisko zostawiasz jeszcze przez okno rollbackowe.

Poniżej krótka checklista, która w takich projektach naprawdę robi różnicę:

Ta checklista wynika bezpośrednio z dokumentacji Coolify i Hetznera: backup instancji nie obejmuje danych aplikacyjnych, APP_KEY i klucze SSH są krytyczne, a snapshoty/backupy serwera nie obejmują podpiętych Volumes.

Proces można streścić tak:

W naszym projekcie ważnym elementem była też kwestia registry dla obrazów Docker. Hetzner nie daje natywnego odpowiednika DOCR jako managed usługi, więc rozwiązaliśmy to własnym, open-source’owym registry. Efekt: trochę więcej odpowiedzialności po naszej stronie, ale bez dodatkowego abonamentu. To typowy kompromis „mniej magii platformy, więcej kontroli i niższy rachunek”. Na DigitalOcean podobną funkcję pełni DOCR, którego płatne plany zaczynają się od 5 USD miesięcznie.

Gdzie Hetzner nie wygrywa

Żeby ten wpis był uczciwy, trzeba powiedzieć wprost: Hetzner nie jest lepszy we wszystkim.

Po pierwsze: mniej PaaS-u i mniej gotowych warstw „managed”.

DigitalOcean App Platform to pełnoprawny PaaS, który sam buduje, wdraża i skaluje aplikacje. Hetzner daje raczej świetne klocki infrastrukturalne i kilka gotowych aplikacji startowych, ale nie przykrywa całego procesu warstwą PaaS. Jeśli zespół nie ma kompetencji operacyjnych, to DigitalOcean może być wygodniejszy.

Po drugie: brak natywnej, zarządzanej usługi registry analogicznej do DOCR.

DigitalOcean ma prywatny registry z planami od 5 USD do 20 USD miesięcznie. W Hetznerze najczęściej trzeba postawić własne registry albo użyć zewnętrznej usługi. To obniża koszt abonamentowy, ale zwiększa odpowiedzialność operacyjną.

Po trzecie: Object Storage Hetznera jest S3-compatible, ale nie S3-identical.

W oficjalnej dokumentacji Hetzner wprost wymienia brak wsparcia m.in. dla Notifications, Website, Analytics, Logging, Metrics, Replication, Tagging i custom domains dla bucketów. Jeśli dziś korzystasz z takich funkcji albo z wygody typu built-in CDN w Spaces, migracja wymaga dodatkowej warstwy: reverse proxy, CDN, event busa albo własnej logiki.

Po czwarte: więcej odpowiedzialności za backup i odtwarzanie.

Hetzner daje snapshoty i backupy serwerów, ale dokumentacja przypomina, że nie obejmują one podpiętych Volumes. To oznacza, że strategia backupu nadal musi być świadomie zaprojektowana: osobno bazy, osobno wolumeny, osobno object storage i testowe restore’y.

Po piąte: wynik kosztowy zależy od wzorca użycia.

Moje porównanie zakłada build server działający przez cały miesiąc. Jeśli w Twojej organizacji build node włącza się tylko na czas joba, DigitalOcean częściowo odzyskuje przewagę dzięki billingowi per-second. Z drugiej strony, jeśli Twoje workloady są ARM-compatible, Hetzner może być jeszcze tańszy dzięki rodzinie CAX.

Krótko mówiąc: Hetzner wygrywa tam, gdzie chcesz taniej i bardziej świadomie zarządzać IaaS-em. DigitalOcean nadal wygrywa tam, gdzie chcesz kupić wygodę i skrócić odpowiedzialność operacyjną.

Co powinna zrobić polska firma teraz

Jeśli miałbym zamknąć ten temat w jednym zdaniu, powiedziałbym tak: dla wielu polskich firm utrzymujących własne aplikacje kontenerowe migracja z DigitalOcean do Hetznera jest dziś sensowna ekonomicznie i obroniona procesowo.

Szczególnie warto ją rozważyć, gdy:

• masz już Docker, CI/CD i podstawowe kompetencje operacyjne;
• nie jesteś silnie uzależniony od App Platform i innych usług PaaS;
• trzymasz dane klientów z UE i chcesz uprościć narrację compliance;
• rosną Ci rachunki nie od „surowych VM-ek”, ale od całego otoczenia managed;
• chcesz świadomie zmniejszyć zależność od amerykańskich dostawców.

Z kolei ostrożniej podchodziłbym do migracji, jeśli:

• używasz głęboko App Platform lub innych wygodnych warstw, które trzeba będzie odtworzyć;
• polegasz na funkcjach object storage wykraczających poza podstawową zgodność z S3;
• nie masz procesu backup/restore, testów smoke i planu rollbacku;
• Twoje workloady są krótkotrwałe i dużo korzystają z per-second billing.

Dla ROI sprawa jest prosta:

Jeśli przyjąć konserwatywnie koszt pracy inżynierskiej na poziomie 250 zł/h i czas projektu 6–8 godzin, to zwrot z samej oszczędności infrastrukturalnej następuje po około 2,8–3,8 miesiąca. To bardzo krótki horyzont jak na zmianę, która jednocześnie porządkuje temat kosztu, jurysdykcji i niezależności technologicznej.

Różnica w kosztach jest widoczna już przy niewielkim setupie, a na start można ją jeszcze dodatkowo „zamortyzować”: rejestrując się z naszego linka partnerskiego, otrzymasz 20 euro kredytu do wykorzystania na produkty Hetzner Cloud.

Załóż konto w Hetznerze

Jeżeli Twoja firma chce płacić mniej, uproszczyć temat jurysdykcji danych i przenieść się do europejskiej chmury bez operacyjnego chaosu, to warto ten ruch policzyć już teraz. Pomożemy przygotować realny model TCO, ocenić zależności od usług managed, zaprojektować architekturę docelową i przeprowadzić migrację tak, żeby zamknęła się w przewidywalnym oknie, z backupem, rollbackiem i testami odtworzeniowymi.