starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

[Help] Possible to auto import a backup on container startup? #530

New issue

Closed

opened 2026-02-28 01:49:36 -05:00 by deekerman · 5 comments

deekerman commented

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

Owner

Originally created by @troodes on GitHub (Nov 4, 2021).

⚠️ Please verify that this bug has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

📝 Describe your problem

Great tool, love the simplicity of it.

I'm wondering if there is a way to have the app restore the settings from a backed up .json file on docker startup?Perhaps by mounting the .json backup to a specific location and having the app restore it at startup?

My use case is I'd like to create a bunch of canned monitor .json configs to use, and then fire up the docker container pointing at one of them in order to avoid having to use the UI to manually create them all, or import the backup settings. My monitor hosts change dynamically, so it'd be useful to be able to generate the settings .json ahead of time and load it at startup.

Alternatively, is there a way to trigger the "Import Backup" remotely, instead of using the GUI?

Thanks!

🐻 Uptime-Kuma Version

1.10.0

💻 Operating System and Arch

RHEL

🌐 Browser

Google Chrome

🐋 Docker Version

🟩 NodeJS Version

Using Docker

Originally created by @troodes on GitHub (Nov 4, 2021). ### ⚠️ Please verify that this bug has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### 📝 Describe your problem Great tool, love the simplicity of it. I'm wondering if there is a way to have the app restore the settings from a backed up .json file on docker startup?Perhaps by mounting the .json backup to a specific location and having the app restore it at startup? My use case is I'd like to create a bunch of canned monitor .json configs to use, and then fire up the docker container pointing at one of them in order to avoid having to use the UI to manually create them all, or import the backup settings. My monitor hosts change dynamically, so it'd be useful to be able to generate the settings .json ahead of time and load it at startup. Alternatively, is there a way to trigger the "Import Backup" remotely, instead of using the GUI? Thanks! ### 🐻 Uptime-Kuma Version 1.10.0 ### 💻 Operating System and Arch RHEL ### 🌐 Browser Google Chrome ### 🐋 Docker Version 20 ### 🟩 NodeJS Version Using Docker

deekerman

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

closed this issue
added the
help
label

deekerman commented

2026-02-28 01:49:40 -05:00

Author

Owner

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

👍🏻 for this feature, it would be very useful for stateless deployments.

@gaby commented on GitHub (Nov 4, 2021): 👍🏻 for this feature, it would be very useful for stateless deployments.

deekerman commented

2026-02-28 01:49:42 -05:00

Author

Owner

@deefdragon commented on GitHub (Nov 5, 2021):

Likely a duplicate of #270

I really do think providing the option of loading in a config/backup on startup should at-least be re-considered. Based on the Project Styles, it sounds like Louis wants UK to be as easy as possible to use and deploy. I really don't think that adding the option to load a config/backup in via a file would mean any more difficult for users, while enabling some cool stuff like stateless deployments, or potentially making a custom startup script to generate the backup.

@deefdragon commented on GitHub (Nov 5, 2021): Likely a duplicate of #270 I really do think providing the option of loading in a config/backup on startup should at-least be re-considered. Based on the Project Styles, it sounds like Louis wants UK to be as easy as possible to use and deploy. I really don't think that adding the _option_ to load a config/backup in via a file would mean any more difficult for users, while enabling some cool stuff like stateless deployments, or potentially making a custom startup script to generate the backup.

deekerman commented

2026-02-28 01:49:42 -05:00

Author

Owner

@louislam commented on GitHub (Nov 5, 2021):

Supports both ways (config file + config from web ui) are super difficult in my opinion, it would increase the complexity of Uptime Kuma and hard to maintain in the future.

Also it is against my project style:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#project-styles

So it won't happen.

Alternative, you can:

After setup everything, you can build your container into own image by docker commit.
Just use other open source projects which is config file friendly such as gatus: https://github.com/TwiN/gatus

@louislam commented on GitHub (Nov 5, 2021): Supports both ways (config file + config from web ui) are super difficult in my opinion, it would increase the complexity of Uptime Kuma and hard to maintain in the future. Also it is against my project style: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#project-styles So it won't happen. Alternative, you can: 1. After setup everything, you can build your container into own image by `docker commit`. 1. Just use other open source projects which is config file friendly such as gatus: https://github.com/TwiN/gatus

deekerman commented

2026-02-28 01:49:42 -05:00

Author

Owner

@deefdragon commented on GitHub (Nov 5, 2021):

I seriously believe you are shooting the project in the foot, but very well. I shall not bring it up again.

@deefdragon commented on GitHub (Nov 5, 2021): I seriously believe you are shooting the project in the foot, but very well. I shall not bring it up again.

deekerman commented

2026-02-28 01:49:42 -05:00

Author

Owner

@troodes commented on GitHub (Nov 5, 2021):

Yup, definitely a dup of #270 , thanks for pointing that out.
@louislam , thanks for the reply and suggested alternatives.

@troodes commented on GitHub (Nov 5, 2021): Yup, definitely a dup of #270 , thanks for pointing that out. @louislam , thanks for the reply and suggested alternatives.