Backing up Komodo settings (possibly also DB change) #136

Closed
opened 2025-10-31 15:02:59 -05:00 by GiteaMirror · 7 comments
Owner

Originally created by @gitcatpeter on GitHub (Nov 23, 2024).

Is there any way to backup and export Komodo core settings? Like all server configs, stacks and so on...
How much is kept in TOML and how much can be dumped from a DB.
And then restore to a vanilla install?

Second part of that question is changing DB type e.g. postgres -> mongo. Is there a way to somehow convert DB dump or something?

I had unexplained postgres failure and even though it eventually recovered I lost some confidence in it (latest Komodo, latest postgres and ferret). Which is strange. because for years postgres has been rock-solid for me.

Originally created by @gitcatpeter on GitHub (Nov 23, 2024). Is there any way to backup and export Komodo core settings? Like all server configs, stacks and so on... How much is kept in TOML and how much can be dumped from a DB. And then restore to a vanilla install? Second part of that question is changing DB type e.g. postgres -> mongo. Is there a way to somehow convert DB dump or something? I had unexplained postgres failure and even though it eventually recovered I lost some confidence in it (latest Komodo, latest postgres and ferret). Which is strange. because for years postgres has been rock-solid for me.
GiteaMirror added the
info
label 2025-10-31 15:02:59 -05:00
Author
Owner

@mbecker20 commented on GitHub (Nov 23, 2024):

Yes, there is the Resource Sync to help with this. Lets say you want to set up Komodo again with a new database backend:

The high level steps will be:

  1. Export your configs to Resource Toml
  2. Take down Komodo
  3. Start fresh Komodo pointing to new db
  4. Create a Resource Sync, paste in the exported Resources Toml, and execute the sync.

Specifics:

To start, note that you cannot export either Users or Git / Docker Providers, lets deal with that first.

For Users, they will have to recreate their account and onboard again. You will lose any specific Permissions attached to Users if you delete the database data. The solution is to migrate all user specific permissions to User Groups which can be included in Resource Toml: https://komo.do/docs/sync-resources#user-group. Non-admin users just need to create their users again with the same username. Admin users can use any username / have no restrictions.

For the Git / Docker Providers, move them all to the core.config.toml: https://github.com/mbecker20/komodo/blob/main/config/core.config.toml#L397. Either this, or you must re-add them via the UI.

The settings for Komodo itself are in the config files (compose.yaml, compose.env, core.config.toml). Just copy these somewhere safe to backup if the server is being formatted.

For the Resources, everything is in the TOML files. Export them before taking down Komodo.

Assuming all your user permissions are moved to User Groups, and your Git / Docker Providers are in your core.config.toml, you can follow the below steps.

  1. From the Dashboard, click the Toml export button. Copy the contents.
  2. Paste the contents into a local file for safekeeping.
  3. Take down Komodo. Copy the compose files as they are as a backup.
  4. Start from the default compose files for your desired database: https://komo.do/docs/setup. Change the necessary things to align with your old config, but leave the database config alone (still fill in DB_USERNAME / DB_PASSWORD).
  5. Bring up Komodo using the provided command from https://komo.do/docs/setup.
  6. Navigate to komodo login in the browser, and sign up your admin user.
  7. Create a new Sync, choose UI Defined, and paste in your Resource Toml you copied before.
  8. Execute the Sync. Confirm all your Resources are back.

Let me know how it works out 🦎

@mbecker20 commented on GitHub (Nov 23, 2024): Yes, there is the Resource Sync to help with this. Lets say you want to set up Komodo again with a new database backend: The high level steps will be: 1. Export your configs to Resource Toml 2. Take down Komodo 3. Start fresh Komodo pointing to new db 4. Create a Resource Sync, paste in the exported Resources Toml, and execute the sync. Specifics: To start, note that you cannot export either Users or Git / Docker Providers, lets deal with that first. For Users, they will have to recreate their account and onboard again. You will lose any specific Permissions attached to Users if you delete the database data. The solution is to migrate all user specific permissions to User Groups which can be included in Resource Toml: https://komo.do/docs/sync-resources#user-group. Non-admin users just need to create their users again with the same username. Admin users can use any username / have no restrictions. For the Git / Docker Providers, move them all to the `core.config.toml`: https://github.com/mbecker20/komodo/blob/main/config/core.config.toml#L397. Either this, or you must re-add them via the UI. The settings for Komodo itself are in the config files (`compose.yaml`, `compose.env`, `core.config.toml`). Just copy these somewhere safe to backup if the server is being formatted. For the Resources, everything is in the TOML files. Export them before taking down Komodo. Assuming all your user permissions are moved to User Groups, and your Git / Docker Providers are in your `core.config.toml`, you can follow the below steps. 1. From the Dashboard, click the `Toml` export button. Copy the contents. 6. Paste the contents into a local file for safekeeping. 7. Take down Komodo. Copy the compose files as they are as a backup. 8. Start from the default compose files for your desired database: https://komo.do/docs/setup. Change the necessary things to align with your old config, but leave the database config alone (still fill in DB_USERNAME / DB_PASSWORD). 9. Bring up Komodo using the provided command from https://komo.do/docs/setup. 10. Navigate to komodo login in the browser, and sign up your admin user. 11. Create a new `Sync`, choose UI Defined, and paste in your Resource Toml you copied before. 12. Execute the Sync. Confirm all your Resources are back. Let me know how it works out 🦎
Author
Owner

@gitcatpeter commented on GitHub (Nov 24, 2024):

Thank you for that detailed instruction! I'm going to try it asap.

What is your experience or recommendation for a backend DB for Komodo.
We're talking about a homelab with ~200 docker stacks.

Have you seen any issues with ferret+postgres? That additional translation layer could potentially cause issues.
Is my decision to go back to MongoDB warranted?

@gitcatpeter commented on GitHub (Nov 24, 2024): Thank you for that detailed instruction! I'm going to try it asap. What is your experience or recommendation for a backend DB for Komodo. We're talking about a homelab with ~200 docker stacks. Have you seen any issues with ferret+postgres? That additional translation layer could potentially cause issues. Is my decision to go back to MongoDB warranted?
Author
Owner

@mbecker20 commented on GitHub (Nov 24, 2024):

Komodo uses the mongo driver internally, I've been using it for years and haven't had any problems with it. It has a nice GUI explorer with Compass: https://www.mongodb.com/products/tools/compass. While I don't think Postgres will have any issues insofar as the number of your resources, I don't see the advantage of PG if your host supports Mongo. I mainly added the Sqlite / Postgres options for compatibility with hosts that don't support Mongo.

I realize there is no need to take down your old Komodo, you can deploy the new Komodo using Mongo alongside the old one, and make sure the new one is working before taking the old one down.

@mbecker20 commented on GitHub (Nov 24, 2024): Komodo uses the mongo driver internally, I've been using it for years and haven't had any problems with it. It has a nice GUI explorer with Compass: https://www.mongodb.com/products/tools/compass. While I don't think Postgres will have any issues insofar as the number of your resources, I don't see the advantage of PG if your host supports Mongo. I mainly added the Sqlite / Postgres options for compatibility with hosts that don't support Mongo. I realize there is no need to take down your old Komodo, you can deploy the new Komodo using Mongo alongside the old one, and make sure the new one is working before taking the old one down.
Author
Owner

@R-Nabil commented on GitHub (Jul 11, 2025):

Hi,

FOllowing up on that question. Is there a way to do it in a simpler way (the export ressource part) ? As in : why not have a Sync that syncs from the changes made in the UI to a Git Repo defined (with the same approach of execute/commit) ?

That way, the UI stays the main interaction but we also keep ressources in sync in a GitRepo.

@R-Nabil commented on GitHub (Jul 11, 2025): Hi, FOllowing up on that question. Is there a way to do it in a simpler way (the export ressource part) ? As in : why not have a Sync that syncs from the changes made in the UI to a Git Repo defined (with the same approach of execute/commit) ? That way, the UI stays the main interaction but we also keep ressources in sync in a GitRepo.
Author
Owner

@mbecker20 commented on GitHub (Jul 14, 2025):

Hi,

FOllowing up on that question. Is there a way to do it in a simpler way (the export ressource part) ? As in : why not have a Sync that syncs from the changes made in the UI to a Git Repo defined (with the same approach of execute/commit) ?

That way, the UI stays the main interaction but we also keep ressources in sync in a GitRepo.

I have considered it through something like an auto commit flag on the Sync settings

@mbecker20 commented on GitHub (Jul 14, 2025): > Hi, > > FOllowing up on that question. Is there a way to do it in a simpler way (the export ressource part) ? As in : why not have a Sync that syncs from the changes made in the UI to a Git Repo defined (with the same approach of execute/commit) ? > > That way, the UI stays the main interaction but we also keep ressources in sync in a GitRepo. I have considered it through something like an auto commit flag on the Sync settings
Author
Owner

@R-Nabil commented on GitHub (Jul 14, 2025):

Im a big fan of IaC so from my point of view this would be a great feature :)
On 14 Jul 2025 at 14:12 +0800, Maxwell Becker @.***>, wrote:

mbecker20 left a comment (moghtech/komodo#199)

Hi,
FOllowing up on that question. Is there a way to do it in a simpler way (the export ressource part) ? As in : why not have a Sync that syncs from the changes made in the UI to a Git Repo defined (with the same approach of execute/commit) ?
That way, the UI stays the main interaction but we also keep ressources in sync in a GitRepo.
I have considered it through something like an auto commit flag on the Sync settings

Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

@R-Nabil commented on GitHub (Jul 14, 2025): Im a big fan of IaC so from my point of view this would be a great feature :) On 14 Jul 2025 at 14:12 +0800, Maxwell Becker ***@***.***>, wrote: > mbecker20 left a comment (moghtech/komodo#199) > > Hi, > > FOllowing up on that question. Is there a way to do it in a simpler way (the export ressource part) ? As in : why not have a Sync that syncs from the changes made in the UI to a Git Repo defined (with the same approach of execute/commit) ? > > That way, the UI stays the main interaction but we also keep ressources in sync in a GitRepo. > I have considered it through something like an auto commit flag on the Sync settings > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you commented.Message ID: ***@***.***>
Author
Owner

@mbecker20 commented on GitHub (Aug 26, 2025):

There is now the database backup feature: https://komo.do/docs/setup/backup

@mbecker20 commented on GitHub (Aug 26, 2025): There is now the database backup feature: https://komo.do/docs/setup/backup
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/komodo#136
No description provided.