mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
Terraform Provider #123
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#123
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 @pete-leese on GitHub (Aug 11, 2021).
Hello,
Not really a feature request per-say, but I intend on building a terraform provider for those who wish to manage uptime kuma using terraform (IaC) which some may know is a popular tool when it comes to automation in the cloud / DevOps space.
This is of course dependant on an API is available - #118 and I hope that the terraform provider will closely follow any new feature added to the uptime kuma API.
I just wanted to let it be known my intentions and also to get an idea on if this will be of interest to others so I can priorise accordingly, please feel free to discuss / give a thumbs up if of interest to you !
Many thanks for a great product!
@mikenabhan commented on GitHub (Aug 22, 2021):
Hi Pete, this is something that I would be very interested in seeing.
@ondrejsika commented on GitHub (Dec 29, 2021):
I’ve created many Terraform providers, so I can help with it.
@pete-leese commented on GitHub (Dec 29, 2021):
Sounds great. Don’t think API support has been added yet until sometime in the 2.x.x lifecycle. Ready to rock when that does happen though.
@Spritekin commented on GitHub (Oct 14, 2022):
Any news on this one? It would be fantastic to be able to install services in kubernetes and register them in uptime kuma for monitoring.
@anthosz commented on GitHub (Oct 14, 2022):
Without API available, it's tricky :)
@Dragonatorul commented on GitHub (Apr 7, 2023):
There appears to be an unofficial API now as per https://github.com/louislam/uptime-kuma/issues/118#issuecomment-1205502024 and https://github.com/louislam/uptime-kuma/issues/118#issuecomment-1351710068
The relevant repos are:
While these are not official APIs in the app itself, it doesn't seem likely that an official API will become available any time soon. A lot of people would love to use CI/CD friendly tools like terraform to maintain and control uptime-kuma. Until an official API becomes available, if ever, I believe these wrappers should be used instead.
@pete-leese and @ondrejsika What do you think?
@vanhoutenbos commented on GitHub (Jul 20, 2023):
@ondrejsika maybe we can make one with the un-official API as metnioned above: https://github.com/MedAziz11/Uptime-Kuma-Web-API
Potentially we need a little confirmation for @MedAziz11 that he wants to keep it up to that if kuma revisits his structures or introduces breaking changes
@ondrejsika commented on GitHub (Aug 7, 2023):
I'll try to create a PoC with that
@MedAziz11 commented on GitHub (Aug 10, 2023):
Indeed, I am amenable to accommodating changes and fostering the project's ongoing development. However, I must express that I cannot commit to a high level of active engagement at this juncture due to my current constraints on available time. @vanhoutenbos
@sachasmart commented on GitHub (Dec 23, 2023):
Happy to help with this!
@johntdyer commented on GitHub (Apr 26, 2024):
I'm game to help as well, I've made a provider before as well
@CommanderStorm commented on GitHub (Apr 26, 2024):
See #3854 for the PR that the official REST API (which people above have said is a requirement for this instead of the semi-official python wrapper for the socket.io API)
We are currently working on #4500 which is a requirement befor this can happen. (If people want to get there quicker, please see this issue)
Maybe this can help: https://github.com/BigBoot/AutoKuma
@AurimasNav commented on GitHub (Aug 21, 2024):
First thing when evaluating should I start using uptime Kuma was finding out if it has tf provider. Very interested in this.
@jacksonporter commented on GitHub (Oct 30, 2024):
Any updates on this? I am possibly available to help with this as well, written go before (what is recommended for TF providers). Love uptime kuma!
@pete-leese commented on GitHub (Nov 12, 2024):
I believe we are getting closer to an official API - I think this is penned 2.1.0 following the 2.0.0 beta release recently.
I have started to do some early work with a Terraform Provider based upon the following until official API lands: - https://github.com/MedAziz11/Uptime-Kuma-Web-API
@TheodoreHerzfeld commented on GitHub (Nov 14, 2024):
Hello all! I'd love to lend a hand on developing the provider as a long-time user. Is the re a repo setup that I can contribute to?
@TheodoreHerzfeld commented on GitHub (Nov 15, 2024):
i've created one here with some working code: https://github.com/TheodoreHerzfeld/kuma-provider
lots of work to do, but it's a start. It's based on the API mentioned above, but it should be reasonably easy to port it to the official one when it comes out)
@TheodoreHerzfeld commented on GitHub (Nov 17, 2024):
ok - i've got a few data sources working. Should be a good place to start at least. I'll keep plugging away at this when I have time
@pete-leese commented on GitHub (Nov 18, 2024):
I am taking a different approach with this and using speakeasy to generate the provider based on the openAPI spec available from Uptime-Kuma-Web-API.
This should do a lot of the leg work and also uses the terraform provider plugin framework.
@pete-leese commented on GitHub (Nov 18, 2024):
I've made some progress on using easyspeak to generate a provider based on the aforementioned API
https://github.com/pete-leese/terraform-provider-uptime-kuma-wapi
Now I am getting a little more familiar with the concepts, hopefully will be able to addmore functionality
@TheodoreHerzfeld commented on GitHub (Nov 19, 2024):
did some experimentation with speakeasy and i think I'm going to go a different direction - it's being quite wonky and buggy, and the documentation is less than stellar. HC provides some code-generation tools that will do most of that work for us: https://developer.hashicorp.com/terraform/plugin/code-generation
@pete-leese Thoughts on joining forces on this?
@meyerbro commented on GitHub (Jan 15, 2025):
Any news on this?
@ankek commented on GitHub (May 14, 2025):
Me waiting too
@ibrohimislam commented on GitHub (May 21, 2025):
you can check https://registry.terraform.io/providers/ehealth-co-id/uptimekuma/latest
@ainsleyclark commented on GitHub (Nov 19, 2025):
It would be great for an official terraform provider, a considerable amount of them are incomplete.
@ibrohimislam commented on GitHub (Dec 7, 2025):
Updated the Terraform provider (https://registry.terraform.io/providers/ehealth-co-id/uptimekuma/latest) for full Uptime Kuma v2 compatibility. It now works directly with Uptime Kuma - no need for the Uptime-Kuma-Web-Api wrapper. Also includes multiple bug fixes.
@ankek commented on GitHub (Dec 9, 2025):
Many thanks @ibrohimislam. Works pretty well. I`ve not faced any issues with 20+ monitors except monitor type "groups". Not supported at the moment. Not a blocker at all, I hope to see such option in future.
@Hazy87 commented on GitHub (Dec 9, 2025):
Thanks for the work on this, when im making monitors they are being created in a disabled state. If I hit resume on them they work fine.
Uptime Version: 2.0.2
provider : 1.0.3
resource "uptimekuma_monitor" "http_example" { name = "TF-test" type = "http" url = "https://example.com" method = "GET" interval = 60 retry_interval = 30 max_retries = 3 upside_down = false ignore_tls = false notification_id_list = [1] accepted_status_codes = [200, 201] }@ibrohimislam commented on GitHub (Dec 9, 2025):
@Hazy87 Thanks for flagging this. For any issues with the Terraform provider, please open them directly on the repo.
The fix is now included in v1.0.4, feel free to give it a try.
@breml commented on GitHub (Dec 9, 2025):
Hi!
I am the author of https://github.com/breml/go-uptime-kuma-client, the package, which powers the direct socket.io communication in https://github.com/ehealth-co-id/terraform-provider-uptimekuma. I made this package public some days ago, as a preparation step for my own implementation of a Terraform provider for Uptime Kuma. @ibrohimislam has been really quick (or lucky) in finding my new package this soon, so I am now kind of "late to the party with my own Terraform implementation in https://github.com/breml/terraform-provider-uptimekuma.
Given the situation, I decided to make my own code public now as well, even if I originally have planned to do a bit more polishing before releasing. I have not yet added this provider to the official registry, since I would like to first figure out, which of the two providers fits the need of the community more.
Since both of them rely on the same client package, there are obviously quite some similarities. The main differences I see are:
uptimekuma_monitor) versus very specific resources in breml (uptimekuma_monitor_httporuptimekuma_monitor_group). Me personally, I like the very specific approach better, since it allows for better documentation and validation of the parameters.ehealth-co-idcurrently supportsuptimekuma_monitor,uptimekuma_status_pageanduptimekuma_tag. My implementation has additional support foruptimekuma_notification,uptimekuma_proxy,uptimekuma_dockerhost,uptimekuma_maintenance, etc.). Obviously, all of this can be added toehealth-co-idas well, since the underlying client is the same.I hope to get some feedback from the community on which approach is liked more and how best to move forward.
@ibrohimislam I would like to hear your thoughts in particular.
@marcispauls commented on GitHub (Dec 9, 2025):
my fifty cents to both of you.. maybe @louislam can create repo under this organization and share access to both contributors. shift there go-uptime-kuma-client and aso provider?
@simonostendorf commented on GitHub (Dec 9, 2025):
I think this would be the best idea.
Massive thanks to both of you!
I like the approaches of the breml/terraform-provider-uptimekuma more because of the aspects you just mentioned (fine granular resources, more resources to manage)
@ibrohimislam commented on GitHub (Dec 9, 2025):
Thanks for sharing the background. and first of all, sorry if my early use of your client library ended up taking some of the spotlight. I found the package, it worked well for my use case, and I moved fast without realizing you were preparing your own provider release.
After looking through your implementation, it’s clear you’ve put a lot of thought into the resource design and coverage. Given that both providers rely on your client package and yours already takes a more complete, structured approach, I’m leaning toward archiving my repository and pointing users toward your provider instead.
Appreciate the work you’ve done on the client and the Terraform provider. Happy to collaborate or support in whatever direction makes the most sense for the community.
@marcispauls commented on GitHub (Dec 10, 2025):
i would also say that probably @breml approach seems a bit more progressed :) but then can we get at least beta version published in terraform repository? also as i said probably it makes sense to move it under https://github.com/louislam/
@louislam commented on GitHub (Dec 10, 2025):
I personally don't know what is Terraform, I probably will not maintain it, so no need to move it under my name.
Feel free to add your repo link to our wiki:
https://github.com/louislam/uptime-kuma/wiki/3rd-Party-Addons-Apps
If it is about deployment, should be added here.
https://github.com/louislam/uptime-kuma/wiki/%F0%9F%94%A7-How-to-Install#unofficial
@breml commented on GitHub (Dec 10, 2025):
Thanks for all the replies so far.
Based on the statement by @louislam, I understand that putting the Terraform provider under github.com/louisIam is off the table.
Therefore I will move ahead with publishing my implementation in the Terraform registry (hopefully I can do it this weekend). We can then collect more feedback and experience.
@ibrohimislam thanks also for your reply. There was no way for you to anticipate, that I work on a Terraform provider as well. So no problem there. I would happily colaborate with you on the future development of the Terraform provider.
There is in particular one feature that I might borrow from your code and this is the connection pool. The way I currently "work a round" the login rate limiting in the acceptance tests is by far not ideal.
@breml commented on GitHub (Dec 11, 2025):
I just released v0.1.0 in the Terraform registry: https://registry.terraform.io/providers/breml/uptimekuma/latest
@marcispauls commented on GitHub (Jan 8, 2026):
amazing job @breml i also think we can close this thread ;)