Autor: [Adam Nadolny](/autorzy/adam-nadolny) Ekspert DevOps i infrastruktury · Zweryfikowano Kwiecień 2026

1.  [Strona główna](/) ›
2.  [Baza wiedzy](/baza-wiedzy/) ›
3.  Supervisor — zarządzanie procesami na VPS

# Supervisor na VPS — zarządzanie procesami Python, Node.js i Celery

Opublikowano: 9 kwietnia 2026 · Kategoria: VPS

Uruchamiasz aplikację Python z Gunicornem lub workery Celery i chcesz, żeby automatycznie startowały po restarcie VPS i wznawiały pracę po awarii? Supervisor (supervisord) to sprawdzone narzędzie do zarządzania procesami w tle — prostsze niż systemd dla aplikacji użytkownika i bardziej elastyczne niż screen/tmux.

## Instalacja Supervisora

\# Ubuntu / Debian
sudo apt update && sudo apt install supervisor -y

# CentOS / Rocky Linux
sudo dnf install supervisor -y

# Python pip (najnowsza wersja)
pip install supervisor

# Uruchom i włącz przy starcie
sudo systemctl enable --now supervisor

# Sprawdź status
sudo systemctl status supervisor

## Konfiguracja — Gunicorn + Django/Flask

Utwórz plik konfiguracyjny `/etc/supervisor/conf.d/myapp.conf`:

\[program:myapp\]
; Komenda startowa — ścieżka do venv + Gunicorn
command=/var/www/myapp/venv/bin/gunicorn myapp.wsgi:application
    --workers 3
    --bind 127.0.0.1:8000
    --timeout 120
    --log-level info

; Katalog roboczy aplikacji
directory=/var/www/myapp

; Użytkownik (nie root!)
user=www-data

; Automatyczny start i restart
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true

; Logi
stdout\_logfile=/var/log/supervisor/myapp.log
stderr\_logfile=/var/log/supervisor/myapp.err.log
stdout\_logfile\_maxbytes=10MB
stdout\_logfile\_backups=5

; Zmienne środowiskowe
environment=DJANGO\_SETTINGS\_MODULE="myapp.settings.production",
    DATABASE\_URL="postgresql://user:pass@localhost/myapp"

Po każdej zmianie pliku `.conf`: `sudo supervisorctl reread && sudo supervisorctl update`.

## Konfiguracja — Celery worker

\[program:celery-worker\]
command=/var/www/myapp/venv/bin/celery
    -A myapp
    worker
    --loglevel=info
    --concurrency=4
    -n worker1@%%h

directory=/var/www/myapp
user=www-data
autostart=true
autorestart=true
stopwaitsecs=600
stopasgroup=true
killasgroup=true

stdout\_logfile=/var/log/supervisor/celery-worker.log
stderr\_logfile=/var/log/supervisor/celery-worker.err.log

\[program:celery-beat\]
command=/var/www/myapp/venv/bin/celery
    -A myapp
    beat
    --loglevel=info
    --scheduler django\_celery\_beat.schedulers:DatabaseScheduler

directory=/var/www/myapp
user=www-data
autostart=true
autorestart=true

stdout\_logfile=/var/log/supervisor/celery-beat.log
stderr\_logfile=/var/log/supervisor/celery-beat.err.log

## Konfiguracja — Node.js / Next.js

\[program:nextjs-app\]
command=/usr/bin/node /var/www/nextapp/.next/standalone/server.js

directory=/var/www/nextapp
user=nodeuser
autostart=true
autorestart=true

environment=NODE\_ENV="production",PORT="3000",HOST="127.0.0.1"

stdout\_logfile=/var/log/supervisor/nextjs.log
stderr\_logfile=/var/log/supervisor/nextjs.err.log

Dla Node.js rozważ też PM2 — ma dedykowane funkcje jak cluster mode i reload bez downtime. Supervisor jest lepszy gdy zarządzasz mieszanką technologii (Python + Node).

## supervisorctl — zarządzanie procesami

\# Status wszystkich procesów
sudo supervisorctl status

# Start / stop / restart konkretnego procesu
sudo supervisorctl start myapp
sudo supervisorctl stop myapp
sudo supervisorctl restart myapp

# Przeładuj konfigurację (po dodaniu nowego .conf)
sudo supervisorctl reread
sudo supervisorctl update

# Logi w czasie rzeczywistym
sudo supervisorctl tail -f myapp
sudo supervisorctl tail -f myapp stderr

# Interaktywny shell
sudo supervisorctl

## Porównanie: Supervisor vs systemd vs PM2

Cecha

Supervisor

systemd

PM2

Uprawnienia

Root lub user

Root (systemctl)

User (bez root)

Języki/frameworki

Dowolne

Dowolne (OS-level)

Node.js (głównie)

Cluster mode

Przez grupy

Przez instancje

Wbudowany

Reload bez downtime

Nie wprost

Tak (ExecReload)

Tak (pm2 reload)

Web interface

supervisord web UI

Brak (cockpit extra)

PM2 Plus (płatny)

Najlepszy dla

Python, mieszane stosy

Usługi systemowe

Node.js production

## Grupy procesów

Supervisor pozwala grupować procesy i zarządzać nimi jednym poleceniem:

\[group:myapp-stack\]
programs=myapp,celery-worker,celery-beat

; Zarządzanie całą grupą:
; sudo supervisorctl start myapp-stack:\*
; sudo supervisorctl stop myapp-stack:\*
; sudo supervisorctl restart myapp-stack:\*

## Dobre praktyki

-   **Nigdy nie uruchamiaj jako root** — ustaw `user=www-data` lub dedykowany user aplikacji
-   **Używaj `stopasgroup=true`** dla procesów z subprocess (Gunicorn, Celery) — Supervisor zabije cały drzewo procesów
-   **Rotacja logów** — ustaw `stdout_logfile_maxbytes` i `stdout_logfile_backups` żeby logi nie zapchały dysku
-   **Zmienne środowiskowe przez `environment=`** — nie w `.env` (Supervisor go nie wczytuje automatycznie)
-   **Testuj konfigurację przed dodaniem** — uruchom komendę ręcznie jako docelowy user, żeby upewnić się że działa przed wpisaniem do Supervisora

## Najczęstsze pytania

Co to jest Supervisor i do czego służy? +

Supervisor (supervisord) to system zarządzania procesami dla Linuksa. Uruchamia i monitoruje procesy w tle (Python, Node.js, Celery, Gunicorn), automatycznie restartuje je po awarii i przechowuje logi. Alternatywa dla systemd dla aplikacji użytkownika, szczególnie przydatna gdy nie masz uprawnień roota do tworzenia usług systemd.

Jaka jest różnica między Supervisor a systemd? +

systemd to system init OS (root-only), Supervisor to zarządca procesów użytkownika. systemd jest lepszy dla usług systemowych (nginx, PostgreSQL). Supervisor jest lepszy dla aplikacji Python/Node.js, kolejek (Celery), workerów — szczególnie gdy chcesz zarządzać procesami bez sudo. PM2 to odpowiednik Supervisora specyficznie dla Node.js.

Jak uruchomić aplikację Django/Flask z Gunicornem przez Supervisor? +

Utwórz plik /etc/supervisor/conf.d/myapp.conf z sekcją \[program:myapp\]. Ustaw command=/path/to/venv/bin/gunicorn myapp.wsgi:application --workers 3 --bind 127.0.0.1:8000, directory=/var/www/myapp, user=www-data. Potem: supervisorctl reread && supervisorctl update && supervisorctl start myapp.

Jak sprawdzić logi aplikacji w Supervisor? +

supervisorctl tail -f myapp — podgląd stdout w czasie rzeczywistym. supervisorctl tail -f myapp stderr — logi błędów. Pliki logów: /var/log/supervisor/myapp.log (stdout) i /var/log/supervisor/myapp.err.log (stderr). Status wszystkich procesów: supervisorctl status.

## Sprawdź oferty pasujące do tego scenariusza

Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne.

Contabo

VPS z rootem do instalacji Supervisora i aplikacji Python/Node

VPS root access

[Aktywuj rabat →](/out/contabo)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/contabo)

Mikr.us

Budżetowy VPS pod projekty Python/Node z Supervisorem

Budżetowy VPS

[Aktywuj rabat →](/out/mikrus)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/mikrus)

ProSerwer.pl

Polski VPS z wsparciem technicznym do Python/Node deploymentu

Polski VPS

[Aktywuj rabat →](/out/proserwer-pl)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/proserwer)

## Powiązane strony

-   [Docker na VPS — instalacja i konfiguracja](/baza-wiedzy/docker-na-vps)
-   [Node.js na hostingu współdzielonym](/baza-wiedzy/nodejs-na-hostingu-wspoldzielonym)
-   [Python/Django na hostingu — poradnik](/baza-wiedzy/python-django-na-hostingu)
-   [UFW — firewall na VPS krok po kroku](/baza-wiedzy/ufw-firewall-konfiguracja-vps)
-   [Wszystkie artykuły](/baza-wiedzy/)