Dealownia
Menu
sprawdzono – jak sprawdzamy oferty

Self-hosted zamiast abonamentu: 9 narzędzi na własny VPS

Umami, Plausible CE, Kuma, GlitchTip, Formbricks, LimeSurvey, listmonk, n8n i Vaultwarden na VPS: do czego służą, ile pamięci biorą i kiedy nie warto.

Aplikacje na własnym serwerzezaktualizowano 7 min czytania

Redakcja serwisu Dealownia · ceny i fakty ze stron dostawców, jak sprawdzamy

Które płatne usługi da się zastąpić darmowym oprogramowaniem na własnym VPS, ile każde z nich potrzebuje według swojej dokumentacji, na jakiej licencji działa i kiedy lepiej zostać przy usłudze w chmurze. Do tego jeden wzorzec instalacji, który pasuje do wszystkich narzędzi z listy. Dla trzech lekkich narzędzi (Umami, Uptime Kuma, GlitchTip) podajemy też orientacyjne zużycie pamięci po starcie.

Czego potrzebujesz

  • VPS z Ubuntu 24.04 LTS albo Debianem 12 lub 13, z nginx, certbotem i Dockerem z wtyczką Compose – jak w poradniku od zera.
  • Pamięć zależną od zestawu: dla dwóch–trzech lekkich narzędzi 2 GB RAM, z Plausible CE albo kilkoma bazami – 4 GB. Szczegóły przy każdym narzędziu.
  • Subdomenę dla każdego narzędzia (stats.example.pl, status.example.pl itd.).
  • Kopie zapasowe. Narzędzie u siebie to także Twoje dane u siebie – bez kopii awaria dysku kasuje historię analityki czy sejf z hasłami.

Jeden wzorzec dla wszystkich narzędzi

Każde narzędzie stawiasz tak samo: osobny katalog, plik compose.yaml z dokumentacji projektu, port opublikowany tylko na 127.0.0.1, nginx jako jedyne wejście z zewnątrz i certyfikat Let’s Encrypt.

bash
sudo mkdir -p /opt/apps/NARZEDZIE && sudo chown deploy:deploy /opt/apps/NARZEDZIE
cd /opt/apps/NARZEDZIE
# compose.yaml z dokumentacji projektu, porty zmienione na 127.0.0.1:PORT:PORT
docker compose up -d
docker stats --no-stream

docker stats pokaże, ile pamięci zajmuje kontener – sprawdzaj to po każdym nowym narzędziu. Port bez 127.0.0.1: jest dostępny z internetu mimo ufw, bo Docker dopisuje własne reguły zapory. W nginx dla każdego narzędzia wystarczy blok z proxy_pass http://127.0.0.1:PORT; – pełny przykład z nagłówkami WebSocket jest w poradniku o Uptime Kuma. Gotowy plik z kilkoma narzędziami naraz znajdziesz w poradniku o stacku Docker Compose.

Analityka: Umami albo Plausible CE

Umami zastępuje Google Analytics na stronach, którym wystarczą odsłony, źródła ruchu, strony wejścia i zdarzenia. Obraz: ghcr.io/umami-software/umami:latest, tak jak w poradniku o Umami (dokumentacja instalacji podaje też adres docker.umami.is/umami-software/umami:latest). Wymaga PostgreSQL (dokumentacja podaje minimum 12.14); MySQL nie jest już wymieniony. Dokumentacja nie podaje wymagań pamięci – orientacyjnie kontener Umami zajmuje ok. 180 MiB po starcie, a Postgres ok. 65 MiB (sprawdź u siebie docker stats). Instrukcja: Umami zamiast Google Analytics.

Plausible Community Edition daje podobny zakres z bazą ClickHouse. Według repozytorium CE zalecane jest co najmniej 2 GB RAM, a procesor musi obsługiwać SSE 4.2 albo NEON. Licencja AGPLv3. Wersja CE wychodzi dwa razy w roku i nie ma funkcji płatnych (lejki, przychody w e-commerce, SSO, API zarządzania stronami).

Kiedy nie warto: gdy masz VPS z 1 GB RAM i chcesz Plausible – ClickHouse tyle nie zmieści. Gdy potrzebujesz integracji z Google Ads albo raportów dla klienta w konkretnym formacie.

Monitoring: Uptime Kuma

Uptime Kuma sprawdza strony, certyfikaty, porty i odbiera sygnały od zadań cron, a powiadomienia wysyła m.in. na Discord, Telegram i e-mail. Obraz louislam/uptime-kuma:2, port 3001. Dokumentacja nie podaje wymagań sprzętowych, ostrzega za to, że baza SQLite na NFS może się uszkodzić. Orientacyjnie kontener zajmuje ok. 120 MiB po starcie. Instrukcja: Uptime Kuma na VPS.

Kiedy nie warto: jako jedyny monitoring. Kuma na tym samym serwerze nie powiadomi Cię, że serwer leży. Przy jednej–dwóch stronach zewnętrzny darmowy plan (UptimeRobot daje 50 monitorów co 5 minut) wystarczy bez Kumy.

Błędy aplikacji: GlitchTip

GlitchTip przyjmuje zdarzenia z SDK Sentry, więc w kodzie zmieniasz tylko adres DSN. Dokumentacja zaleca 512 MB RAM, a minimum to 256 MB w trybie all-in-one. Wymaga PostgreSQL 14+, Valkey/Redis 7+ jest opcjonalny. Orientacyjnie kontener zajmuje ok. 170 MiB po starcie. Instrukcja: GlitchTip zamiast Sentry.

Kiedy nie warto: gdy błędów jest kilka miesięcznie, a projekt jest jeden – wtedy darmowy plan usługi w chmurze zwykle wystarczy i nie trzeba pilnować kolejnej bazy.

Formularze i ankiety: Formbricks albo LimeSurvey

Formbricks to ankiety i formularze, także osadzane na stronie. Rdzeń jest na licencji AGPLv3, a funkcje z katalogu ee wymagają klucza licencji Enterprise (są w obrazie, ale zablokowane). Dokumentacja instalacji nie podaje wymagań pamięci; wymaga serwera z Ubuntu, domeny i otwartych portów 80 i 443, a do przechowywania plików zaleca lokalny dysk SSD/NVMe.

LimeSurvey to klasyczne narzędzie do ankiet w PHP, na licencji GPL v2 lub nowszej. Według instrukcji instalacji wersja 7 wymaga PHP od 8.1.29, MariaDB od 10.3.38 albo PostgreSQL od 14 i co najmniej 500 MB miejsca na dysku; limit pamięci PHP – minimum 128 MB.

Kiedy nie warto: dla jednego formularza kontaktowego na stronie statycznej. Stawianie platformy ankietowej, żeby dostać mail z formularza, to więcej pracy z aktualizacjami niż pożytku.

Newsletter: listmonk

listmonk zarządza listami, szablonami i kampaniami. Jeden plik binarny albo obraz listmonk/listmonk:latest, baza PostgreSQL od wersji 12, licencja AGPLv3. Dokumentacja nie podaje wymagań pamięci. Panel po instalacji: port 9000, przy pierwszym wejściu zakładasz konto administratora.

listmonk sam nie dostarcza poczty – wysyła przez skonfigurowane serwery SMTP. Potrzebujesz więc usługi wysyłkowej, a dokumentacja ostrzega, że część dostawców serwerów blokuje wychodzące porty 25 i 465.

Kiedy nie warto: przy małej liście, gdy nie masz czasu pilnować dostarczalności (SPF, DKIM, DMARC, obsługa odbić). Płatna usługa wysyłkowa i tak zostaje, więc oszczędzasz na panelu, nie na wysyłce.

Automatyzacje: n8n – sprawdź licencję

n8n łączy usługi w przepływy (formularz → arkusz → powiadomienie). Obraz n8nio/n8n, port 5678, dane w /home/node/.n8n; domyślna baza to SQLite, można przełączyć na PostgreSQL. Dokumentacja Dockera nie podaje wymagań sprzętowych.

n8n nie jest na licencji open source w rozumieniu OSI. Działa na Sustainable Use License: wolno go używać i modyfikować na własne wewnętrzne potrzeby firmy albo niekomercyjnie i prywatnie. Wolno automatyzować własną firmę i budować płatne automatyzacje dla klientów na swojej instancji, o ile klienci nie dostają edytora ani konfiguracji workflowów. Nie wolno sprzedawać n8n jako usługi, w której klienci sami budują przepływy. Szczegóły: poradnik o n8n. Pliki z .ee w nazwie podlegają osobnej licencji Enterprise.

Kiedy nie warto: gdy chcesz oferować klientom n8n jako usługę, w której sami budują przepływy – licencja tego zakazuje. Przypadki graniczne rozstrzyga licencja i FAQ n8n.

Hasła: Vaultwarden

Vaultwarden to niezależna implementacja serwera zgodnego z klientami Bitwarden (aplikacje, rozszerzenia przeglądarek). Projekt zaznacza, że nie jest powiązany z firmą Bitwarden. Licencja AGPL-3.0. Wymaga HTTPS – sejf w przeglądarce działa tylko w bezpiecznym kontekście.

yaml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    environment:
      DOMAIN: "https://hasla.example.pl"
      SIGNUPS_ALLOWED: "true"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8001:80

SIGNUPS_ALLOWED: "true" jest tu tylko na czas zakładania własnego konta. Zaraz potem zmień wartość na "false" i wykonaj docker compose up -d – inaczej każdy, kto trafi na adres, założy sobie konto na Twoim serwerze. Wymagań pamięci repozytorium nie podaje.

Kiedy nie warto: gdy nie masz sprawdzonej kopii zapasowej katalogu vw-data poza serwerem. Awaria bez kopii oznacza utratę wszystkich haseł. Dla rodziny albo małego zespołu bez osoby od serwera płatny menedżer haseł to mniejsze ryzyko.

Najczęstsze problemy

  • Serwer zwalnia, a w dmesg jest „Out of memory”. Za dużo narzędzi na za małym VPS-ie. Sprawdź docker stats, ustaw limity mem_limit w compose i dodaj plik swap. Dobrą praktyką jest, by każdy kontener narzędzia miał limit pamięci i procesora, żeby nie zagłodził nginx ze stronami.
  • Panel narzędzia widoczny z internetu na porcie, mimo ufw. Port w compose bez 127.0.0.1:. Popraw i docker compose up -d.
  • Po aktualizacji obrazu latest narzędzie nie wstaje. Nowa wersja główna zmieniła bazę albo konfigurację. Przypinaj wersje główne (np. :2), czytaj notatki do wydania i rób kopię przed docker compose pull.
  • Dwie bazy Postgres zjadają pamięć. Umami, GlitchTip i listmonk mogą korzystać z jednego serwera Postgres z osobnymi bazami i użytkownikami. W poradnikach serwisu każde narzędzie ma dla prostoty własny kontener bazy; wspólny Postgres dla Umami i GlitchTip opisujemy w poradniku o GlitchTip (GlitchTip potrzebuje w nim max_locks_per_transaction=512).

Co dalej

Zacznij od jednego narzędzia, które realnie zastąpi płatną usługę, i dopiero po tygodniu dołóż kolejne. Dla każdego ustaw kopie zapasowe i monitoring. Darmowe plany usług w chmurze, które czasem wystarczą zamiast własnego serwera, są na stronie darmowe. Czy zestaw narzędzi na własnym VPS wyjdzie taniej niż abonamenty, policzysz w kalkulatorze self-hosting czy abonament – z RAM z dokumentacji i serwerem z rankingu.

Powiązane poradniki