Nginx czy Apache dla aplikacji Laravel?
W nowych projektach wybieramy Nginx — jest szybszy przy plikach statycznych, lepiej znosi współbieżność i świetnie współpracuje z PHP-FPM. Apache ma sens, gdy projekt korzysta z .htaccess, istnieje już infrastruktura Apache albo hosting współdzielony nie daje wyboru. W obu przypadkach kluczem do wydajności jest PHP-FPM — proces, który realnie wykonuje kod PHP. W tym artykule porównuję serwery, pokazuję konfigurację i wyjaśniam, jak dobrać zasoby, żeby aplikacja działała szybko i stabilnie.
Nginx czy Apache — porównanie dla Laravel
| Kryterium | Nginx | Apache |
|---|---|---|
| Model pracy | Asynchroniczny, zdarzeniowy | Procesy/wątki (prefork, worker, event) |
| Pliki statyczne | Bardzo szybkie | Dobre, wolniejsze przy dużym ruchu |
| Konfiguracja | Centralna, per projekt | .htaccess w katalogach |
| PHP | Przez PHP-FPM | PHP-FPM lub mod_php |
| Pamięć przy dużym ruchu | Zużywa znacznie mniej | Wyższe zużycie przy wielu połączeniach |
| Hosting współdzielony | Rzadziej domyślny | Standard |
| Kiedy wybierać | Nowe projekty, VPS, kontenery | Legacy, .htaccess, proste hostingi |
Najważniejsze: Domyślny wybór dla Laravel to Nginx plus PHP-FPM. Apache wybierz, gdy musisz — z powodu infrastruktury, .htaccess albo ograniczeń hostingu. W obu konfiguracjach wąskim gardłem bywa nie serwer WWW, a liczba procesów PHP-FPM i pamięć RAM serwera.
Jak działa PHP-FPM i dlaczego to on decyduje o wydajności
Serwer WWW (Nginx/Apache) przyjmuje żądania i przekazuje te dotyczące PHP do PHP-FPM — menedżera procesów PHP. To PHP-FPM wykonuje cały kod Laravela. Jego konfiguracja — liczba procesów potomnych — decyduje o tym, ile żądań aplikacja obsłuży równocześnie.
Najważniejsze parametry
- pm.max_children — maksymalna liczba procesów PHP. Najczęstszy błąd to wartość za mała (żądania czekają w kolejce) albo za duża (serwer wpada w swap).
- pm.start_servers, pm.min_spare_servers, pm.max_spare_servers — pula gotowych procesów w trybie dynamic.
- pm.max_requests — ile żądań obsłuży proces przed restartem; chroni przed wyciekami pamięci.
Praktyczny wzór na max_children to dostępna pamięć dla PHP podzielona przez średnie zużycie pamięci przez proces (dla aplikacji Laravel to często 40–80 MB). Przykład: 2 GB RAM dla PHP przy 60 MB na proces to około 30 procesów — z zapasem ustawiamy 25–30.
Konfiguracja Nginx dla Laravel
Kluczowe elementy serwera dla aplikacji Laravel
- root wskazuje na katalog public — nigdy na katalog główny projektu.
- try_files przekierowuje wszystkie żądania do index.php — obsługa routingu Laravela.
- location ~ .php$ przekazuje żądania do PHP-FPM przez gniazdo.
- Blokada dostępu do plików ukrytych i katalogów zaplecza.
- Osobna obsługa plików statycznych z długim cache — offload z PHP.
Przykładowa konfiguracja wygląda tak.
server {
listen 443 ssl http2;
server_name example.com;
root /var/www/example.com/public;
index index.php;
charset utf-8;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.4-fpm.sock;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
include fastcgi_params;
}
location ~ /\.(?!well-known).* {
deny all;
}
}
Do tego HTTPS z Let's Encrypt, HTTP/2 (a najlepiej HTTP/3), kompresja Brotli/gzip dla tekstów i nagłówki cache dla assetów z Vite. Więcej o budowie assetów piszemy w artykule o Node.js w projektach Laravel.
Kiedy Apache ma sens?
- .htaccess — jeśli projekt (lub jego część) opiera się na regułach w .htaccess, Apache działa „z pudełka", a Nginx wymaga przeniesienia reguł do konfiguracji serwera.
- Hosting współdzielony — większość tanich hostingów w Polsce to Apache/LiteSpeed; wybór należy do dostawcy.
- Zespół i narzędzia — organizacje z wieloletnią infrastrukturą Apache rzadko zyskają na zmianie więcej, niż kosztuje migracja.
- Moduły — specyficzne moduły Apache (np. uwierzytelnianie LDAP w intranecie) bywają trudne do zastąpienia.
W nowych projektach na VPS i w kontenerach praktycznie zawsze wybieramy Nginx — głównie ze względu na niższe zużycie pamięci przy wielu równoczesnych połączeniach.
VPS, hosting współdzielony czy kontenery?
- Hosting współdzielony — wystarcza dla prostych stron i małych aplikacji bez kolejek i Redisa. Ograniczenia: brak kontroli nad konfiguracją, wspólne zasoby, często brak SSH.
- VPS — pełna kontrola, możliwość konfiguracji Nginx, PHP-FPM, Redisa, kolejek i cron. To nasz standard dla aplikacji produkcyjnych.
- Kontenery (Docker) — powtarzalne środowiska, łatwe skalowanie i przenoszenie między serwerami. Wymagają wiedzy operacyjnej i pipeline'u wdrożeniowego.
Automatyzację wdrożeń na takich środowiskach opisujemy w artykule CI/CD i DevOps dla aplikacji Laravel.
Bezpieczeństwo i utrzymanie serwera
- Aktualizacje systemu i PHP — regularne, najlepiej automatyczne dla poprawek bezpieczeństwa.
- Firewall — otwarte tylko 80/443 i SSH (najlepiej z ograniczeniem po IP lub kluczami).
- Backupy — bazy danych codziennie, plików wg potrzeb; backup, którego nie testowałeś przywracania, nie istnieje.
- Monitoring — obciążenie, pamięć, miejsce na dysku, czasy odpowiedzi; alerty zanim skończy się miejsce albo RAM.
- Logi i rotacja — access/error logi serwera i logi aplikacji z rotacją, żeby nie zapełniły dysku.
Serwer bez monitoringu to awaria, która czeka na dogodny moment. W usłudze utrzymania i modernizacji kodu konfigurujemy monitoring, backupy i procedury operacyjne dla aplikacji produkcyjnych.
Ile kosztuje konfiguracja serwera?
- Konfiguracja VPS od zera (Nginx, PHP-FPM, baza, Redis, SSL, backupy) — 1–2 dni, orientacyjnie 1 500–4 000 zł netto + VAT.
- Optymalizacja istniejącego serwera (PHP-FPM, cache, bazy) — 1–3 dni, 1 000–5 000 zł.
- Migracja między serwerami lub hostingiem — 1–2 dni zależnie od złożoności, od 2 000 zł.
- Koszt samego VPS — od ok. 20–100 zł miesięcznie dla typowej aplikacji biznesowej.
Chcesz przenieść aplikację na własny serwer albo przyspieszyć istniejącą infrastrukturę?
Opisz projekt w formularzu — wycena jest bezpłatna.
Najczęściej zadawane pytania
Nginx czy Apache dla Laravel — co wybrać?
Do nowych projektów — Nginx z PHP-FPM: jest szybszy i zużywa mniej pamięci przy dużym ruchu. Apache wybierz, gdy projekt opiera się na .htaccess, hosting nie daje wyboru albo istniejąca infrastruktura już działa na Apache. Laravel działa identycznie na obu.
Ile procesów PHP-FPM powinienem ustawić?
Podziel pamięć przeznaczoną dla PHP przez średnie zużycie pamięci przez proces (typowo 40–80 MB dla Laravela). Przykład: 2 GB / 60 MB ≈ 33, z zapasem ustaw 25–30. Obserwuj metryki — kolejka żądań oznacza za mało procesów, swap i OOM — za dużo.
Czy hosting współdzielony wystarczy dla Laravel?
Do prostych aplikacji bez kolejek i przy małym ruchu — często tak (wymagany PHP 8.2+, MySQL, cron). Do projektów z Redisem, kolejkami, większym ruchem i wymaganiami wydajnościowymi potrzebny jest VPS lub kontenery.
Po co Laravelowi Node.js na serwerze?
Do budowania assetów (Vite), opcjonalnie do SSR (Inertia/React) i do serwera WebSocketów (Laravel Reverb). Backend aplikacji pozostaje w PHP — Node pełni role pomocnicze, które opisuję w osobnym artykule.
Jak zabezpieczyć serwer z aplikacją Laravel?
Firewall (tylko 80/443/SSH), aktualizacje systemu i PHP, HTTPS, brak publicznego dostępu do bazy i Redisa, backupy z testem przywracania, monitoring z alertami. Serwer WWW wskazuje na katalog public i blokuje pliki ukryte.
Czy Nginx obsługuje HTTP/2 i HTTP/3?
Tak — HTTP/2 włącza się jednym parametrem w konfiguracji, HTTP/3 wymaga nowszej wersji Nginx i konfiguracji QUIC. Oba protokoły realnie skracają czas ładowania, zwłaszcza na łączach mobilnych.
👉 Potrzebujesz konfiguracji lub optymalizacji serwera dla Laravel? Sprawdź usługę modernizacji i utrzymania kodu albo Laravel Development — wycena jest bezpłatna.
📖 Zobacz również: Node.js w projektach Laravel, CI/CD i DevOps dla aplikacji Laravel oraz optymalizacja wydajności aplikacji Laravel.