mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
When v2.0.0? #4159
Labels
No labels
A:accessibility
A:api
A:cert-expiry
A:core
A:dashboard
A:deployment
A:documentation
A:domain expiry
A:incidents
A:maintenance
A:metrics
A:monitor
A:notifications
A:reports
A:settings
A:status-page
A:ui/ux
A:user-management
Stale
ai-slop
blocked
blocked-upstream
bug
cannot-reproduce
dependencies
discussion
duplicate
feature-request
feature-request
good first issue
hacktoberfest
help
help wanted
house keeping
invalid
invalid-format
invalid-format
question
releaseblocker 🚨
security
spam
type:enhance-existing
type:new
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/uptime-kuma#4159
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Ionys320 on GitHub (Jun 9, 2025).
⚠️ Please verify that your question has not already been reported
🛡️ Security Policy
📝 Describe your problem
Hi!
I would like to know if there is any release date for v2, or what are the milestones that must be solved. Waiting for a looot of v2 features (some that I made), but can't switch to v2 easily using YunoHost until v2 is officially released.
📝 Error Message(s) or Log
🐻 Uptime-Kuma Version
1.23.16
💻 Operating System and Arch
Debian GNU/Linux 12
🌐 Browser
Vivaldi 7.4.3684.46 (Stable channel) (64 bits)
🖥️ Deployment Environment
57@CommanderStorm commented on GitHub (Jun 10, 2025):
From my pov nothing is blocking an immediate release.
Maybe the following would be nice to change before we roll out, given this could be breaking ^^:
@dorianborovina commented on GitHub (Jun 10, 2025):
I was wondering too. :)
@CommanderStorm commented on GitHub (Jun 10, 2025):
@Ionys320 if you have some spare time:
There are a few MAJOR bugs from v2.0 which are bad ^^
@Ionys320 commented on GitHub (Jun 11, 2025):
Hi @CommanderStorm, made some PRs for the two first bugs. Will try to check the last one when I'll have more time!
Hoping 2.0.0-beta.4 will be the last Beta version of v2!
@TingTing1990 commented on GitHub (Jun 13, 2025):
I want to use uptime now and don't want to use V1 to avoid the hassle of upgrading to V2, can I just use ghcr.io/louislam/uptime-kuma:2.0.0-beta.3 for now and wait for the bug fixes until the official release?
@CommanderStorm commented on GitHub (Jun 13, 2025):
Yes
@edgicat commented on GitHub (Jul 6, 2025):
It might be worth letting people know are archived logs being migrated to v2 on initial startup. Perhaps something on the webpage until complete would be good too.
@CommanderStorm commented on GitHub (Jul 6, 2025):
That migration takes a while and that people should do a backup is in the migration guide, or are we talking about different places in the docs?
@edgicat commented on GitHub (Jul 7, 2025):
Well that sounds like great advice, but unfortunately I didn't see any migration guide 🤦🏻.
I found I had a problem with my home assistant uptime Kuma HACS integration. When I checked my uptime Kuma dashboard it reported there was an update. I clicked on the date link and it took me straight to beta3 page on GitHub:
https://github.com/louislam/uptime-kuma/releases
A great page full of info on enhancements and fixes, but nothing on upgrading, that I could see.
I explored the home page on git hub:
https://github.com/louislam/uptime-kuma
Then followed the docker how to update link:
https://github.com/louislam/uptime-kuma/wiki/%F0%9F%86%99-How-to-Update
My bad if I've missed a vital page, it took me a little while to check the docker logs to see it was migrating event log history. Once I realised I let it do it's thing. If I had seen something on the beta page perhaps at the very top or the GitHub home page ref migration to v2 I would have followed it. No biggy from my point of view, just thought it was worth noting hence my post here.
Keep up the good work
@CommanderStorm commented on GitHub (Jul 7, 2025):
The migration guide is listed on our releases page => https://github.com/louislam/uptime-kuma/releases/tag/2.0.0-beta.0
I.e. where you (should) read about what has changed in each version.
The update guide you mentioned deliberately tells people how to update to install v1, given that v2 is in a beta..
If you skip a version, this means that you are also not reading the migration guide 🤷🏻
I have added a notification to the newer releases that reading the previous releases is recomended.
@TingTing1990 commented on GitHub (Jul 15, 2025):
Hi,
I updated the container to “nightly2” and the web page about force says “Front-end version does not match the back-end version!”
@rwjack commented on GitHub (Jul 16, 2025):
Users that are waiting for the non-beta v2 release are stuck with latest v1, which is accumulating vulnerabilities and hasn't been updated for more than 6 months.
Currently:
Vulnerabilities: CRITICAL: 1, HIGH: 44, MEDIUM: 100, LOW: 11, INFORMATIONAL: 0Basically the number #1 instruction in swebok states that releases should be made in small and steady increments, so users can properly test, and that no change is steep. This method also eliminates the majority of potential breaking changes during upgrades.
I'm aware It's not my decision nor call, I just don't get why we're dragging out the release for this long. It's never going to be perfect, some bit of code is always going need an update, a rework, etc. - the cycle is endless, but make it steady and push the damn release.
To clarify what I'm saying, with the release of v2, we'll have a base point where dependencies and vulnerable libraries are actually being bumped with weekly, bi-weekly or even monthly image rebuilds. There should be no rush for new features, but keeping the image maintained security wise is what really matters.
@philipshannon commented on GitHub (Jul 29, 2025):
It's not complicated "releases should be made in small and steady increments, so users can properly test, and that no change is steep. "
@rbuzzell commented on GitHub (Aug 1, 2025):
Echoing @rwjack here, I've been waiting to stand this up for 6 months. I need some of the features in the v2.0 version, and I'm not really eager to stand up the basically abandoned v1 or the 2.0 while it has a beta tag. Right now the signal I'm getting from the release history as a new adopter is "project virtually abandoned", but the commit history says "alive and well" and I'm not sure how to square those up.
@CommanderStorm commented on GitHub (Aug 1, 2025):
Hi all,
Thanks for the feedback — I really do understand the frustration, and I share the desire to get v2 out the door. Just to clarify my position: I'm a junior maintainer and unfortunately don’t have the authority to cut official releases. If I did, I’d have done it already — I’ve been running and monitoring v2 in production myself without issues.
That said, if there's a pressing need to keep v1 maintained in the meantime, feel free to contribute patches or backport support. We’re all volunteers here, and the project relies on community contributions to move forward. If there’s something you need, opening a PR is always welcome.
I can review PRs, but won't do the backporting myself.
I absolutely agree with the principle of small and steady releases, and I hope we can move in that direction long term.
Thanks again for caring about the project.
@louislam commented on GitHub (Aug 27, 2025):
My plan:
2.0.0-beta.4will be released shortly after #5991 get merged and fixed.2.0.0will be released if we don't see any critical bugs in2.0.0-beta.4.And unfortunately, I personally will not be able to put much free time on open source projects anymore. As @CommanderStorm said, this project needs community to move forward. Especially for testing pull requests and testing beta/nightly releases (https://github.com/louislam/uptime-kuma?tab=readme-ov-file#contributions). And once again thanks @CommanderStorm for supporting Uptime Kuma. Really appreciate, especially for the pull request reviews.
@gltched-usr commented on GitHub (Aug 27, 2025):
So in like 2 Years?
Don't understand me wrong, I really appreciate the time and work you all put in here but after waiting for a v2 release that long, I kinda lost hope that the draft pr will be completed soon.
@toxsick commented on GitHub (Aug 27, 2025):
@louislam Thanks a lot for all your hard work on kuma. It's an awesome tool since day one.
@gltched-usr please respect that work realities of open-source developers change and you are getting free stuff here.
@CommanderStorm commented on GitHub (Aug 27, 2025):
@gltched-usr
As mentioned above:
Please consider using the v2 beta.
That’s where ongoing fixes and improvements are happening, and feedback from real use helps uncover issues (as Louis said). I’m not backporting bugfixes to v1, so you’ll generally have a better experience with v2.
If you’d like to speed things up, the main blockers are reviews, testing, and bugfixing. Contributions in those areas are very welcome and help move the release forward. Remember that this project is run by volunteers, so progress depends on the time we can contribute.
@mamccorm commented on GitHub (Sep 1, 2025):
Thanks for the work on the project. Given v1.23.16 was last released back in December 2024, and theres been no GA release yet for v2, would the maintainers be open to considering a new v1 patch release, or a re-build of the previous patch releases image?
I would suspect a lot of these would disappear with a re-build in itself and it'd make the project more secure
@gltched-usr commented on GitHub (Sep 1, 2025):
Nah bro, they tell you to use the v2 beta branches, they don't care about v1 anymore and delay the release of v2 by making the scope of the v2 release bigger and bigger instead of just releasing v2 and adding features via smaller realease.
@fnagel commented on GitHub (Sep 7, 2025):
I would like to test upgrading my 60+ monitors instance to v2 beta4 but I'm running Kuma without Docker and the upgrade guide still says
Is this statement still valid?
@CommanderStorm commented on GitHub (Sep 8, 2025):
Yes, we only publish betas as docker images.
@masoncfrancis commented on GitHub (Sep 23, 2025):
@CommanderStorm Are there any current bugs that need to be worked out that would be helpful if the community chipped in? I saw some above but it looks like PRs have been merged
@CommanderStorm commented on GitHub (Sep 23, 2025):
As I said before, I don't consider any of the bugs that are remaining to be release-blockers.
If I had the power of the release, we would be on v2.3/...
There are some, but we will always have bugs. Given the test coverage, amount of paid maintainers, … this is unavoidable.
Here are a few pointers which are caused by v2:
Some of these are actual bugs, some need work trying to reproduce them.
If you want to help out, testing/reviewing Open PRs would also be high impact.
@hacs64 commented on GitHub (Oct 9, 2025):
Where I can find API documentation for v2?
@CommanderStorm commented on GitHub (Oct 9, 2025):
We don't have an officially documented API
@louislam commented on GitHub (Oct 10, 2025):
3 issues to go. I try my best to fix them this month and also release 2.0.0 this month.
2.0.0 Milestone:
https://github.com/louislam/uptime-kuma/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A2.0.0
@CommanderStorm I hope the
masterbranch should be freezed for now, until 2.0.0 will have been released. Feel free to merge new reviewed pull requests into the2.1.Xbranch.@manuelkamp commented on GitHub (Oct 13, 2025):
nice, hopefully there will be an upgrade path for non-docker installations too. I am stuck with the december 2024 version on my bare metal setup (no dockers in my environment per choice).
@younsl commented on GitHub (Oct 15, 2025):
First, thank you for releasing such a great open source project. Could you please consider including the feature to add Monitor descriptions on the status page(https://github.com/louislam/uptime-kuma/pull/4612, https://github.com/louislam/uptime-kuma/issues/6124) in uptime-kuma 2.x? Currently, I'm operating with a custom-built image of 2.0.0-beta3, but it's difficult to deploy with custom builds like this every time.
@CommanderStorm commented on GitHub (Oct 16, 2025):
@younsl feel free to do a PR to implement this properly.
I stated how I feel this feature should work. I won't merge undercooked work because this means we would be stuck with this decision.
Also no feature work in v2.0 due to the featur freeze
@louislam commented on GitHub (Oct 20, 2025):
Ah......... I think I chose a wrong time to release 2.0.0.
@Ionys320 commented on GitHub (Oct 20, 2025):
Oh shit. Maybe related to the AWS outage? Wasn't expecting that..
@younsl commented on GitHub (Oct 20, 2025):
Yes. Docker Hub error maybe caused by AWS outage in us-east-1. Additionally, quay.io and public.ecr.aws were also affected by this outage.
Current status for dockerhub:
@lenny87 commented on GitHub (Oct 20, 2025):
Hi,
can you please upload also dist tarball to 2.0.0 release? It's actually missing
@louislam commented on GitHub (Oct 20, 2025):
Have to wait too, because it is uploaded by a Docker container too.
@rwjack commented on GitHub (Oct 20, 2025):
Unfortunately Debian is riddled with unfixable CVEs...
The only one (that's conveniently critical) npm
form-data, needs to be bumped to4.0.4: https://github.com/advisories/GHSA-fjxv-7rqg-78g4@louislam commented on GitHub (Oct 20, 2025):
Which tool are you using? GitHub's Dependabot alerts had told me this 3 months ago, and it should be fixed already 3 months ago.
@rwjack commented on GitHub (Oct 20, 2025):
A very expensive and corporate one :)
Yes, very interesting:
github.com/louislam/uptime-kuma@5aca422f5d/package.json (L95)According to the above, the latest build should have included 4.0.4.
Can we somehow check what version of the package was used in the build? I cannot deduct much from the image itself (2.0.1)
Edit:
Now I'll stop giving ultimate praise to the security tool and show myself out.
@louislam commented on GitHub (Oct 20, 2025):
The expensive tool probably don't understand what is
~4.0.0.Anyway, thanks everyone for supporting this project, even though releasing 2.X was not so smooth today due to several issues. Going to sleep now. Have a good day.
@rwjack commented on GitHub (Oct 20, 2025):
Doesn't always have to be smooth, but you finally did it. Thanks for the update!
FYI for everyone else: the upgrade path that worked for me:
v1 latest > 2.0.1 (wait for the migration) > 2.0.1-slim-rootless > works like a charm
@fnagel commented on GitHub (Oct 21, 2025):
Are there any objections against upgrading to v2 with a non Docker setup? Did anyone already tried it?
@CommanderStorm commented on GitHub (Oct 21, 2025):
None reported
@manuelkamp commented on GitHub (Oct 21, 2025):
did it today (to 2.0.1 from 1.23.16) on bare metal, worked fine. migration took some time, but also without any errors.
@lenny87 commented on GitHub (Oct 21, 2025):
It works, I did it yesterday. Just simple nodejs 22 LTS on debian with pm2, used classic upgrade path from wiki
https://github.com/louislam/uptime-kuma/wiki/🆙-How-to-Update#--non-docker
Without any problem
@Tragen commented on GitHub (Oct 21, 2025):
Worked but with some
git remote prune origin
npm fund
and many
npm audit fix --force
The database upgrade took about 3 hours.
@fnagel commented on GitHub (Oct 22, 2025):
Thanks for the feedback everyone! Did the non Docker update myself last night, worked without issues. DB update took ~1.5h for 63 monitors.