Define services form file.

deekerman commented

2026-02-28 01:36:59 -05:00

Owner

Originally created by @jtagcat on GitHub (Aug 25, 2021).

Allow to define monitoring from a file, likely yaml. Ideally, multiple files.
This makes it compatible with CI / infra from file.

Files could be represented as (read-only, no-login) users (#128).

As a 3rd party, it could be implemented via the API (#118) by requesting current state, and adding/modifying/removing services, reaching the defined state.

GitHub Etiquette

Please use the 👍 reaction to show that you are affected by the same issue.
Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
Subscribe to receive notifications on status change and new comments.

Originally created by @jtagcat on GitHub (Aug 25, 2021). Allow to define monitoring from a file, likely yaml. Ideally, multiple files. This makes it compatible with CI / infra from file. Files could be represented as (read-only, no-login) users (#128). As a 3rd party, it could be implemented via the API (#118) by requesting current state, and adding/modifying/removing services, reaching the defined state. ### GitHub Etiquette * Please use the 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to show that you are affected by the same issue. * Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue. * Subscribe to receive notifications on status change and new comments.

deekerman

2026-02-28 01:36:59 -05:00

closed this issue
added the
feature-request
label

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@nicolas-g commented on GitHub (Sep 4, 2021):

👍
supporting everything through configuration files instead of point and click on the UI is crucial in order to have automation and is also Git-friendly so you can have it in version control.

@nicolas-g commented on GitHub (Sep 4, 2021): 👍 supporting everything through configuration files instead of point and click on the UI is crucial in order to have automation and is also Git-friendly so you can have it in version control.

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@gaby commented on GitHub (Sep 4, 2021):

I would love this feature, we currently have over 300 services to monitor :-)

@gaby commented on GitHub (Sep 4, 2021): I would love this feature, we currently have over 300 services to monitor :-)

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@louislam commented on GitHub (Oct 10, 2021):

Although it got a lot of thumbs up, it againsts my project styles.

https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#project-styles

If you love to config via yaml, I would suggest Gatus https://github.com/TwiN/gatus

@louislam commented on GitHub (Oct 10, 2021): Although it got a lot of thumbs up, it againsts my project styles. https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#project-styles If you love to config via yaml, I would suggest Gatus https://github.com/TwiN/gatus

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@jtagcat commented on GitHub (Oct 15, 2021):

The config file doesn't have to be the primary, or only way of configuration.

It would provide an alternative to the Web UI config, being not mandatory

@jtagcat commented on GitHub (Oct 15, 2021): The config file doesn't have to be the primary, or only way of configuration. It would provide an alternative to the Web UI config, being not mandatory

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@Xplouder commented on GitHub (Dec 28, 2022):

@louislam Please reconsider this feature request, as said earlier this is not a replacement but another way to configure the monitors, alerts, etc. This would allow a declarative way to automate what already exists, so its a complement.

@Xplouder commented on GitHub (Dec 28, 2022): @louislam Please reconsider this feature request, as said earlier this is not a replacement but another way to configure the monitors, alerts, etc. This would allow a declarative way to automate what already exists, so its a complement.

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@nicolas-g commented on GitHub (Dec 28, 2022):

So disappointed to see this issue closed.. this is a great product but not being able to automate or have the config in version control will be impossible to scale so this is a no go for me now.

@nicolas-g commented on GitHub (Dec 28, 2022): So disappointed to see this issue closed.. this is a great product but not being able to automate or have the config in version control will be impossible to scale so this is a no go for me now.

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@pauldevlin-smarsh commented on GitHub (Mar 21, 2023):

Uptime-kuma is amazing, it's a shame it doesn't have the ability to pre-configure the endpoints on start-up. I'm awful with Javascript but it looks as though it could be achieved by updating the server.js after setup to simply check for a backup json file (maybe in the data/uploads folder) then use the functionality already provided by Importing a Backup in the Settings.

It would probably look like this -

After setup is successful possibly at the end of this call socket.on("setup", async (username, password, callback)
Then check for backup.json in ../data/upload
If exists run socket.on("uploadBackup", async (uploadedJSON, importHandle, callback)

Maybe something like this:

// check for json file at ../data/upload/*.json

let jsonFile = path.join(__dirname, "../data/upload/*.json");

//  if file exists then run socket.on("uploadBackup", async (uploadedJSON, importHandle, callback) on line 1247

if (glob.sync(jsonFile).length > 0) {
    let uploadedJSON = JSON.parse(fs.readFileSync(jsonFile[0], "utf8"));
    let importHandle = "overwrite";
    socket.emit("uploadBackup", uploadedJSON, importHandle, callback);
}

Again, I'm terrible at JS so do point out if I'm being ridiculous.

@pauldevlin-smarsh commented on GitHub (Mar 21, 2023): Uptime-kuma is amazing, it's a shame it doesn't have the ability to pre-configure the endpoints on start-up. I'm awful with Javascript but it looks as though it could be achieved by updating the server.js after setup to simply check for a backup json file (maybe in the data/uploads folder) then use the functionality already provided by Importing a Backup in the Settings. It would probably look like this - - After setup is successful possibly at the end of this call socket.on("setup", async (username, password, callback) - Then check for backup.json in ../data/upload - If exists run socket.on("uploadBackup", async (uploadedJSON, importHandle, callback) Maybe something like this: ``` // check for json file at ../data/upload/*.json let jsonFile = path.join(__dirname, "../data/upload/*.json"); // if file exists then run socket.on("uploadBackup", async (uploadedJSON, importHandle, callback) on line 1247 if (glob.sync(jsonFile).length > 0) { let uploadedJSON = JSON.parse(fs.readFileSync(jsonFile[0], "utf8")); let importHandle = "overwrite"; socket.emit("uploadBackup", uploadedJSON, importHandle, callback); } ``` Again, I'm terrible at JS so do point out if I'm being ridiculous.

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@pauldevlin-smarsh commented on GitHub (Mar 22, 2023):

Just an update on this. You could get around this (sort of) by spinning up a container locally, adding all healthchecks. Once happy with all healthchecks you can then run a docker cp uptime-kuma:/app/data ./. You now have the data folder with your setup.

The next part is a bit fun (and could probably be done a better way) When you are spinning up a new instance/container of uptime-kuma you can run a docker cp data uptime-kuma:/app after you have brought it up. This will overwrite the data file with what you have already configured. restart the service and visit the /login page. Login with the credentials you had set before backup and you should see all your services ready as they were.

@pauldevlin-smarsh commented on GitHub (Mar 22, 2023): Just an update on this. You could get around this (sort of) by spinning up a container locally, adding all healthchecks. Once happy with all healthchecks you can then run a `docker cp uptime-kuma:/app/data ./`. You now have the data folder with your setup. The next part is a bit fun (and could probably be done a better way) When you are spinning up a new instance/container of uptime-kuma you can run a `docker cp data uptime-kuma:/app` after you have brought it up. This will overwrite the data file with what you have already configured. restart the service and visit the /login page. Login with the credentials you had set before backup and you should see all your services ready as they were.

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@LCerebo commented on GitHub (Jun 10, 2023):

It's a pity that this feature was abandoned. As @Xplouder said it will be a second way to define checks, this will enable the definition of checks as "configuration as code".
As a second bonus it could be very easy to backup and restore the configuration (not the history) using the same format (for example a yaml descriptor).
Personally I use ansible to deploy every service both at work and at home, and configuration as code is almost everywhere supported and welcome.
Reading your project styles guidelines I don't find this request contradicting any of them.
Hope that @louislam can reconsider to include the feature in a future release!

@LCerebo commented on GitHub (Jun 10, 2023): It's a pity that this feature was abandoned. As @Xplouder said it will be a second way to define checks, this will enable the definition of checks as "configuration as code". As a second bonus it could be very easy to backup and restore the configuration (not the history) using the same format (for example a yaml descriptor). Personally I use ansible to deploy every service both at work and at home, and configuration as code is almost everywhere supported and welcome. Reading your project styles guidelines I don't find this request contradicting any of them. Hope that @louislam can reconsider to include the feature in a future release!

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@vanhoutenbos commented on GitHub (Jun 30, 2023):

My teams love Uptime Kuma and have been using it for a long time!

At this moment we are growing exponentially with our services and would like to have a way to add a new service to a 'configuration file' and rollout the change to all our environments instead of pressing 'add monitor' on every kuma interface on every environment.
As @gaby mentions, when you have hundreds of monitors (and many environments) this is getting very maintain heavy.

I have seen a couple use cases where it could be nice to have the option to configure the monitors on deployment or atleast be able to 'control' the content of the data folder more easy.

I am open to build or help build a solution but I would like to see what would be a workable solution for the maintainer.

TL;DR; I would like to be able to configure monitors from code, how is irrelevant for me but for example through a JSON file or SQL query.

Please reconsider this feature as an optional option <3

@vanhoutenbos commented on GitHub (Jun 30, 2023): My teams love Uptime Kuma and have been using it for a long time! At this moment we are growing exponentially with our services and would like to have a way to add a new service to a 'configuration file' and rollout the change to all our environments instead of pressing 'add monitor' on every kuma interface on every environment. As @gaby mentions, when you have hundreds of monitors (and many environments) this is getting very maintain heavy. I have seen a couple use cases where it could be nice to have the option to configure the monitors on deployment or atleast be able to 'control' the content of the `data` folder more easy. I am open to build or help build a solution but I would like to see what would be a workable solution for the maintainer. TL;DR; I would like to be able to configure monitors from code, how is irrelevant for me but for example through a JSON file or SQL query. Please reconsider this feature as an optional option <3

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 30, 2023):

I would like to be able to configure monitors from code

Currently, we don't support an API, but you can look into the community-maintained https://uptime-kuma-api.readthedocs.io/en/latest/ or maybe https://github.com/MedAziz11/Uptime-Kuma-Web-API
See #118 for further details

@CommanderStorm commented on GitHub (Jun 30, 2023): > I would like to be able to configure monitors from code Currently, we don't support an API, but you can look into the community-maintained https://uptime-kuma-api.readthedocs.io/en/latest/ or maybe https://github.com/MedAziz11/Uptime-Kuma-Web-API See #118 for further details

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@tylerlittlefield commented on GitHub (Sep 6, 2023):

Such a shame. Has anyone made a fork that allows configuration files?

@tylerlittlefield commented on GitHub (Sep 6, 2023): Such a shame. Has anyone made a fork that allows configuration files?

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@dorkamotorka commented on GitHub (Sep 20, 2023):

+1

@dorkamotorka commented on GitHub (Sep 20, 2023): +1

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@vanhoutenbos commented on GitHub (Sep 28, 2023):

Such a shame. Has anyone made a fork that allows configuration files?

Since IAC was a hard-requirement from my client I moved to https://github.com/TwiN/gatus/
I love the kuma UI and its so easy on the eyes, but IAC was a must-have and UI was a nice to have

@vanhoutenbos commented on GitHub (Sep 28, 2023): > Such a shame. Has anyone made a fork that allows configuration files? Since IAC was a hard-requirement from my client I moved to https://github.com/TwiN/gatus/ I love the kuma UI and its so easy on the eyes, but IAC was a must-have and UI was a nice to have

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@terminator891 commented on GitHub (Mar 22, 2025):

Its just a shame that this feature was never impleneted I'm forced to move to other solution despite loving uptime-kuma gui

@terminator891 commented on GitHub (Mar 22, 2025): Its just a shame that this feature was never impleneted I'm forced to move to other solution despite loving uptime-kuma gui

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@Yatharth0045 commented on GitHub (Jan 16, 2026):

Can we reconsider this. As @Xplouder said, this is just an alternative and will not be the only approach to add monitors/status pages. Would love to have this feature in place. @louislam

@Yatharth0045 commented on GitHub (Jan 16, 2026): Can we reconsider this. As @Xplouder said, this is just an alternative and will not be the only approach to add monitors/status pages. Would love to have this feature in place. @louislam

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jan 16, 2026):

Can we reconsider this

Has something fundamentally changed?
I think this feature is kind of resonable, but would need a larger review slot, tests and someone who is willing to maintain this.
At the minimum, this would need a refactoring of the monitoring type interface and help moving all monitors to this new interface.

Currently, I don't see this slot even if implmemented.
I don't have the capacity to maintain this.
-> I won't reconsider when already so heavily under water. (this month there were 152 Active pull requests
144 Active issues
. And this includes the christmas/december low).

See these issues, if you want to help:

As said, there is a number of projects already focused on IAC, so if you need this I think choosing them is a better fit.

@CommanderStorm commented on GitHub (Jan 16, 2026): > Can we reconsider this Has something fundamentally changed? I think this feature is kind of resonable, but would need a larger review slot, tests and someone who is willing to maintain this. At the minimum, this would need a refactoring of the monitoring type interface and help moving all monitors to this new interface. Currently, I don't see this slot even if implmemented. I don't have the capacity to maintain this. -> I won't reconsider when already so heavily under water. (this month there were [152 Active pull requests 144 Active issues ](https://github.com/louislam/uptime-kuma/pulse). And this includes the christmas/december low). See these issues, if you want to help: - https://github.com/louislam/uptime-kuma/issues/6260 - https://github.com/louislam/uptime-kuma/issues/6673 As said, there is a number of projects already focused on IAC, so if you need this I think choosing them is a better fit.

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@merura commented on GitHub (Feb 23, 2026):

Its just a shame that this feature was never impleneted I'm forced to move to other solution despite loving uptime-kuma gui

@terminator891, which other solution are you using?

@merura commented on GitHub (Feb 23, 2026): > Its just a shame that this feature was never impleneted I'm forced to move to other solution despite loving uptime-kuma gui @terminator891, which other solution are you using?

deekerman commented

2026-02-28 01:37:07 -05:00

Author

Owner

@Yatharth0045 commented on GitHub (Feb 23, 2026):

@merura , you can try out Gatus

@Yatharth0045 commented on GitHub (Feb 23, 2026): @merura , you can try out [Gatus](https://github.com/TwiN/gatus)

Rows
Columns

Define services form file. #162

GitHub Etiquette