Hosting aplikacji Laravel w Polsce – hosting współdzielony, VPS czy chmura?

Dla firmowej aplikacji Laravel najczęściej najlepszym wyborem jest VPS lub serwer w chmurze z centrum danych w Polsce albo innym kraju UE, z dostępem SSH, stałymi procesami dla kolejek, harmonogramem zadań i Redisem. Hosting współdzielony wystarcza tylko dla prostych stron i paneli bez kolejek i długotrwałych procesów. Chmura z usługami zarządzanymi (baza, cache, kolejki jako usługa) opłaca się przy zmiennym ruchu i wysokich wymaganiach dostępności, ale jest droższa i bardziej złożona. Ważniejsze od typu serwera jest to, kto odpowiada za aktualizacje, kopie zapasowe i monitoring.

Czego potrzebuje aplikacja Laravel na produkcji

Laravel na komputerze programisty i Laravel w produkcji to dwa różne środowiska. Na serwerze aplikacja biznesowa zwykle potrzebuje:

• Aktualnego PHP – wspierane wersje frameworka (Laravel 13) wymagają co najmniej PHP 8.3, a kolejne wydania mogą podnieść ten próg; dokładną minimalną wersję i wymagane rozszerzenia sprawdź w dokumentacji wydania, którego używasz.
• Serwera WWW i PHP-FPM – najczęściej Nginx, z konfiguracją wskazującą na katalog public, a nie na główny katalog projektu.
• Bazy danych – MySQL, MariaDB lub PostgreSQL, z regularnymi kopiami.
• Harmonogramu zadań – jeden wpis w cronie uruchamiający co minutę polecenie schedule:run, które odpala zadania zdefiniowane w aplikacji (raporty, synchronizacje, czyszczenie danych).
• Workerów kolejek – stałych procesów queue:work, pilnowanych przez Supervisor lub systemd, które przetwarzają maile, importy i integracje w tle.
• Redisa – jako magazynu cache, sesji i kolejek; przy Redisie można użyć Laravel Horizon do podglądu i sterowania kolejkami.
• Certyfikatu TLS, logów i miejsca na pliki – lokalnie lub w magazynie obiektowym zgodnym z S3.

Punkty 4 i 5 najczęściej decydują o typie hostingu. Aplikacja, która synchronizuje dane z ERP albo wysyła powiadomienia, bez działających kolejek i crona po prostu nie będzie robić tego, do czego powstała.

Hosting współdzielony, VPS czy chmura

Hosting współdzielony

Tani i prosty, ale zaprojektowany z myślą o stronach WWW. Wielu dostawców udostępnia SSH, Composer i cron, jednak zwykle nie pozwala uruchamiać stałych procesów, nie daje Redisa albo ogranicza czas wykonania skryptów. Kolejki można wtedy obsługiwać tylko prowizorycznie, np. uruchamiając workera z crona co minutę. Współdzielony hosting wystarczy dla wizytówki na Laravelu, prostego formularza lub wewnętrznego narzędzia dla kilku osób. Dla portalu B2B, CRM czy integracji – nie.

VPS

Wirtualny serwer z pełnym dostępem administracyjnym. Instalujesz dokładnie to, czego potrzebuje aplikacja: wybraną wersję PHP, Redisa, Supervisora, własne reguły firewalla. To najczęstszy wybór dla aplikacji firmowych średniej wielkości – przewidywalny koszt, pełna kontrola i centra danych w Polsce u wielu dostawców. Cena tej kontroli: ktoś musi serwer administrować. Niezarządzany VPS bez opiekuna to ryzyko, a nie oszczędność.

Chmura

Pod tym słowem kryją się dwie rzeczy. Pierwsza to po prostu maszyny wirtualne u dużego dostawcy – z punktu widzenia Laravela działa to jak VPS. Druga to architektura z usługami zarządzanymi: baza danych jako usługa, zarządzany Redis, magazyn plików, kilka instancji aplikacji za load balancerem, automatyczne skalowanie. Ma to sens, gdy aplikacja musi działać mimo awarii pojedynczej maszyny albo ruch skacze kilkukrotnie w określonych godzinach. Dla typowego panelu B2B z przewidywalnym ruchem to często przerost formy – płacisz za złożoność, której nie wykorzystasz.

Szczegóły konfiguracji, którą proponujemy klientom, opisujemy na stronie hosting pod Laravel w Polsce.

Wdrożenia bez przestojów

Nowa wersja aplikacji nie powinna oznaczać komunikatu „przerwa techniczna” w środku dnia. Standardowy proces wygląda tak:

• Kod trafia na serwer do nowego, osobnego katalogu wydania, a nie nadpisuje działającej wersji.
• W tym katalogu instalowane są zależności i budowane zasoby frontendu.
• Uruchamiane są migracje bazy – zaprojektowane tak, żeby stara wersja kodu nadal działała na nowej strukturze (np. nowa kolumna najpierw jako opcjonalna).
• Dowiązanie symboliczne „current” przełącza się na nowy katalog, a PHP-FPM jest przeładowywany.
• Workery kolejek są restartowane poleceniem queue:restart, żeby pobrały nowy kod.
• Przy problemie przełączasz dowiązanie z powrotem na poprzednie wydanie.

Ten schemat realizują narzędzia typu Deployer lub pipeline CI/CD. Tryb konserwacji (artisan down) zostaje na wyjątkowe sytuacje, np. długą migrację danych. Więcej o zasadach bezpiecznych wdrożeń piszemy w artykule bezpieczne wdrożenia Laravel w firmie.

Kopie zapasowe i monitoring

Kopia, której nikt nie odtworzył, jest tylko nadzieją. Minimalny standard dla aplikacji biznesowej:

• codzienna kopia bazy danych i plików użytkowników, przechowywana poza serwerem produkcyjnym, najlepiej u innego dostawcy lub w innej lokalizacji,
• określony czas przechowywania kopii, zgodny z polityką firmy i zasadą minimalizacji danych,
• test odtworzenia wykonywany co najmniej raz na kwartał na osobnym środowisku,
• monitoring dostępności z zewnątrz, który alarmuje, gdy strona nie odpowiada,
• monitoring kolejek i crona – alert, gdy zadania się nie wykonują lub kolejka rośnie,
• zbieranie błędów aplikacji w narzędziu, które grupuje wyjątki i powiadamia zespół.

Najczęstsza awaria, którą widzimy, nie polega na tym, że serwer przestał działać. Polega na tym, że worker kolejki zatrzymał się kilka dni temu i nikt tego nie zauważył, bo strona się otwierała. Dlatego monitoring samej dostępności strony to za mało – trzeba obserwować także to, co dzieje się w tle: czas oczekiwania zadań w kolejce, liczbę nieudanych zadań i godzinę ostatniego wykonania każdej synchronizacji.

Środowisko testowe i zabezpieczenie serwera

Serwer produkcyjny to nie miejsce na sprawdzanie nowych funkcji. Nawet przy niewielkiej aplikacji warto utrzymywać osobne środowisko testowe (staging) z tą samą wersją PHP, bazy i Redisa co produkcja. Tam zespół i osoby z biznesu sprawdzają zmiany przed wdrożeniem, a migracje bazy są testowane na kopii danych – po ich zanonimizowaniu, jeśli zawierają dane osobowe. Staging może stać na mniejszym i tańszym serwerze, byle konfiguracja była zgodna.

Sam serwer produkcyjny wymaga kilku podstawowych zabezpieczeń, niezależnie od dostawcy:

• logowanie przez SSH wyłącznie kluczem, bez hasła, i bez bezpośredniego logowania na konto root,
• firewall przepuszczający tylko potrzebne porty, a baza danych i Redis niedostępne z internetu,
• plik .env z hasłami i kluczami poza katalogiem publicznym, z trybem debugowania wyłączonym na produkcji,
• automatyczne aktualizacje bezpieczeństwa systemu lub stały harmonogram ich instalowania,
• osobne konta i klucze dla każdej osoby z dostępem, usuwane po zakończeniu współpracy.

To lista minimalna, a nie pełny audyt bezpieczeństwa, ale jej brak widać w większości problemów, z którymi trafiają do nas firmy po przejęciu aplikacji od poprzedniego wykonawcy.

RODO i lokalizacja danych

Aplikacje B2B przechowują dane osobowe – osób kontaktowych, użytkowników portalu, pracowników. Hostingodawca przetwarza je w Twoim imieniu, więc potrzebujesz z nim umowy powierzenia przetwarzania danych zgodnej z art. 28 RODO. Większość dostawców udostępnia gotowy wzór.

Sprawdź też, gdzie fizycznie są dane. Serwer w Polsce lub innym kraju Europejskiego Obszaru Gospodarczego upraszcza sprawę, bo nie ma przekazania danych do państwa trzeciego. Jeśli jakakolwiek usługa (kopie, poczta transakcyjna, monitoring błędów) przetwarza dane poza EOG, potrzebna jest podstawa przekazania zgodna z rozdziałem V RODO. Ostateczną ocenę warto skonsultować z prawnikiem lub inspektorem ochrony danych, bo zależy ona od konkretnych usług i umów.

Kto odpowiada za aktualizacje

To pytanie warto zadać przed wyborem hostingu, bo odpowiedź zmienia się w zależności od modelu:

• Hosting współdzielony: system i PHP aktualizuje dostawca, ale możesz nie mieć wpływu na termin zmiany wersji PHP; aktualizacje Laravela i pakietów są po Twojej stronie.
• VPS niezarządzany: wszystko jest po Twojej stronie – system operacyjny, PHP, baza, Redis, firewall, certyfikaty.
• VPS zarządzany lub opieka software house'u: system i usługi aktualizuje opiekun serwera, aplikację – zespół, który ją rozwija; zakres musi być opisany w umowie.
• Chmura z usługami zarządzanymi: bazę i cache aktualizuje dostawca chmury, maszyny i aplikację – Ty lub Twój partner.

W każdym wariancie ktoś musi regularnie aktualizować zależności aplikacji i planować przejście na nowsze wersje PHP oraz Laravela, zanim stare stracą wsparcie bezpieczeństwa. Jeśli ten ktoś nie jest wskazany z nazwiska lub nazwy firmy, w praktyce nie robi tego nikt.

Następny krok

Zanim wybierzesz serwer, spisz: czy aplikacja używa kolejek i harmonogramu, ile ma użytkowników w szczycie, jak długo może być niedostępna i kto będzie ją administrował. Te cztery odpowiedzi zwykle wystarczą, żeby dobrać wariant. Jeśli budujesz lub rozwijasz aplikację z software house'em Laravel, ustal od razu, czy hosting i utrzymanie wchodzą w zakres współpracy. Możesz też zapytać nas o konfigurację dla swojego projektu.