Większość hostingów współdzielonych kończy się na panelu i menedżerze plików. MyDevil idzie o krok dalej - dostajesz SSH i własne narzędzie CLI o nazwie devil, przez które zarządzasz domenami, bazami i certyfikatami. Pod spodem znajduje się niestandardowy jak na dzisiejsze czasy system FreeBSD, a subskrypcja zaczyna się od 20 zł/mies. Ta recenzja odpowiada na pytanie: dla kogo to ma sens i gdzie zaczyna boleć.
Zanim przejdziemy dalej: MyDevil wykupił przestrzeń reklamową na 4programmers.net - w tym kontekście 4programmers zaproponowało im tę recenzję. Treść pisałem samodzielnie i MyDevil nie miał na nią żadnego wpływu. Poświęciłem na tę recenzję około 13 godzin testowania i dostałem za to wynagrodzenie od 4programmers. Nie jestem ekspertem tego narzędzia - to wrażenia z tego okresu, a nie wyczerpujący przegląd platformy.
Dla kogo jest ten produkt?
Produkt MyDevil, jak można się spodziewać, działa w określonych ramach, więc nie każdy projekt się w nie wpasuje i warto to wiedzieć przed zakupem. Z tego względu ta usługa jest przeznaczona do prostych rozwiązań, które mają działać stabilnie bez ciągłego majstrowania przy konfiguracji. Dość sporym bonusem do tych ram jest dostęp przez SSH, co nie udostępnia całego serwera jak w rozwiązaniach VPS, ale jednak rozszerza możliwości wykorzystania hostingu, przy założeniu, że użytkownik ma świadomość jak używać ssh i powłoki.
Pasuje dobrze dla:
- Solo-dewelopera z kilkoma projektami - jedno konto obsługuje wiele domen jednocześnie, każda z osobną konfiguracją.
- Freelancera utrzymującego strony klientów w PHP, Node.js lub innych - zmiana wersji środowiska per-domena bez konfliktów między projektami.
- Dewelopera, który chce czegoś więcej niż typowy shared hosting - długo żyjące procesy, crony, PostgreSQL, MongoDB, własna poczta i FTP w jednym miejscu.
- Projektów, które wyrosły z darmowych tierów - gdy Vercel lub Netlify przestają wystarczać, ale chmura to jeszcze za dużo.
Nie pasuje dla:
- Kogoś, kto potrzebuje Dockera lub roota - MyDevil to wciąż shared hosting; nie postawisz własnych kontenerów ani nie zmienisz parametrów kernela.
- Projektu z ambicją skalowania - jeden region (Polska), brak IaC, bez poziomego skalowania.
- Kogoś bez minimalnych podstaw technicznych - panel wystarczy do prostych rzeczy, ale przy bardziej zaawansowanych tematach (własne crony, konfiguracja Node.js, debugging procesów) terminal jest nieunikniony.
Jak wyglądał testowy workflow?
Testowałem na prostej aplikacji Node.js. Pierwszym krokiem było dodanie domeny przez CLI:
chmod +x index.js
devil www add 17.sesja.linuksowa.pl nodejs /home/jbosak/repo/index.js
To samo można zrobić z poziomu panelu - dodanie strony to kilka kliknięć, kod wrzuca się przez wbudowany menedżer plików. Oba podejścia działają i oba stają się szybsze z każdym kolejnym projektem.
Próbowałem też uruchomić aplikację napisaną w Next.js, ale dokumentacja opisuje obsługę Node.js jako uruchamianie z pojedynczego pliku index.js - przez co nie byłem w stanie wystartować serwera aplikacji. Napisałem do supportu i po 30 minutach miałem odpowiedź. Rozwiązaniem okazała się rezerwacja portu, uruchomienie aplikacji na tym porcie, a następnie ustawienie strony w trybie proxy w panelu. Nie było to dla mnie oczywiste: dokumentacja Node.js wskazuje inne podejście, a opis trybu proxy skupia się na tym, jak go uruchomić, nie na tym, kiedy i do czego go użyć.
Bazę PostgreSQL założyłem przez panel - dwa pola, jeden przycisk. To samo można zrobić przez devil pgsql add. Początkowo próbowałem użyć phpPgAdmin z przeglądarki, ale to narzędzie nie przypadło mi do gustu przez dość kiepski user experience. Na szczęście, w dokumentacji znalazłem informacje o tym, że z użyciem tunelowania SSH można łatwo podłączyć się do bardziej nowoczesnych narzędzi, które można uruchomić na swoim komputerze i swobodnie korzystać z bazy danych.
SSL to 3 kliknięcia w panelu administratora. Po odświeżeniu strona jest zabezpieczona - bez ręcznej konfiguracji certbota, bez crona odnawiającego certyfikat.
Po każdej zmianie kodu restart jest ręczny: kliknięcie w panelu albo devil www restart 17.sesja.linuksowa.pl. Liczyłem na automatyczne odświeżanie po zmianie pliku - tej funkcji nie ma, ale nie traktuję tego jako deal-breaker, bo da się to obejść: własnym skryptem lub cronem wywołującym restart, albo mechanizmem restart.txt dla aplikacji Ruby i Python.
Pierwszy setup zajął mi około godziny. Panel i devil na początku przytłaczają - nowe pojęcia, inny model zarządzania aplikacjami niż na VPS czy w chmurze. Każdy z procesów z osobna jest prosty, ale razem tworzą środowisko, do którego trzeba się przyzwyczaić. Każde kolejne wdrożenie to już czas poniżej 10 minut.
Co realnie poprawia?
MyDevil wyróżnia się przede wszystkim zestawem narzędzi, które są dostępne od razu, bez dopłat i bez konfigurowania zewnętrznych usług.
Konto pocztowe zakłada devil mail add - bez konfigurowania zewnętrznego SMTP ani SPF w osobnym dashboardzie. Na typowym hostingu poczta transakcyjna to osobna usługa (Mailgun, Resend), tutaj jest w pakiecie.
Backupy tworzone są automatycznie raz dziennie i trzymane przez 14 dni - dostępne bezpośrednio z poziomu konta, więc sprawdza się to bardzo dobrze do szybkiego revertu zmian z ostatnich kilku dni. Platforma utrzymuje też backup zdalny w innej serwerowni, w innym mieście. To lepsza historia niż większość shared hostingów, które trzymają backupy wyłącznie lokalnie - choć nadal nie zastępuje własnego backupu poza platformą.
Cronjobs są dostępne z panelu i przez devil cron add, ale w tym przypadku użycie panelu ma mały sens, bo sam cron to najczęściej wywołanie komendy bashowej lub skryptu, który powinien zostać napisany i przetestowany z poziomu CLI. Dla projektu, który potrzebuje regularnych zadań, to duża zaleta w porównaniu do typowego shared hostingu.
Przy wersjonowaniu środowisk warto zajrzeć do dokumentacji - dla danej technologii może odbywać się to w mniej standardowy sposób. W przypadku Node.js jednorazowo ustawia się globalny katalog npm i PATH w .bash_profile, a każda zmiana wersji to podmiana symlinka w ~/bin. Działa, ale wymaga chwili, żeby się z tym zapoznać.
Liczba wspieranych technologii w porównaniu do konkurencji jest imponująca. Oprócz standardowych, jak na przykład Wordpress, PHP, Node.js, Python, Ruby, Java czy Perla, znajdziemy tu też Rust, C/C++, Go, .NET, Lua, a nawet mniej typowe języki jak OCaml, D, V, Zig czy Crystal - rzeczy, których próżno szukać u konkurencji.
MyDevil nie limituje liczby stron WWW ani baz danych w ramach konta. W przypadku braku miejsca na dysku można w każdej chwili dokupić dodatkową przestrzeń do planu - bez migracji, bez zmiany środowiska.
Dla osób, które nie posługują się płynnie językiem angielskim - dokumentacja i support są po polsku.
SSH na MyDevil to prawdziwe konto systemowe, nie wirtualizacja - dostępnych jest wiele poleceń systemowych, choć bez roota. Rezerwacja portów i mechanizm proxy www to funkcje, które na pierwszy rzut oka wyglądają niszowo, ale w praktyce okazują się kluczowe - to właśnie przez proxy uruchomiłem Next.js, a ten sam mechanizm pozwala wystawić pod ruchem www dowolną aplikację obsługującą HTTP: uruchamiasz ją na zarezerwowanym porcie, a ruch przekierowujesz przez proxy.
Co najbardziej irytuje po czasie?
SLA MyDevil gwarantuje dostępność na poziomie 99,70%, co przekłada się na ~26 godzin potencjalnego downtime'u rocznie. Większość współczesnych cloud providerów gwarantuje 99,9% lub więcej - warto mieć to w głowie przy projektach, gdzie dostępność jest krytyczna.
Na stronie hostingu widać ładnie wyeksponowane wsparcie dla nowoczesnych technologii - Elixir, Kotlin, Go, Rust i innych. W praktyce okazuje się, że brakuje jakiejkolwiek dokumentacji dotyczącej tych języków w kontekście stron www - ani jak je wystawić pod ruchem, ani jak zarządzać ich wersjami. Rozwiązanie dla strony www istnieje: mechanizm proxy pozwala uruchomić dowolną aplikację HTTP na wcześniej zarezerwowanym porcie, ale nigdzie nie jest napisane, że to właśnie ta ścieżka.
Logi aplikacji www są dostępne z CLI w /home/USER/domains/DOMAIN/logs. Z logami cronjobów było trudniej - szukałem ich w panelu, przez SSH i w dokumentacji, bez rezultatu. Dopiero support wyjaśnił, że do odczytu logów crona używa się komendy mail. W FreeBSD to standardowe narzędzie do tego celu, ale dla kogoś przyzwyczajonego do Linuxa - nieoczywiste. Można też przekierować wyjście crona do pliku, dodając przekierowanie bezpośrednio w definicji taska. Problem nie leży w braku logów, ale w tym, że mechanizm jest praktycznie nieudokumentowany - bez pytania supportu ciężko na to wpaść, ale dostałem informacje, że planują to dodać do panelu. Logi systemowe są za permission denied, co jest konsekwencją shared hostingu.
Nie każdy się z tym zgodzi, ale ja uważam, że przydałoby się tu systemd. FreeBSD używa innego systemu init, przez co odpada journalctl, systemctl i cały ekosystem narzędzi, do których przyzwyczajony jest każdy, kto pracował na Linuxie. Crony, logi, procesy - wszystko wymaga nauczenia się innego podejścia. Nie jest to nie do przejścia, ale dla dewelopera z linuksowym backgroundem to realne tarcie.
Co jest overrated?
Marketingowym wyróżnikiem jest narzędzie CLI pod nazwą devil, ale przez to, że niektóre rzeczy dużo łatwiej zrobić z panelu, moje używanie hostingu polegało na skakaniu między tymi dwoma sposobami w zależności od zadania. Panel jest wygodniejszy przy prostych operacjach, CLI przy powtarzalnych. Żadne z nich nie daje pełnej kontroli: panel ma ograniczone opcje customizacji, a CLI jest związane brakiem roota i zakresem komend, do których devil został zaprojektowany.
FreeBSD jako cecha techniczna platformy brzmi imponująco, ale dla dewelopera bez uprawnień roota, jest to głównie szczegół implementacyjny. Największym ograniczeniem jest właśnie brak uprawnień administratora, bo przez to nie ma dostępu do systemu w stopniu, który pozwoliłby wykorzystać FreeBSD - czyli swobodne używanie pkg, Podmana, czy własnych reguł iptables.
Szerokie wsparcie technologii to realna przewaga, ale lista języków na stronie jest obietnicą bez instrukcji obsługi - dotarcie do tego, jak uruchomić Go czy Rusta pod ruchem www, wymagało w moim przypadku kontaktu z supportem, a nie tylko przeczytania docs.
Alternatywy
Hetzner Web Hosting - prawdopodobnie droższy (zależnie od wybranego planu), z węższą ofertą technologiczną: głównie PHP, Node.js i gotowe aplikacje jak WordPress, Drupal czy Matomo. Hetzner nie oferuje żadnej gwarancji dostępności dla usług web hostingu - pod tym kątem MyDevil (99,70% SLA) wypada lepiej.
Hetzner VPS - porównywalny cenowo, z SLA na poziomie 99,9%, ale wymaga samodzielnego zarządzania serwerem. Dla kogoś, kto ma czas i czuje się komfortowo z administracją, to więcej kontroli za podobne pieniądze.
DigitalOcean nie ma porównywalnego shared hostingu. Można tam postawić aplikację PHP lub WordPressa, ale za wyraźnie wyższą cenę i bez takiej różnorodności usług - poczty, cronów, FTP, wielu wersji środowisk - które są dostępne w MyDevil od razu.
Mikrus to ciekawa alternatywa dla osób, które chcą eksperymentować i pogłębiać wiedzę o serwerach. Tanie VPS-y, społecznościowy charakter platformy - dobry wybór do nauki, nie do produkcji.
GitHub Pages to najtańsza opcja na tej liście - darmowa, ale też najbardziej ograniczona. Hostuje wyłącznie strony statyczne: brak bazy danych, poczty, procesów serwerowych. Jeśli projekt nie potrzebuje niczego z powyższego, to wystarczy i nie ma sensu płacić za coś więcej.
MyDevil ma sens wtedy, gdy potrzebujesz więcej niż statyczny hosting, ale nie chcesz samodzielnie zarządzać VPS-em.
Czy kupiłbyś to ponownie za własne pieniądze i dla kogo byś to rekomendował?
Dla prostych projektów, które potrzebują bazy danych, poczty, cronów - za 20zł lub 40 zł miesięcznie dostałem pocztę, crony i backupy - bez dokupowania osobnego Mailguna ani zewnętrznych backupów. Gdybym rozwijał strony dla małych lokalnych firm, które potrzebują gwarantowanej dostępności bez konieczności samodzielnego zarządzania serwerem, z pewnością bym go rozważył.
Nie rekomendowałbym go projektom wymagającym skalowalności, Dockera lub zaawansowanego CI/CD. Nie jest też optymalnym miejscem do hostowania statycznych plików - do tego wystarczy GitHub Pages lub podobne rozwiązanie za darmo.
To są moje wrażenia - jeśli masz więcej doświadczenia z MyDevil albo uważasz, że coś tu jest niezgodne z rzeczywistością, zapraszam do komentarzy.
