Uptime Kuma 2.x — co nowego? Przegląd wszystkich zmian w wersji 2

Dlaczego wersja 2 to kamień milowy w historii Uptime Kuma

20 października 2025 roku Louis Lam — twórca i główny maintainer Uptime Kuma — opublikował na GitHubie wersję 2.0.0. To nie była zwykła aktualizacja z paroma poprawkami. To było fundamentalne przebudowanie jednego z najpopularniejszych narzędzi self-hosted w historii — projektu, który w marcu 2026 roku zgromadził już ponad 84 000 gwiazdek na GitHubie i przekroczył 100 milionów pobrań z Docker Hub.

Wersja 2.x przyniosła zmiany, na które społeczność czekała latami: obsługę MariaDB/MySQL jako alternatywy dla SQLite, całkowicie przepisany interfejs na Vue 3 z Vite, rootless Docker image dla zwiększonego bezpieczeństwa, nowy system szablonów powiadomień oparty na LiquidJS, a w kolejnych wydaniach — Globalping (rozproszone sondowanie z całego świata) i monitoring wygasania domen przez RDAP.

W tym artykule szczegółowo omawiamy wszystkie zmiany w gałęzi 2.x — od wersji 2.0.0 przez 2.1.0 po najnowszą 2.2.1. Dowiesz się, co dokładnie się zmieniło, jak bezpiecznie przeprowadzić migrację z v1 i dlaczego hosting zarządzany to najłatwiejszy sposób, by korzystać z najnowszych funkcji bez ryzyka.

Oś czasu — od pierwszych zapowiedzi do stabilnego wydania

Prace nad wersją 2.0 trwały ponad dwa lata. Louis Lam rozpoczął je jeszcze w 2023 roku, a jednym z jego celów była nauka Vue 3 i Vite — frameworków, które miały zastąpić starzejący się stos Vue 2. Rozwój v2 przebiegał równolegle z utrzymaniem gałęzi 1.x, co znacząco wydłużyło proces.

Oto kluczowe daty w historii Uptime Kuma 2.x:

Warto zauważyć, że od momentu wydania stabilnej wersji 2.0.0 tempo rozwoju znacząco przyspieszyło. Wersja 2.1.0 zawierała łącznie 250 scalonych pull requestów — co pokazuje zaangażowanie zarówno Louisa Lama, jak i społeczności kontrybutorów. Nowe wydania ukazują się mniej więcej co miesiąc, przynosząc nowe funkcje, integracje i poprawki.

Uptime Kuma 2.0 — przełomowe zmiany

Wersja 2.0.0 to największa pojedyncza aktualizacja w historii projektu. Obejmuje zmiany na każdym poziomie — od bazy danych, przez backend, po interfejs użytkownika. Poniżej omawiamy każdą z kluczowych zmian szczegółowo.

MariaDB/MySQL — koniec ery wyłącznie SQLite

Przez cztery lata istnienia Uptime Kuma korzystała wyłącznie z SQLite jako bazy danych. To było jedną z jej największych zalet — zero konfiguracji, zero zewnętrznych zależności, plik bazy bezpośrednio w katalogu danych. Ale stało się też jedną z największych limitacji: SQLite nie radzi sobie najlepiej z dużą liczbą współbieżnych zapisów, a instalacje z setkami monitorów i krótkim interwałem sprawdzania (20–60 sekund) potrafiły generować problemy z wydajnością i blokowaniem bazy.

Wersja 2.0 rozwiązuje ten problem, wprowadzając pełną obsługę MariaDB i MySQL jako alternatywnej bazy danych. Oto, co to oznacza w praktyce:

Dwie ścieżki wdrożenia bazy danych

• SQLite (domyślnie) — nadal dostępna i zalecana dla mniejszych wdrożeń (do ~500 monitorów). Zero konfiguracji, zero dodatkowych usług. Idealny wybór dla homelabów, małych firm i instalacji testowych.
• MariaDB/MySQL (opcjonalnie) — zalecana dla większych instalacji z setkami lub tysiącami monitorów, gdzie kluczowa jest skalowalność, obsługa współbieżnych zapisów i możliwość replikacji bazy. Wymaga osobnego serwera bazy danych (lub kontenera Docker).

Konfiguracja MariaDB w Docker

Konfiguracja odbywa się przez zmienne środowiskowe. Oto wymagane parametry:

UPTIME_KUMA_DB_TYPE=mariadb
UPTIME_KUMA_DB_HOSTNAME=db-host
UPTIME_KUMA_DB_PORT=3306
UPTIME_KUMA_DB_NAME=uptime_kuma
UPTIME_KUMA_DB_USERNAME=kuma_user
UPTIME_KUMA_DB_PASSWORD=twoje_haslo

Alternatywnie, przy nowej instalacji Docker możesz wybrać opcję embedded MariaDB — wbudowany serwer MariaDB uruchamiany wewnątrz kontenera Uptime Kuma. To kompromis między prostotą SQLite a mocą MariaDB — nie wymaga osobnego kontenera bazy danych, a jednocześnie oferuje znacznie lepszą wydajność niż SQLite przy dużej liczbie monitorów.

Kiedy wybrać MariaDB zamiast SQLite?

Nowy interfejs — Vue 3 + Vite

Wersja 2.0 przyniosła całkowitą przebudowę frontendu z Vue 2 na Vue 3 z bundlerem Vite. Choć wizualnie interfejs zachowuje rozpoznawalny styl Uptime Kuma — ciemny motyw, lista monitorów po lewej, szczegóły po prawej — pod spodem wszystko zostało przepisane od podstaw.

Co się zmieniło w praktyce?

• Szybsze ładowanie — Vite generuje znacznie mniejsze i lepiej zoptymalizowane bundleki JavaScript niż poprzedni Webpack. Czas pierwszego ładowania panelu jest odczuwalnie krótszy, szczególnie przy dużej liczbie monitorów.
• Płynniejsza praca z listą monitorów — renderowanie setek monitorów w Vue 3 z Composition API jest wydajniejsze. Przewijanie, filtrowanie i grupowanie monitorów działa zauważalnie szybciej.
• Lepszy hot-reload dla deweloperów — kontrybutorzy pracujący nad kodem Uptime Kuma korzystają z błyskawicznego HMR (Hot Module Replacement) Vite, co przyspiesza rozwój nowych funkcji.
• Lepsza responsywność mobilna — poprawiono wyświetlanie przycisków i elementów na ekranach poniżej 450px. PWA działa płynniej na urządzeniach mobilnych.
• Usuniecie wsparcia dla starszych przeglądarek — w zamian za wyższy standard kodu Vue 3 usunięto kompatybilność z przestarzałymi przeglądarkami. Wymagana jest nowoczesna przeglądarka (Chrome 80+, Firefox 80+, Safari 14+, Edge 80+).

Dla przeciętnego użytkownika zmiana jest subtelna — interfejs wygląda znajomo, ale działa szybciej i płynniej. Dla deweloperów i kontrybutorów to fundamentalna zmiana, która otwiera drogę do implementacji nowych funkcji na nowoczesnym stosie technologicznym.

Rootless Docker — bezpieczeństwo na pierwszym miejscu

Jedną z najważniejszych zmian bezpieczeństwa w wersji 2.0 jest wprowadzenie rootless Docker image. Przez lata domyślny obraz Uptime Kuma uruchamiał procesy wewnątrz kontenera jako root — co jest standardem w wielu projektach open-source, ale stanowi ryzyko bezpieczeństwa: jeśli atakujący przełamie izolację kontenera, uzyskuje uprawnienia root na hoście.

Dwa warianty obrazu Docker

Obraz rootless uruchamia procesy Node.js jako użytkownik node zamiast root. To istotne w kontekście:

• Bezpieczeństwa — ogranicza potencjalne skutki exploitów (container escape)
• Zgodności z politykami Kubernetes — wiele klastrów K8s wymaga Pod Security Standards, które zabraniają kontenerów uruchamianych jako root
• Best practices DevSecOps — zasada najmniejszych uprawnień (principle of least privilege)

Pozostałe zmiany w wersji 2.0

Oprócz trzech głównych zmian, wersja 2.0.0 przyniosła szereg mniejszych, ale istotnych usprawnień:

• Nowe notification providers — Nextcloud Talk, Brevo (dawniej Sendinblue), Evolution API
• Autofokus 2FA — pole kodu 2FA jest automatycznie aktywne po załadowaniu strony logowania, co przyspiesza logowanie
• LiquidJS dla szablonów e-mail — system szablonów powiadomień SMTP przeszedł z custom regex na LiquidJS, oferując zmienne ({{ msg }}, {{ name }}, {{ status }}, {{ hostnameOrURL }}) i pełną obsługę HTML
• Proxy dla powiadomień — zmienna środowiskowa pozwala kierować ruch notification providers przez proxy
• Poprawki bezpieczeństwa — łatka podatności vm2 w proxy-agent, aktualizacja zależności
• Usunięcie Alpine Docker images — tylko Debian-based images od v2
• Wymaganie Node.js 20.4+ — usuniecie wsparcia dla Node.js 14, 16 i 18

Breaking changes i migracja z v1 do v2

Wersja 2.0 to major release z istotnymi breaking changes. Jeśli aktualnie korzystasz z Uptime Kuma 1.x, przed aktualizacją musisz zapoznać się z listą zmian, które mogą wpłynąć na Twoją konfigurację.

Lista breaking changes w v2.0

Uptime Kuma 2.1 — Globalping, domain expiry i nowe integracje

Wersja 2.1.0, wydana 7 lutego 2026, to kolejny duży krok naprzód. Obejmuje łącznie 250 scalonych pull requestów i wprowadza trzy funkcje, na które społeczność czekała od dawna: monitoring rozproszony (Globalping), monitoring wygasania domen (RDAP) i nowe integracje z systemami ticketowymi.

Globalping — monitoring z całego świata

Do wersji 2.0 włącznie Uptime Kuma monitorowała usługi wyłącznie z jednej lokalizacji — z serwera, na którym była zainstalowana. Jeśli Twój serwer monitoringu stał w Warszawie, wszystkie testy ping, HTTP i DNS wychodziły z Warszawy. Nie widziałeś problemów regionalnych — np. niedostępności strony w USA, Azji czy Ameryce Południowej spowodowanej błędami routingu, problemami CDN lub cenzurą DNS.

Globalping to open-source'owa platforma sieci sond rozmieszczonych na całym świecie, utrzymywana przez społeczność i organizację jsdelivr. Integracja z Uptime Kuma 2.1 pozwala uruchamiać testy z dowolnej lokalizacji na świecie — bez konieczności wdrażania własnych serwerów w różnych regionach.

Jak skonfigurować monitor Globalping

Domain Expiry Monitoring — monitoring wygasania domen (RDAP)

Wygaśnięcie domeny to jeden z najbardziej wstydliwych i kosztownych błędów, jaki może popełnić firma. Wielkie marki — w tym Google, Microsoft, Foursquare i Marketo — straciły swoją domenę przynajmniej raz z powodu przeoczenia daty odnowienia. Uptime Kuma 2.1 wprowadza natywny monitoring wygasania domen, który eliminuje to ryzyko.

Funkcja działa w oparciu o protokół RDAP (Registration Data Access Protocol) — następcę przestarzałego WHOIS. Uptime Kuma odpytuje serwery RDAP o datę wygaśnięcia domeny i wysyła powiadomienie, gdy zbliża się termin. Kluczowe cechy:

• Automatyczne sprawdzanie — domeny są sprawdzane raz dziennie, wyniki cachowane w bazie danych
• Deduplikacja — jeśli wiele monitorów URL wskazuje na tę samą domenę, RDAP lookup odbywa się tylko raz
• Konfigurowalny próg — ustawiasz liczbę dni przed wygaśnięciem, po której otrzymasz alert (np. 30 dni, 14 dni, 7 dni)
• Zintegrowane z powiadomieniami — alert o wygasającej domenie trafia do tych samych kanałów (Telegram, Discord, e-mail) co alerty o niedostępności

Nowe notification providers w v2.1

Wersja 2.1 dodaje kolejne integracje z systemami powiadomień:

• Jira Service Management — tworzenie incydentów bezpośrednio w Jira SM, idealne dla zespołów ITSM korzystających z Atlassian
• Google Sheets — zapis zdarzeń monitoringu do arkusza Google. Przydatne do tworzenia niestandardowych raportów, dashboardów i historii incydentów bez dodatkowej infrastruktury
• HaloPSA — integracja z HaloPSA (Professional Services Automation), popularnym narzędziem MSP. Dodano przekazywanie monitor_id i heartbeat_id do ticketów

Ulepszenia szablonów powiadomień

Wersja 2.1 kontynuuje rozwój systemu szablonów LiquidJS:

• Discord — niestandardowe wiadomości i presety formatowania. Możesz teraz w pełni dostosować treść i wygląd embedów Discord
• Ntfy — niestandardowe tytuły i szablony wiadomości dla powiadomień push ntfy (self-hosted)
• Slack — opcja dołączenia nazwy grupy monitora do powiadomień, co ułatwia filtrowanie w kanałach z wieloma usługami

Poprawki w wersji 2.1

Poza nowymi funkcjami, wersja 2.1 naprawiła wiele drobnych, ale uciążliwych błędów:

• Poprawiono obsługę wygasania certyfikatów SSL
• Naprawiono strefy czasowe w RSS pubDate
• Tagi nie zasłaniają już nazw monitorów w liście
• Rozwijanie/zwijanie grup działa poprawnie z zagnieżdżonymi grupami
• Poprawiono obsługę błędów klienta RADIUS (czyszczenie socketów)
• Poprawiono parsowanie JSON w monitorze MongoDB

Uptime Kuma 2.2 — SOCKS proxy, WhatsApp i poprawki

Wersja 2.2.0 (5 marca 2026) i 2.2.1 (10 marca 2026) to mniejsze, ale wartościowe wydania skupione na rozszerzeniu możliwości powiadomień i poprawkach stabilności.

Nowe funkcje w v2.2

• SOCKS proxy dla powiadomień — notification providers mogą teraz kierować ruch przez proxy SOCKS. Kluczowe dla instalacji w sieciach korporacyjnych z ograniczonym dostępem do internetu
• WhatsApp (360messenger) — nowy notification provider umożliwiający wysyłanie alertów przez WhatsApp za pośrednictwem platformy 360messenger
• Szablony Signal — Signal notification provider obsługuje teraz szablony wiadomości LiquidJS, podobnie jak Discord i ntfy
• Fluxer notification (v2.2.1) — nowy provider powiadomień Fluxer
• Structured JSON logging — możliwość generowania logów w formacie JSON, co ułatwia integrację z ELK Stack, Loki, Splunk i innymi systemami agregacji logów

Poprawki bezpieczeństwa

• GHSA-c7hf-c5p5-5g6h — łatka brakującej autoryzacji na endpoincie ping badge, która umożliwiała wyciek czasów odpowiedzi monitorów
• GHSA-v832-4r73-wx5j (v2.2.1) — łatka podatności SSTI (Server-Side Template Injection) w szablonach powiadomień, która umożliwiała odczyt plików z serwera

Istotne poprawki

• Poprawiono obsługę wielu współbieżnych połączeń SQLite
• Rozwiązano problem kompatybilności ze starszymi wersjami Node.js 20 (~20.17.0)
• Poprawiono obsługę błędów Globalping (retry przy statusie 500)
• Naprawiono walidację rekordów PTR DNS
• Usunięto wymuszanie statusu DOWN w monitorach grupowych
• Dodano wyświetlanie certyfikatu SSL dla monitorów TCP na stronach statusu
• Usunięto zależności AWS SDK i Azure jako pakietów

Migracja z v1 na v2 — co warto wiedzieć

Migracja z Uptime Kuma v1 na v2 jest procesem jednokierunkowym — po aktualizacji nie można wrócić do v1 bez przywrócenia backupu. Kluczowe informacje o procesie migracji:

Najważniejsze zasady migracji

• Backup jest absolutnie kluczowy — projekt oficjalnie podkreśla wagę backupu, powtarzając to zalecenie trzy razy w dokumentacji. Przed jakąkolwiek aktualizacją wykonaj pełną kopię zapasową katalogu data/
• Migracja bazy danych jest automatyczna — po uruchomieniu nowej wersji Uptime Kuma automatycznie wykrywa starą bazę i przeprowadza migrację, agregując dane heartbeat do zoptymalizowanego formatu
• Proces może trwać długo — na wolniejszym sprzęcie lub przy dużej ilości danych migracja może trwać nawet kilka godzin. Nie przerywaj procesu — przerwana migracja wymaga przywrócenia z backupu
• Wymagane minimum 2x rozmiar bazy na dysku — migracja tworzy tymczasowe dane podczas konwersji
• Node.js 20.4+ jest wymagany dla wersji 2.x (istotne przy instalacjach bare metal)

Hosting zarządzany — zawsze najnowsza wersja bez wysiłku

Migracja z v1 na v2, śledzenie breaking changes, testowanie kompatybilności notification providers, monitorowanie logów migracji, aktualizacja Node.js — to wszystko wymaga czasu, wiedzy i uwagi. Dla wielu firm i freelancerów ten czas jest zbyt cenny, by poświęcać go na administrację narzędziem, które ma monitorować — a nie być monitorowane.

Hosting zarządzany Uptime Kuma na SmartXHosting.pl eliminuje ten problem całkowicie:

• Automatyczne aktualizacje — Twoja instancja jest zawsze na najnowszej stabilnej wersji. Gdy wychodzi v2.2.1 z łatką bezpieczeństwa — jest wdrożona w ciągu godzin, nie dni
• Zero migracji — nie musisz planować okna maintenance, robić backupów, monitorować logów. Aktualizacja dzieje się transparentnie
• Codzienny backup — automatyczny, bez konfiguracji. Twoje dane monitoringu są bezpieczne
• Gotowa instancja — własna subdomena (np. twoja-firma.uptimekuma.eu), SSL, reverse proxy — wszystko skonfigurowane
• Wsparcie techniczne — dedykowane wsparcie w języku polskim, gdy potrzebujesz pomocy z konfiguracją monitorów, powiadomień czy stron statusu

Co dalej — roadmap i przyszłość Uptime Kuma

Uptime Kuma rozwija się w imponującym tempie. Patrząc na dotychczasowy trend wydań i aktywność na GitHubie, możemy zarysować kierunki, w których zmierza projekt.

Potwierdzone kierunki rozwoju

• Rozbudowa szablonów LiquidJS — coraz więcej notification providers otrzymuje obsługę niestandardowych szablonów. W v2.1 Discord i ntfy, w v2.2 Signal. Kolejne providers (Slack, Telegram, Webhooks) prawdopodobnie pójdą w tym samym kierunku
• Nowi notification providers — każde wydanie dodaje 2–3 nowe integracje. Społeczność aktywnie zgłasza PR-y z nowymi providerami, a ich akceptacja jest dość szybka
• Poprawa Globalping — wersja 2.2 już naprawiła obsługę błędów i retry w Globalping. Spodziewamy się dalszego rozwoju — np. monitoringu z wielu lokalizacji w jednym monitorze, dashboardu geograficznego
• Ciągłe poprawki bezpieczeństwa — projekt aktywnie reaguje na zgłoszenia GHSA i aktualizuje zależności

Funkcje poszukiwane przez społeczność

Na GitHubie Uptime Kuma najczęściej głosowane feature requesty obejmują:

• API do zarządzania monitorami — oficjalne REST API do tworzenia, edycji i usuwania monitorów programatycznie (obecnie dostępne tylko nieoficjalne API przez WebSocket)
• Ulepszone strony statusu — więcej opcji customizacji, komponenty (maintenance, incidents), integracja z CSS frameworkami
• Eksport raportów — generowanie raportów uptime w formacie PDF/CSV za wybrany okres
• Multi-location monitoring natywny — monitoring z wielu lokalizacji bez konieczności tworzenia osobnych monitorów (agregacja wyników z różnych sond)
• Dashboardy i wizualizacje — bardziej zaawansowane wykresy, heatmapy, porównania trendów

Tempo rozwoju projektu pozwala oczekiwać, że wiele z tych funkcji pojawi się w nadchodzących wydaniach 2.x.

Najczęściej zadawane pytania