Uptime Kuma 2.0 landed in 2025 after almost a year of open beta. The version number looks modest — 1.x to 2.x — but the jump is genuinely bigger than it sounds. The database layer is different, the framework underneath the UI is different, Docker runs rootless by default, and several new monitor types have been added. If you are running 1.x and wondering whether to upgrade, or if you are new to Uptime Kuma altogether and need to know which version you will be working with, this guide walks through every change that matters and what it means specifically for UK users. If you have never looked at Uptime Kuma before, our plain-English introduction is the right place to start before this one.
The headline: what actually changed
Before we go into detail, here is the honest two-sentence summary. Uptime Kuma 2.x is the same product, better engineered underneath. If you were happy with 1.x, you will be happy with 2.x — only more so, once the upgrade is behind you.
The changes split into two categories. Under the bonnet: MariaDB is now supported alongside SQLite, the front-end has moved from Vue 2 to Vue 3, the official Docker image runs rootless by default and the notification channel count has ticked up to 91. On the surface: new monitor types (notably several for modern API patterns), a polished status-page editor, and a handful of small UI improvements that collectively add up to an interface that feels more like a 2026 application than a 2022 one.
Database: v1 SQLite only, v2 SQLite or MariaDB · Front-end: v1 Vue 2, v2 Vue 3 · Docker: v1 runs as root by default, v2 runs rootless by default · Monitor types: v1 ~24, v2 30+ · Notification channels: v1 ~80, v2 91 · Licence: MIT in both.
MariaDB support — the big database change
The most consequential change in 2.x, and the one most people miss when they scan the release notes, is that Uptime Kuma now supports MariaDB as a database back-end. SQLite is still the default and still works beautifully for single-instance deployments — which is most deployments — but having a real client-server database as an option unlocks several scenarios that were awkward or impossible before.
Why does it matter? SQLite stores everything in a single file on the local disk. That file is easy to back up, easy to move, and fast for a few hundred monitors. It is also a single point of lock contention when writes spike — for example during the first few minutes after a mass outage, when many monitors flip state at once. MariaDB sidesteps that by separating the database process from the application process, and it is the foundation on which a future clustered version of Uptime Kuma could plausibly be built.
For the typical UK SME with one instance monitoring 30 to 150 services, the answer to "should I switch to MariaDB?" is usually no, stay on SQLite. SQLite is simpler, faster to back up, and has one fewer moving part. You should consider MariaDB if you are running several hundred monitors with short intervals, if you need the database on a different host from Uptime Kuma for policy reasons, or if you want to share the database with other applications for reporting.
Two more MariaDB-specific niceties worth knowing about. First, migration from SQLite to MariaDB is supported with an in-app conversion; you do not have to export and re-import by hand. Second, a MariaDB back-end unlocks slightly better historical-data retention because the storage engine handles large row counts more efficiently than SQLite. If your compliance regime requires you to keep 18 months of monitor history online — rather than summarised or archived — MariaDB is a cleaner path.
Vue 3 and the UI overhaul
The second big under-the-bonnet change is that the front-end has moved from Vue 2 to Vue 3. Vue 2 reached end-of-life in December 2023, which meant that staying on it was increasingly untenable for security and dependency reasons. The Vue 3 migration unlocks modern browser features, faster rendering and — for the project maintainers — access to a much larger pool of compatible libraries.
For an end user, the visible result is that the 2.x interface is noticeably snappier than 1.x. Panels load faster, the monitor list scrolls smoothly even at a few hundred monitors, and chart rendering no longer pauses the browser when you switch views. The actual screens are mostly in the same places — this is not a ground-up redesign — but the polish is unmistakable.
There is one practical implication: some very old browsers that worked with 1.x do not work with 2.x. If you have a colleague still running an ancient version of Internet Explorer or an unpatched Edge from 2017, that will be the day they need to upgrade. For anyone on a recent Chrome, Firefox, Safari or Edge, there is nothing to do.
Rootless Docker by default
Uptime Kuma has always shipped a Docker image as the recommended installation path. In 2.x, the official image runs as a non-root user by default. This is a security best practice that has become standard across the ecosystem: if the application process does not need to be root inside the container, it should not be root, so that a container escape cannot trivially become a host root shell.
The practical consequence is that the data volume permissions are slightly different between 1.x and 2.x. A fresh 2.x install is fine out of the box; a 1.x-to-2.x upgrade needs a one-time chown of the data directory so that the non-root user inside the container can read and write it. The project documentation walks through the exact commands; the one-liner is straightforward but is the single most common source of upgrade trouble reports on GitHub.
If you are on a managed plan, none of this touches you — the provider handles the container runtime and its permissions. If you are self-hosting, it is ten minutes of attention the first time you upgrade, and zero attention thereafter.
New and improved monitor types
Uptime Kuma 2.x ships 30+ monitor types, up from about 24 in 1.x. The new additions focus mostly on modern API patterns and a few infrastructure checks that were missing before.
Notable additions:
- JSON Query v2 — improved JSONPath support, so you can now assert on nested response fields that used to need a keyword workaround
- gRPC — direct support for gRPC endpoints, with health-check protocol awareness
- Kafka Producer — publish a heartbeat message and verify the broker accepts it
- RabbitMQ — check a queue is reachable and within an expected message backlog
- SNMP — basic SNMP polling for network device health
- Tailscale Ping — monitor reachability across a Tailscale mesh without exposing endpoints publicly
All of the 1.x monitor types are still present and behave the same way. HTTP(s), the workhorse monitor that covers the majority of day-to-day needs, has had a quiet polish too: the underlying HTTP client now honours more of the edge-case headers that older versions occasionally tripped over. For the deep dive on setting up HTTP monitoring, see our complete HTTP(s) monitoring guide.
Notification channel additions
The notification-channel count is up to 91 in 2.x, with a few additions worth calling out. WhatsApp Business, which had been community-maintained in 1.x, is now a first-class channel. Signal has matured from a bridge-only integration into direct support. Several incident-management platforms — Opsgenie, PagerDuty and Grafana OnCall — have been updated to their current APIs.
For UK users, the notification side of 2.x is also where we see the biggest practical difference in deliverability. The SMTP client has been reworked to handle modern TLS negotiation more robustly, which means Gmail app passwords, Microsoft 365 and strict corporate SMTP relays behave more consistently than they did in 1.x. If email alerts are your primary channel, our SMTP notifications guide walks through the full setup.
The managed Uptime Kuma offer on smartxhosting.uk runs the current 2.x stable release. Updates arrive automatically when Louis Lam ships them, so you always get the latest monitor types and notification channel fixes without doing anything yourself. You still configure each channel in the application after logging in — the application is unchanged from the open-source release.
Status page improvements
Status pages were already one of Uptime Kuma's strongest features in 1.x. In 2.x they have been tightened in several small ways that add up. The editor is more WYSIWYG — you can see how the public page will look while you are building it — and custom CSS now applies in the editor preview, not only on the published page. Maintenance windows can be scheduled further in advance and recur on a weekly pattern. Incident posts support basic formatting (headings and lists) rather than plain text only. And the API for status pages has been stabilised, which means third-party themes and exports should survive future upgrades without breaking.
The practical benefit is that the team member who maintains the status page — often a marketing or customer-success colleague rather than a developer — can work more independently. In 1.x they frequently had to go to the engineering team for CSS changes or to schedule recurring maintenance. In 2.x, most of those tasks are clickable.
Breaking changes you need to know about
Most upgrades from 1.x to 2.x are uneventful, but there are a handful of breaking changes. None are showstoppers; all are solvable with a small amount of attention.
- Data volume permissions. As noted above, the rootless Docker change means existing data volumes need a one-time chown. The upgrade will refuse to start otherwise.
- Old browser support. Vue 3 drops support for Internet Explorer and several ancient browser builds. If you have users on those, they will need to upgrade their browser to access the dashboard.
- API endpoint shapes. A handful of internal API endpoints have changed shape. If you have scripts that poll Uptime Kuma's unofficial API, review them against the v2 documentation — several fields moved, a few were renamed.
- Custom themes. Community-contributed themes that patched 1.x internals will almost always need work to run against 2.x. Themes that only override CSS variables are unaffected.
- Third-party integrations. Projects that speak to Uptime Kuma — AutoKuma, uptime-kuma-api and similar — mostly ship 2.x-compatible releases alongside the main project, but you should check version compatibility before upgrading.
- Node.js version bump. The 2.x line targets Node.js 20 and later. If you are installing Uptime Kuma as a plain Node.js service rather than via Docker, you will need to ensure your host has a supported runtime before the upgrade.
- Default log format. Structured log output has been reworked in 2.x. If you are shipping Uptime Kuma's logs to an external aggregator (Loki, Elasticsearch or similar), the parser rules likely need a small adjustment. Plain tail-the-file inspection is unchanged.
None of these are showstoppers, but any organisation that has even a moderately automated deployment pipeline will want to walk through the list once before the upgrade rather than discover each item during the upgrade.
Migrating from v1 to v2 — the safe way
The safe migration pattern is straightforward and does not involve anything clever.
- Back up your v1 database. Export from the Uptime Kuma UI (Settings → Backup) and keep a copy somewhere that is not your Uptime Kuma server.
- Read the v2 release notes for the specific release you are targeting. The project publishes a detailed upgrade checklist with every release.
- Do a dry run on a staging instance. Spin up a separate 2.x installation, restore your v1 backup into it, and verify that your monitors, notifications and status pages work as expected. This step is worth the twenty minutes it costs.
- Upgrade the production instance once the staging dry run is clean. For Docker users this is usually a container replace against the 2.x image; for bare-metal Node.js users it is a package update followed by a restart.
- Verify post-upgrade that all monitors are running, alerts arrive at the usual destinations, and the status page renders correctly for an anonymous visitor.
If any of this feels like more operational attention than you want to give to monitoring infrastructure, that is one of the strongest arguments for managed hosting. The provider-side team absorbs the upgrade work entirely; your first sign that v2 has arrived is usually a slightly different notification channel list in the dropdown or a new monitor type that was not there yesterday. For any shop that treats monitoring as a necessary capability rather than a hobby, that hands-off upgrade cycle is worth its weight in avoided Saturday afternoons.
What this means on a managed plan
The short version: if you are on a managed Uptime Kuma plan with smartxhosting.uk, the v1-to-v2 upgrade already happened or is being rolled out on your behalf. The platform tracks the current 2.x stable release, so the breaking changes listed above are absorbed by the provider — including the data-volume permissions dance and any dependency updates.
What you will notice is the new features appearing in your UI over time: new monitor types in the drop-down, the updated notification channels, the improved status-page editor. No action needed from your side; your existing monitors, notifications and status pages carry forward untouched.
If you were previously self-hosting and are considering the switch specifically to avoid dealing with the 2.x upgrade, that is a reasonable reason on its own. If you are picking a monitoring tool from scratch and wondering how Uptime Kuma 2.x stacks up against commercial alternatives, our Uptime Kuma vs Uptime Robot comparison is the natural follow-on.
One more point worth noting: managed platforms typically introduce new Uptime Kuma releases after a brief internal soak — usually a week or two — rather than the day they are published. That is a feature, not a bug. It means you get the bug fixes from point releases before the bleeding edge of a fresh minor version hits your production instance. For anyone who has ever been burned by shipping the first hour of a new release straight into production, that caution will be welcome.
Summary and next steps
Uptime Kuma 2.x is the natural evolution of a product that was already good. MariaDB support opens the door to larger deployments; Vue 3 gives the UI the polish it deserves; rootless Docker is the security default that should have been in place from the start; new monitor types fill out genuine gaps in the 1.x toolbox; status pages are now maintainable by non-developers. None of it is revolutionary. All of it is worth having.
The migration from 1.x is straightforward if you do it carefully; the path is entirely removed if you are on managed hosting. Either way, staying on 1.x long-term is not advisable — Vue 2 itself is past end-of-life and will not receive security updates going forward. The community is already treating 2.x as the baseline assumption in support threads, blog posts and third-party tooling, which is the usual sign that a legacy version has become a backwater rather than a supported path.