WordPress na Coolify: Kompletny przewodnik po konfiguracji z SSH, SFTP, WP-CLI i zarządzaniem zasobami [2026]

Coolify to open-source’owa platforma do self-hostingu aplikacji — alternatywa dla Vercel, Heroku czy tradycyjnych paneli typu cPanel i DirectAdmin. W tym przewodniku pokazuję krok po kroku, jak skonfigurować profesjonalne środowisko WordPress na Coolify z pełnym dostępem developerskim.

Artykuł powstał na podstawie rzeczywistego wdrożenia produkcyjnego na serwerze Hetzner — opisuję każdy problem, który napotkałem, i jak go rozwiązałem.

Czego dowiesz się z tego artykułu?

• Jak wygląda architektura WordPress na Coolify vs tradycyjny hosting
• Jak zarządzać zasobami (RAM, CPU) w kontenerach Docker
• Jak skonfigurować SSH/SFTP z izolowanym dostępem per developer
• Jak dodać WP-CLI dostępny przez SSH
• Jak ustawić wyższe limity PHP (upload, pamięć, czas wykonania)
• Jakie problemy napotkałem i jak je rozwiązałem
• Plusy i minusy WordPress na Coolify vs klasyczny hosting

Coolify vs tradycyjny hosting WordPress — kluczowe różnice

Na tradycyjnym hostingu (cPanel, DirectAdmin, shared hosting) WordPress działa na współdzielonym serwerze z dziesiątkami lub setkami innych stron. Na Coolify każda aplikacja działa w izolowanym kontenerze Docker z własnymi zasobami.

Aspekt	Coolify (Docker)	Shared hosting (cPanel/DirectAdmin)
Izolacja	Pełna — osobny kontener	Ograniczona — współdzielone zasoby
Zasoby (RAM/CPU)	Konfigurowalne limity per kontener	Współdzielona pula, „noisy neighbor”
Wydajność	~320ms ładowanie strony	~650ms ładowanie strony
SSH/SFTP	Wymaga konfiguracji (ten przewodnik)	Wbudowane
WP-CLI	Przez kontener helper	Wbudowane
PHP limity	Pełna kontrola	Ograniczone przez panel
Deployment	Git push → auto deploy	FTP / panel
SSL	Automatyczny (Let’s Encrypt)	Automatyczny lub ręczny
Koszt	~5-15€/mies (VPS) + Twój czas	~3-10€/mies, zero zarządzania
Skalowalność	Łatwe skalowanie horyzontalne	Ograniczone planem

Zarządzanie zasobami: RAM, CPU i dysk

To jedna z największych zalet Coolify nad tradycyjnym hostingiem — masz pełną kontrolę nad zasobami każdego kontenera.

Limity zasobów w Docker Compose

W klasycznym Coolify WordPress nie ma wbudowanego UI do ustawiania limitów RAM/CPU per kontener. Musisz to zrobić ręcznie w docker-compose.yml:

services:
  wordpress:
    image: wordpress:latest
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 2048M
        reservations:
          cpus: '1.0'
          memory: 1024M

Co oznaczają te ustawienia:

• limits.memory: 2048M — maksymalna ilość RAM. Przekroczenie = Docker zabija kontener
• reservations.memory: 1024M — gwarantowane minimum RAM
• limits.cpus: '2.0' — maksymalnie 2 rdzenie CPU
• reservations.cpus: '1.0' — gwarantowany 1 rdzeń

Uwaga: Bez ustawionych limitów kontenery mają nieograniczony dostęp do zasobów hosta — jeden kontener może „zjeść” całą pamięć serwera.

Monitoring zasobów

Coolify ma wbudowany Sentinel — lekki kontener monitorujący, który zbiera metryki CPU, RAM i dysku dla każdego kontenera. Możesz śledzić zużycie zasobów bezpośrednio w dashboardzie Coolify.

Minimalne wymagania serwera

Zastosowanie	CPU	RAM	Dysk
Coolify + 1 WordPress	2 rdzenie	2 GB	30 GB
Coolify + 3-5 WordPress	4 rdzenie	8 GB	60 GB
Coolify + 10+ aplikacji	8 rdzeni	16 GB	120 GB

Docker Compose — kompletna konfiguracja

Poniżej pełny, przetestowany docker-compose.yml do wdrożenia w Coolify:

services:
  wordpress:
    image: wordpress:latest
    volumes:
      - wordpress-files:/var/www/html
      - type: bind
        source: ./uploads.ini
        target: /usr/local/etc/php/conf.d/uploads.ini
        content: |
          file_uploads = On
          upload_max_filesize = 512M
          post_max_size = 512M
          memory_limit = 512M
          max_execution_time = 600
          max_input_time = 600
          max_input_vars = 10000
    environment:
      - WORDPRESS_DB_HOST=mariadb
      - WORDPRESS_DB_USER=$SERVICE_USER_WORDPRESS
      - WORDPRESS_DB_PASSWORD=$SERVICE_PASSWORD_WORDPRESS
      - WORDPRESS_DB_NAME=wordpress
    depends_on:
      mariadb:
        condition: service_healthy
    healthcheck:
      test: ["CMD-SHELL", "curl -sL http://localhost:80/ -o /dev/null -w '%{http_code}' | grep -qE '^[23]'"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 60s

  mariadb:
    image: mariadb:11
    volumes:
      - mariadb-data:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=$SERVICE_PASSWORD_ROOT
      - MYSQL_DATABASE=wordpress
      - MYSQL_USER=$SERVICE_USER_WORDPRESS
      - MYSQL_PASSWORD=$SERVICE_PASSWORD_WORDPRESS
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 5s
      timeout: 20s
      retries: 10

  wpcli:
    image: wordpress:cli
    init: true
    volumes:
      - wordpress-files:/var/www/html
    environment:
      - WORDPRESS_DB_HOST=mariadb
      - WORDPRESS_DB_USER=$SERVICE_USER_WORDPRESS
      - WORDPRESS_DB_PASSWORD=$SERVICE_PASSWORD_WORDPRESS
      - WORDPRESS_DB_NAME=wordpress
    depends_on:
      - wordpress
      - mariadb
    entrypoint: ["tail", "-f", "/dev/null"]
    user: "0:0"

volumes:
  wordpress-files:
  mariadb-data:

Na co zwrócić uwagę w konfiguracji

1. Składnia content: — tworzenie plików w locie

Coolify ma specjalną składnię content:, która tworzy pliki automatycznie bez commitowania ich do repozytorium. Dzięki temu uploads.ini z limitami PHP jest generowany przy każdym deploy’u.

2. Zmienne środowiskowe Coolify

$SERVICE_USER_WORDPRESS i $SERVICE_PASSWORD_WORDPRESS — Coolify automatycznie generuje bezpieczne hasła do bazy danych. Nie musisz ich tworzyć ręcznie.

3. Healthcheck z obsługą redirectów

Standardowy healthcheck nie działa z WordPress, bo zwraca redirect 302 (np. na stronę instalacji). Flaga -L w curl podąża za redirectami, a regex '^[23]' akceptuje kody 2xx i 3xx.

4. init: true — zapobieganie zombie processes

Kontener wpcli z tail -f /dev/null jako entrypoint nie „sprząta” procesów potomnych. Bez init: true po kilku dniach miałem 2869 procesów zombie na serwerze. Dodanie init: true rozwiązuje problem całkowicie.

5. Plik docker-compose musi mieć rozszerzenie .yml

Coolify nie rozpoznaje plików .yaml — tylko .yml. To drobna rzecz, ale może kosztować sporo debugowania.

6. Branch musi być main

Jeśli repozytorium ma branch master, Coolify nie znajdzie pliku. Zmień domyślny branch na main.

Konfiguracja PHP — trzy metody

Metoda 1: Przez docker-compose (trwała, rekomendowana)

Użyj składni content: jak w konfiguracji powyżej. Ustawienia przetrwają każdy redeploy.

Metoda 2: Przez .htaccess (szybka, bez redeployu)

php_value upload_max_filesize 512M
php_value post_max_size 512M
php_value memory_limit 512M
php_value max_execution_time 600
php_value max_input_time 600
php_value max_input_vars 10000

Metoda 3: Przez php.ini w kontenerze (tymczasowa)

docker exec wordpress-CONTAINER sh -c "cat > /usr/local/etc/php/conf.d/uploads.ini << 'EOF'
upload_max_filesize = 512M
post_max_size = 512M
memory_limit = 512M
max_execution_time = 600
EOF"

Uwaga: Metoda 3 nie przetrwa restartu kontenera. Metoda 2 przetrwa restart, ale nie redeploy z nowym wolumenem.

SSH i SFTP — izolowany dostęp dla developerów

To był najtrudniejszy problem do rozwiązania. Na tradycyjnym hostingu SSH/SFTP jest wbudowane. Na Coolify z Docker? Nie ma gotowego rozwiązania.

Podejścia, które NIE zadziałały

1. Kontener SSH (linuxserver/openssh-server) — komplikuje konfigurację sieci, wymaga osobnych portów per instalacja, nie skaluje się
2. SSH przez domenę — SSH nie routuje się przez HTTP reverse proxy jak Traefik. Potrzebujesz unikatowych portów lub Cloudflare Tunnel
3. FileBrowser (web-based) — nie zastępuje prawdziwego SSH/SFTP. Developerzy potrzebują FileZilla, WinSCP, VS Code Remote

Rozwiązanie: użytkownicy systemowi na hoście

Kluczowa innowacja: tworzymy użytkowników systemowych na serwerze hosta, których katalog domowy wskazuje na Docker Volume z plikami WordPress. Działa to identycznie jak DirectAdmin:

• SSH/SFTP przez standardowy port 22
• Każdy developer widzi tylko swój WordPress
• Nie potrzeba osobnych kontenerów ani portów

Skrypt automatyzacji

# Po deploymencie WordPress w Coolify:

# 1. Znajdź prefix wolumenu
docker volume ls | grep wordpress-files

# 2. Utwórz użytkownika
./setup-wordpress-user.sh klient PREFIX

# Skrypt automatycznie:
# - Tworzy użytkownika z grupą www-data (GID 33)
# - Dodaje go do grupy docker (dla WP-CLI)
# - Ustawia home directory na Docker Volume
# - Tworzy wrapper WP-CLI
# - Generuje hasło
# - Naprawia uprawnienia

Kluczowe szczegóły techniczne

• GID 33 (www-data) — użytkownik musi być w grupie www-data, żeby mógł edytować pliki WordPress. Nie używaj UID 33 (to alias istniejącego www-data), tylko normalny UID z grupą 33
• Grupa docker — potrzebna do uruchamiania WP-CLI (który wykonuje docker exec wewnątrz kontenera)
• chmod o+x — cała ścieżka /var/lib/docker/volumes/PREFIX/ musi mieć execute permission dla „others”
• Pliki .bashrc i .bash_history — muszą być własnością użytkownika, nie www-data, bo inaczej SSH zgłasza „Permission denied”

WP-CLI przez SSH

Po skonfigurowaniu użytkownika, WP-CLI działa bezpośrednio po SSH:

ssh klient@serwer-ip

wp plugin list
wp theme list
wp core version
wp user list
wp db export backup.sql
wp search-replace 'stara-domena.pl' 'nowa-domena.pl'

Jak to działa pod spodem: Wrapper script /usr/local/bin/wp-klient wykonuje docker exec wewnątrz kontenera wordpress:cli. Ważne: musi celować w kontener z obrazem wordpress:cli, nie wordpress:latest (który nie zawiera WP-CLI).

Problemy, które napotkałem — i jak je rozwiązałem

Problem 1: 2869 zombie processes

Objaw: Po kilku dniach serwer zgłaszał tysiące procesów zombie.

Przyczyna: Kontener wpcli z tail -f /dev/null nie zbierał procesów potomnych z docker exec.

Rozwiązanie: Dodanie init: true do kontenera wpcli w docker-compose.yml.

Problem 2: DNS nie działa w kontenerach Docker (Hetzner)

Objaw: Deployment fails z błędem „Could not resolve host: github.com”.

Przyczyna: Docker był skonfigurowany z publicznymi DNS (1.1.1.1, 8.8.8.8), ale Hetzner blokuje zewnętrzne serwery DNS i wymaga własnych.

Rozwiązanie: Zmiana /etc/docker/daemon.json:

{
  "dns": ["185.12.64.2", "185.12.64.1"]
}

Po zmianie: systemctl restart docker

Problem 3: „No available server” w Coolify

Objaw: Po deploymencie Coolify pokazuje błąd healthcheck.

Przyczyna: WordPress zwraca redirect 302, a domyślny curl tego nie obsługuje.

Rozwiązanie: Healthcheck z flagą -L (follow redirects) i regex akceptującym kody 2xx/3xx.

Problem 4: SSH Permission Denied na katalog domowy

Objaw: SSH loguje, ale nie może wejść do katalogu domowego.

Przyczyna: Ścieżka /var/lib/docker nie ma execute permission dla non-root.

Rozwiązanie:

chmod o+x /var/lib/docker
chmod o+x /var/lib/docker/volumes
chmod o+x /var/lib/docker/volumes/PREFIX_wordpress-files
chmod o+x /var/lib/docker/volumes/PREFIX_wordpress-files/_data

Problem 5: WP-CLI „executable not found”

Objaw: wp komenda zgłasza, że nie może znaleźć pliku wykonywalnego.

Przyczyna: Wrapper WP-CLI celował w kontener wordpress:latest (Debian, UID 33), a nie wordpress:cli (Alpine).

Rozwiązanie: Zmiana filtra w wrapperze na --filter "ancestor=wordpress:cli".

Problem 6: PasswordAuthentication wyłączone

Objaw: SSH odmawia połączenia hasłem.

Przyczyna: Ubuntu domyślnie wyłącza PasswordAuthentication w sshd_config.

Rozwiązanie: Ustawienie PasswordAuthentication yes w /etc/ssh/sshd_config i systemctl restart ssh.

Plusy i minusy WordPress na Coolify

Plusy

• Pełna kontrola nad zasobami — ustawiasz dokładne limity RAM i CPU per kontener
• Izolacja — problem z jedną stroną nie wpływa na inne (brak „noisy neighbor”)
• Wydajność — ~51% szybsze ładowanie stron vs shared hosting
• Deployment z Git — push do repozytorium automatycznie deployuje zmiany
• Darmowe SSL — automatyczny Let’s Encrypt bez konfiguracji
• Skalowalność — łatwe dodawanie nowych instancji WordPress
• Pełna kontrola PHP — żadnych ograniczeń panelu hostingowego
• Nowoczesna architektura — Docker, CI/CD, Infrastructure as Code

Minusy

• Brak wbudowanego SSH/SFTP — wymaga ręcznej konfiguracji (ten przewodnik)
• Brak UI do zarządzania zasobami — limity RAM/CPU ustawia się ręcznie w docker-compose
• Krzywa uczenia — wymaga znajomości Docker, Linux, sieci
• Zarządzanie serwerem — aktualizacje, backup, security to Twoja odpowiedzialność
• Brak panelu email — potrzebujesz osobnego rozwiązania (Mailcow, zewnętrzny provider)
• Specyficzne problemy DNS — np. Hetzner blokuje publiczne DNS (1.1.1.1, 8.8.8.8)
• Uprawnienia po redeployu — chmod na Docker volumes trzeba ponawiać po niektórych operacjach

Kiedy wybrać Coolify?

• Jesteś developerem lub agencją z wieloma WordPress
• Potrzebujesz pełnej kontroli nad serwerem
• Chcesz lepszej wydajności niż shared hosting
• Planujesz skalowanie

Kiedy zostać przy tradycyjnym hostingu?

• Masz jedną stronę i nie chcesz zarządzać serwerem
• Potrzebujesz wbudowanego email, FTP, phpMyAdmin
• Nie znasz Docker’a i nie chcesz się uczyć
• Budżet jest priorytetem, nie wydajność

Automatyzacja nowych klientów

Cały proces dodawania nowego klienta WordPress:

1. W Coolify: Utwórz nowy projekt z docker-compose (z tego repo GitHub)
2. Ustaw domenę: np. klient.twojadomena.pl
3. Deploy
4. Na serwerze:

# Znajdź prefix wolumenu
docker volume ls | grep wordpress-files

# Utwórz użytkownika
./setup-wordpress-user.sh nazwa-klienta PREFIX

Skrypt wyświetli dane do przekazania klientowi: login SSH, hasło, adres serwera.

Repozytorium z kodem

Cały kod, skrypty i konfiguracja dostępne na GitHub:

github.com/lukelocksmith/wordpress-ssh-coolify

Zawiera:

• docker-compose.yml — kompletna konfiguracja dla Coolify
• scripts/setup-wordpress-user.sh — automatyzacja tworzenia użytkownika SSH
• scripts/new-wordpress.sh — pełna automatyzacja z Coolify API

Najczęściej zadawane pytania

Czy redeploy nadpisze moje pliki WordPress?

Nie. Docker Volumes (wordpress-files, mariadb-data) przetrwają redeploy. Twoje treści, wtyczki i konfiguracja pozostaną nienaruszone.

Czy mogę dać dostęp SSH tylko do jednego WordPress?

Tak. Każdy użytkownik systemowy ma katalog domowy wskazujący na konkretny Docker Volume — widzi tylko swoje pliki.

Ile WordPress mogę uruchomić na jednym serwerze?

Zależy od zasobów. Na serwerze z 8 GB RAM i 4 rdzeniami CPU możesz spokojnie hostować 3-5 instancji WordPress + Coolify + inne aplikacje. Z limitami zasobów per kontener masz pełną kontrolę.

Czy muszę robić backup ręcznie?

Coolify ma wbudowany system backupów. Możesz też użyć WP-CLI: wp db export i rsync do archiwizacji plików.

Co się stanie jak serwer się zrestartuje?

Docker automatycznie uruchomi wszystkie kontenery. Jedyny problem: uprawnienia chmod o+x na ścieżkach Docker volumes mogą się zresetować po aktualizacji Docker — trzeba je ponowić.

Artykuł oparty na rzeczywistym wdrożeniu produkcyjnym. Ostatnia aktualizacja: luty 2026.

]]>

Czytaj również

Wordpress

WordPress vs Webflow vs Wix — co wybrać dla firmy w Polsce w 2026?

02.04.2026

Wordpress

Framer vs Webflow — co wybrać w 2026? Porównanie dla polskich firm

01.04.2026