Import/Export/Backup Config Manager

[bradjtrammell]

Is your feature request related to a problem? Please describe.
I frequently encounter issues where NGINX Proxy Manager (NPM) becomes unusable due to custom configurations. It would be incredibly helpful if the Admin Panel included built-in functionality to back up, export, and import configurations or sync multiple NPM systems together for high availability. This would allow for seamless recovery by restoring settings to another instance without manual intervention.

Additionally, I’d love to see the Admin Panel operate independently—either as a separate service or running on a dedicated NGINX instance. Currently, if the Docker container fails or an error occurs, the Admin Panel becomes inaccessible, requiring users to manually exec into the container to reset configurations or rebuild the database. This recovery process is often difficult and, in my experience, not always successful. Decoupling the Admin Panel from the main NPM instance would greatly improve reliability and ease of recovery.

[arsen3d]

This would be useful for initial setup as well.
Another use case is having proxy manager synchronize with Kubernetes services.

[Ryland0]

Yes please!

[theotherguy2175]

I would also like this feature.

[AntoninoBonanno]

+1

[asanchezed]

+1

[gududege]

+1

[cug]

+1

[AC-0308]

+1

[theotherguy2175]

I might take a crack at developing something like this. At the minimum exporting the config should be easy. But injecting the new files and updating the DB might be more involved.

[theotherguy2175]

Acutally for everyone following, now that I think about it.

Is this really something that is needed? Considereing the functions of contaienrs and how everything is stored in /data and /letsencrypt there are already means with docker swarm and kubernetes to allow "syncing" between instances

Further more when it comes to git, or other means of backup, having an external backup method would seem simpler

[kankaristo]

@theotherguy2175, export/import would still be useful if you don't use something like Docker Swarm or Kubernetes that allows syncing (I use Docker Compose on my home server).

And it would also be useful for backups and "snapshots", in case you want to return to an earlier state a week ago, before you changed config and broke something. Yes, you can also backup the container volumes, but I would personally prefer a plaintext config/export file (just the config, I can regenerate the certificates/keys). You mention backing up with Git, but Git isn't really meant for binary files (like an SQLite database, which is what NPM uses).

[theotherguy2175]

My issue with that is, if you did want a snapshot feature where would you store these files? Somewhere else right? Or possibly via integration on NPM with services like Google Drive.

However, even in single instances doing backups on the file level would be just as simple. I understand why a GUI would be useful for this. But as I mentioned the nature of containers means following container best practices which includes data storage backup and recovery. This should be done externally with something as simple as a cron job to archive the files (which would solve your snapshot feature)

I guess I just don't honestly see the point of putting in the work to code it considering that container storage replication/backup is something that is already done and well documented.

And while there is some truth to that Git claim for NPM that is just not true. The DB isn't being updated all the time, I would guess only every few months. At max days. Meaning that sqlite is fine for using git for repo based backup too.

[kankaristo]

Following container best practices would ideally move all configuration into configuration files or environment variables, so that the configuration is easy to edit for different servers.

You can backup the SQLite database and other files, but they're not easily editable (without an SQLite editor or similar).

I have about 30 different (sub)domains on my home server, and I change the config almost weekly, not every few months (it's a home server, so I experiment with stuff).

Just last week, I changed my home network's IP subnet, and I had to manually edit all of the forwarding rules in NPM. If there had been an import/export feature, I could have exported the config (also as a backup), edited the exported config with search and replace, and imported the config back into NPM. Same thing if I would have wanted to replicate the same setup with minor changes on another server, now it's all manual through the GUI.

To me, the main point of the import/export feature would be to avoid using NPM's GUI as much as possible, because I could edit the config with a text editor. Technically, I could do the same by editing the SQLite database, but then it could easily get corrupted, and I'd have to recover from a backup (outside of NPM, because it doesn't have import/export functionality).

I'm not arguing that you would have to use import/export, if you're happy with backing up the container volumes directly. But there are definitely many use-cases for import/export.

If all of the config would be text files (like they are with Nginx itself), I would 100 % agree with you. In that case, I would just back up and version control those config files directly, no import/export necessary. But a Git diff on an SQLite database isn't very useful, so there it seems a bit pointless (I do have ZFS backups/snapshots of the volumes, just not Git).

[theotherguy2175]

I understand, I just don't see the value in coding this. You are making references from a server perspective which would be huge if this was not a docker container. Containers are better in this aspect and sometime require rethinking our workflows from traditional server(s) mean.

NPM Has an api that I have used to auto update my let's encrypt certs which you could do too with a script for updating all your ports.

I do get where you are coming from. But the more I think about it an export tool just makes more work. Also there is no way to have a single config as you say. Each proxy host has it's own config and then is reference by the DB. Hopefully someone will code this one day for you guys. I used to want this feature but I realized just today it's a little self defeating.