v2.0.0-Release

[CommanderStorm]

This was originally a PR here, but has been transformed into an issue due to being pin-able

what has been done?

We are hard at work improving Uptime Kuma.
If you want to have a look at the full set of features for v2.0, have a look here.

Most notably this includes (a full migration guide will be made before the release, dont worry):

• better performance through external MariaDB, storing heartbeats in an aggregated form, full server-side pagination for important events
  => even though benchmarking is still out, we are confident that this pushes the prominent "limits" (highly hardware-dependent, not a limit imposed by us) ~500 Monitor or ~1.5GB DB-size
  A large part of the focus in this release is on performance. We don't know if we are optimising for the right thing, see Can/should we add privacy-respecting usage metrics? #4456 for a discussion on this topic.

Tip

If you are affected by the performance problems of v1, you need to reduce the amount of data you store.
The core problem is that Uptime Kuma in v1 has to do a table scan of the entire heartbeat table for some operations.

The solution boils down to having a lower amount of data => making Uptime Kuma less worried about reading those gigabytes of data.:

• reduce the retention and execute a manual cleanup under /settings/monitor-history
• Increase the time between checks
• pause or reduce the amount of monitors
• delete the specific history of less essential monitors (to "lower" their retention below the configured maximum)

• tightening the security via offering rootless docker images images #2086 #4052
• deprecated backup feature has been dropped (see Drop backup #3892 (comment) for an explanation why)
• deprecated cacheable lookups (not the same as nscd) have been dropped CacheableLookup was never used for http monitors #3762
• A lot of bugfixes, some minor new features (see the milestone)

what is needed to get 2.0.0-beta.0 released

Note

We hope 2.0.0-beta.0 can be released in spring 2024, which doesn't include the e2e tests yet. During the beta test, we will try to work on implementing the e2e tests.

Tip

How can I get involved?

While most of the bugs noted below require reading some code
=> gaining some context about how the aggregated tables work, some work do not and are such better starting points:

• writing a synthetic benchmark which spawns some monitors and looks how the server handles it
• helping in writing e2e tests using playwright

• some features have not adopted to new aggregate tables yet
  • Migrate existing heartbeat data into aggregate tables
  • Clear stats (Update clear stats #4324)
  • History retention
  • Ping chart (Feat: Use UptimeCalculator for PingChart #4264)
  • Heartbeat table keeps 24-48 hours data only (excepted for important events, it will keep longer for the event list) (Can be deferred)
  • Test and fix the Badges feature (originally introduced in Add badges #1119, a big headache for us right now because the new table schemas break this feature a lot)
• Testing
  • Drop Jest e2e testing  #2174
  • Playwright + Native Node Test Runner #3893
  • Write more E2E Testing using Playwright
• Document how the aggregated tables work for our contributors in our contribution guide
• Migration guide from v1 to v2 (Wiki) Migration Guide from v1 to v2 uptime-kuma-wiki#53
  • New Docker tags
  • Notify about breaking changes and write a migration guide
    • removed variable badges
    • SMTP-templating Feature: SMTP-templating of customBody and customHeader via liquidjs #3414
      • dropped support for vArIaBlE Cased variables
      • deprecated UPPERCASE variables (this was added to make the v1⇒v2 migration more seamless, but will be removed in v3)
    • removed deprecations:
      • CacheableLookup was never used for http monitors #3762
      • Drop backup #3892
    • Update to respect docker compose v2 #4289
    • default retires is now 0 instead of 1
• Benchmark where the new performance limits are
• Write the changelog and Release 2.0.0-beta.0

[CommanderStorm]

@compgeniuses
Our installation guide only works for stable versions (it checks out a git tag to avoid users being on the wrong branch in npm run setup).
Pre-releases will be made once we don't have glaring bugs left, see my post above for which ones there are.

If you want to test-drive or contribute one of the areas named above, our contribution guide should have all the answers. If you are missing something for development, feel free to ping me.
We also have this way of testing PRs: https://github.com/louislam/uptime-kuma/wiki/Test-Pull-Requests

[timbo-tj]

What is the best way to try this out? We deploy via Docker on Railway.app and we use it to monitor our services. It is pretty low-stakes environment and I am happy to risk running a preview version of Uptime Kuma to get access to the new features and 'test run' it. But since it is not available on Docker hub I am not sure how to get started

[CommanderStorm]

In master, development happens for v2.0-dev.
We currently have NOT published a git/docker tag as we are NOT ready to have a public beta (see the checklist above)

You can:

• Test PRs via the path listed here
• help developing using the path laid out in our contribution guide
• subscribe to this issue or to releases to get notified of the beta once it releases

Note

If you want to use uptime kuma in any production environment, please refer to our installation guide.
We do not offer stability/semver guarantees for development versions such as v2.0-dev.
There will be a migration guide between the versions.