Define services form file.

[jtagcat]

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.

[nicolas-g]

👍
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.

[gaby]

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

[louislam]

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

[jtagcat]

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

[Xplouder]

@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.

[nicolas-g]

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.

[pauldevlin-smarsh]

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]

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.

[LCerebo]

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!

[vanhoutenbos]

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

[CommanderStorm]

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

[tylerlittlefield]

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

[vanhoutenbos]

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