Dlaczego wersja 2 to kamień milowy w historii Uptime Kuma • Oś czasu — od pierwszych zapowiedzi do stabilnego wydania • Uptime Kuma 2.0 — przełomowe zmiany • MariaDB/MySQL — koniec ery wyłącznie SQLite • Nowy interfejs — Vue 3 + Vite • Rootless Docker — bezpieczeństwo na pierwszym miejscu • Breaking changes i migracja z v1 do v2 • Uptime Kuma 2.1 — Globalping, domain expiry i nowe integracje • Uptime Kuma 2.2 — SOCKS proxy, WhatsApp i poprawki • Jak bezpiecznie przejść z v1 na v2 — krok po kroku • Hosting zarządzany — zawsze najnowsza wersja bez wysiłku • Co dalej — roadmap i przyszłość Uptime Kuma • Najczęściej zadawane pytania
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.
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:
| Data | Wydarzenie | Znaczenie |
|---|---|---|
| 2023 | Rozpoczęcie prac nad v2 | Migracja frontendu na Vue 3, planowanie obsługi MariaDB |
| Wiosna 2024 | Uptime Kuma 2.0.0-beta.0 | Pierwsza publiczna beta z MariaDB i nowym UI |
| 2024 | Seria beta (beta.0–beta.1) | Testy społeczności, naprawianie błędów migracji, optymalizacja |
| 20.10.2025 | Uptime Kuma 2.0.0 — stabilne wydanie | Oficjalne wydanie z MariaDB, Vue 3, rootless Docker |
| 10.2025–01.2026 | Uptime Kuma 2.0.1 | Poprawki błędów z wersji 2.0.0 |
| 07.02.2026 | Uptime Kuma 2.1.0 | Globalping, domain expiry, Jira SM, Google Sheets, HaloPSA |
| 05.03.2026 | Uptime Kuma 2.2.0 | SOCKS proxy dla powiadomień, WhatsApp (360messenger), Signal templates |
| 10.03.2026 | Uptime Kuma 2.2.1 | Fluxer notification, poprawki bezpieczeństwa, stabilność |
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.
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.
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:
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_hasloAlternatywnie, 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.
sqlite3-to-mysql), ale wszelkie problemy wynikające z takiej migracji nie są objęte oficjalnym wsparciem projektu. Najlepszym podejściem jest start z MariaDB od nowej instalacji.
| Scenariusz | Zalecana baza | Dlaczego |
|---|---|---|
| Homelab, <100 monitorów | SQLite | Zero konfiguracji, minimalne zasoby |
| Mała firma, 100–500 monitorów | SQLite lub MariaDB | SQLite wystarczy, MariaDB dla zapasu |
| Agencja/MSP, 500+ monitorów | MariaDB | Lepsza współbieżność, skalowalność |
| Enterprise, 1000+ monitorów | MariaDB (zewnętrzna) | Replikacja, backup, wysoka dostępność |
| Interwał <60s, dużo monitorów | MariaDB | SQLite może blokować przy częstych zapisach |
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.
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.
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.
| Tag obrazu | Użytkownik wewnętrzny | Zastosowanie |
|---|---|---|
louislam/uptime-kuma:2 | root (domyślnie) | Kompatybilność wsteczna, prostota konfiguracji |
louislam/uptime-kuma:2-rootless | non-root (node) | Zwiększone bezpieczeństwo, zgodność z politykami K8s |
Obraz rootless uruchamia procesy Node.js jako użytkownik node zamiast root. To istotne w kontekście:
louislam/uptime-kuma:2-rootless. Pamiętaj jednak, że obraz rootless nie jest zalecany do migracji z v1 na v2 — proces migracji wymaga uprawnień root. Najpierw zmigruj na standardowy obraz :2, a potem opcjonalnie przełącz na :2-rootless.
Oprócz trzech głównych zmian, wersja 2.0.0 przyniosła szereg mniejszych, ale istotnych usprawnień:
{{ msg }}, {{ name }}, {{ status }}, {{ hostnameOrURL }}) i pełną obsługę HTMLWersja 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ę.
| Zmiana | Wpływ | Co zrobić |
|---|---|---|
| Badge endpoints — parametr duration akceptuje tylko: 24, 24h, 30d, 1y | Jeśli używasz badge'y z niestandardowymi wartościami (np. 7d, 90d) | Zaktualizuj URL badge'y do obsługiwanych wartości |
| Usunięcie Backup/Restore z JSON | Stara metoda eksportu/importu JSON przestaje działać | Backup realizuj przez kopię katalogu data/ |
| Usunięcie DNS cache dla HTTP monitorów | Deprecated DNS cache już nie działa | Docker: polegaj na wbudowanym nscd |
| Domyślne retries = 0 (było 1) | Nowe monitory natychmiast oznaczą usługę jako DOWN | Ręcznie ustaw retries przy tworzeniu monitora |
| Szablony e-mail → LiquidJS | Zmienne w szablonach SMTP są case-sensitive | Sprawdź i zaktualizuj szablony powiadomień e-mail |
| Alpine Docker images — usunięte | Użytkownicy Alpine muszą przejść na Debian | Zmień tag obrazu na louislam/uptime-kuma:2 |
| Node.js <20.4 — nie wspierany | Bare metal z Node.js 14/16/18 | Zaktualizuj Node.js do wersji 20.4+ |
| Stare przeglądarki — nie wspierane | IE11, stare Safari, Edge Legacy | Używaj nowoczesnej przeglądarki |
libseccomp2. Wymagana jest aktualizacja systemu do Debian Bullseye lub nowszego przed migracją Uptime Kuma.
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.
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.
1.
W formularzu tworzenia monitora wybierz typ "Globalping" z rozwijanej listy. Pojawią się opcje konfiguracji specyficzne dla Globalping.
2.
Globalping obsługuje trzy rodzaje testów: Ping (ICMP lub TCP), HTTP (z konfigurowalnymi nagłówkami) i DNS (z wyborem typu rekordu). Wybierz odpowiedni dla swojego scenariusza.
3.
Możesz wybrać lokalizację na różnym poziomie szczegółowości: "world" (losowa sonda z całego świata), kontynent (np. Europe), kraj (np. Brazil), miasto (np. Rio de Janeiro) lub nawet typ sieci (np. sieć domowa w Rio). Pozostawienie "world" oznacza losowy wybór sondy z całej sieci.
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:
Wersja 2.1 dodaje kolejne integracje z systemami powiadomień:
monitor_id i heartbeat_id do ticketówWersja 2.1 kontynuuje rozwój systemu szablonów LiquidJS:
Poza nowymi funkcjami, wersja 2.1 naprawiła wiele drobnych, ale uciążliwych błędów:
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.
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:
data/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:
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.
Na GitHubie Uptime Kuma najczęściej głosowane feature requesty obejmują:
Tempo rozwoju projektu pozwala oczekiwać, że wiele z tych funkcji pojawi się w nadchodzących wydaniach 2.x.
Nie ma natychmiastowego przymusu, ale jest to zdecydowanie zalecane. Gałąź 1.x nie otrzymuje już nowych funkcji — jedynie krytyczne łatki bezpieczeństwa. Wszystkie nowe typy monitorów (Globalping, domain expiry), notification providers (Jira SM, Google Sheets, WhatsApp) i usprawnienia (LiquidJS templates, rootless Docker, SOCKS proxy) trafiają wyłącznie do v2. Im dłużej zwlekasz z migracją, tym większe ryzyko, że Twoja instalacja stanie się narażona na niezałatane podatności.
Proces migracji jest dobrze przetestowany i tysiące użytkowników przeszło go bez problemów. Kluczowe jest jednak: (1) wykonanie backupu katalogu data/ przed aktualizacją, (2) nieprzerywanie procesu migracji, który może trwać od kilku minut do kilku godzin w zależności od ilości danych, (3) upewnienie się, że masz wystarczająco miejsca na dysku. Jeśli coś pójdzie nie tak — przywracasz backup i próbujesz ponownie.
Migracja z SQLite do MariaDB nie jest oficjalnie wspierana. Możesz użyć narzędzia sqlite3-to-mysql, ale wszelkie problemy wynikające z takiej konwersji nie są objęte wsparciem projektu. Najlepszym podejściem jest start z MariaDB od nowej instalacji v2 — np. przy okazji wdrożenia nowego serwera lub przeprowadzki do hostingu zarządzanego.
Globalping jest darmowy. Bez konta masz 250 testów na godzinę (przypisanych do IP). Po założeniu darmowego konta na Globalping Dashboard limit rośnie do 500 testów/godzinę. Dla większości instalacji Uptime Kuma z kilkudziesięcioma monitorami i interwałem 60–300 sekund to wystarczający limit. Dla większych wdrożeń Globalping oferuje płatne plany z wyższymi limitami.
Tak, domeny .pl są obsługiwane przez RDAP. Monitor domain expiry sprawdza datę wygaśnięcia domeny raz dziennie i wysyła powiadomienie na skonfigurowaną liczbę dni przed wygaśnięciem. Niektóre rzadsze TLD (np. .co, .de) mogą nie obsługiwać RDAP — w takim przypadku w logach pojawi się ostrzeżenie. Popularne TLD (.com, .net, .org, .io, .pl, .eu) działają bez problemów.
Tak, ale wymaga dodatkowej konfiguracji. Ponieważ obraz rootless uruchamia procesy jako użytkownik node, bezpośredni dostęp do /var/run/docker.sock wymaga odpowiednich uprawnień. Zalecane rozwiązanie to użycie Docker socket proxy (np. Tecnativa/docker-socket-proxy), który filtruje dostęp do API Dockera i jest bezpieczniejszym podejściem niezależnie od typu obrazu.
Dla Dockera: dowolny system z Docker Engine (Linux, Windows, macOS). Dla bare metal: Node.js 20.4+ (usunięto wsparcie dla Node.js 14, 16 i 18). RAM: minimum 1 GB, zalecane 2 GB dla 200+ monitorów. Dysk: kilkaset MB na aplikację + dane. Systemy: Linux (Debian Bullseye+, Ubuntu 20.04+, Fedora, Arch, AlmaLinux), Windows 10+/Server 2012 R2+. Raspberry Pi 3/4/5 jest w pełni obsługiwany (ARM image). Debian/Raspbian Buster nie jest obsługiwany z powodu błędu w libseccomp2.