Dokploy
Back ups for Dokploy
What problem will this feature address?
Currently, there is no possibility of backing up and restoring the Dokploy instance. In other words, consider a scenario where a user has a setup with 10+ apps running on a server. If something goes wrong with the machine, the user must set up Dokploy from scratch, recovering and re-configuring all the apps. This might be a lot of work or even not feasible for larger-scale products.
Describe the solution you'd like
It would be nice to have the possibility to backup Dokploy and an option to "Set up the machine from a backup" when the instance is initialized. I.e., so that if a user installs Dokploy, it gives you the option:
- Set up a new Dokploy instance
- Recover from a backup.
Additionally, it might help users who may want to switch from Dokploy to Dokploy Cloud to "import" their whole set up instead of recreating it from scratch.
Describe alternatives you've considered
The only viable alternative seems to be regular backups of the whole machine (one could, of course, only back up Dokploy's configuration, but since the internal configuration and directories in question are subject to change, simply copying some directories or the Dokploy database associated with a current version of Dokploy would not be a reliable strategy).
Another alternative "workaround" that I considered is using Dokploy Cloud, as I suppose that it should perform backups anyway. However, from what I understood, Dokploy Cloud does not allow you to "import" the existing Dokploy setup (and manually re-creating a complex setup is very costly and error-prone).
Additional context
Related to (a more elaborate version of?) https://github.com/Dokploy/dokploy/issues/668
Recently, I faced the exact situation
I had to recreate each service and export and import database data manually, since there is no zip/ftp backup options, but only S3
@daniel-abramov @kerimovok This is not entirely accurate. Dokploy itself is a collection of Docker services (Dokploy, PostgreSQL, Redis, and Traefik) running within a Docker Swarm. I encountered this issue and replicated it, confirming that once the Dokploy service is destroyed, it needs to be recreated. However, if you’re leveraging Docker Swarm’s features effectively, your downtime and restoration time can be significantly minimized.
For example, in my setup with 3 managers and 2 workers, here’s how I ensure resilience:
-
Manager Quorum: Ensure that at least 2 out of the 3 managers remain operational. As long as quorum is maintained, the swarm will remain active even if one manager fails.
-
Service Replicas: Configure your applications deployed via Dokploy to have replicas distributed across multiple swarm nodes for high availability.
-
Worker Promotion: If more than one manager goes down, promote one of the workers to a manager to restore quorum and maintain swarm functionality.
With these measures in place, your deployed services should remain operational even in the event of node failures. Dokploy itself should also continue running, but even if its service is removed, the applications it deployed within the swarm will remain unaffected.
That said, having a feature to quickly restore the Dokploy UI along with its deployed services in the swarm would certainly be a valuable enhancement.
I'll join the discussion, and I've already added my vote.
I currently using the "Virtualmin" stack, due to the fact that configurations, files and databases can be backed up, but also managed properly.
But I'm searching for a modern interface, where it's more container-based. I do see that Coolify doesn't handle backups that well, either. At least not to a point, where I'm able to backup both the 1) configuration, 2) "project configuration" and 3) "project data", without having to use Duplicati for something, Restic for something else, and maybe even a third service to a few extra bits to be backed up. I normally use cloud providers where backup are offered, too. However, as one of the customers within the burned OVH datacenter, I'll personally always prioritize a great interface with build in remote-backup options, once I migrate to a new product, like Dokploy or the alternatives.
Dokploy looks great, and cool, like Coolify, but it doesn't look like they have added a proper method to manage and do this either, even though the suggestion has been raised a few year ago. There's also a fresh one.
I wish to see Dokploy adding this in the future ⭐ !
Adding my vote.
My org is currently toying with Dokploy, and being able to restore the entire Dokploy instance is a must:
- Dokploy users and their data
- Dokploy own settings
- Projects and their data (config, env)
At the same time, we need ways to restore a specific project to a given version. For static / data-free services it's "easy", but when there is data or volumes, things get tougher.
I'm a big fan of "file based" configurations, I think that Render's blueprint approach has a lot of value ("config as code"), and Dokploy could benefit from something similar (instance + project config).
For now, our approach has been to copy and save all the folders used by Dokploy, but this is becoming more and more tedious, plus we can't be sure that this approach will work after a Dokploy update.
I feel like hacking a backup solution on our own is not the solution, so I may start digging into Dokploy's codebase and see how we could do this more elegantly.
In term of UX, I feel like a "backup" and "restore" buttons + a backup list for a given service are easy wins. A naive approach for this backup could consist of a zip file containing:
- A json file with the service configuration, which could be created via Dokploy own API and must contain all the necessary info to recreate the service
- several zip files, one for each volume
A naive restore approach for a service could be:
- If the service is running, create a restore archive for rollback purpose ;
- If the service is running, stop it via Dokloy's API. If not, create the service via the same API ;
- Update the service using the content of our config file ;
- Delete the volumes, recreate them using the content of our archive and rebind them correctly.
Users could also decide to restore a service partially, in which case only the config would be applied, but the data would not be saved/restored.
For the whole Dokploy instance, I need a bit more time thinking how to split things. But a naive approach could be to save Dokploy settings and DB in a similar way + backup all the running services, creating a "mega" backup to restore a destroyed server quickly.
Alternatively, a user could decide to backup only Dokploy's settings (users, etc.) or Dokploy's settings + services settings, but without their data.
Indeed, perhaps
/etc/dokploy/applications /etc/dokploy/compose /etc/dokploy/traefik
the rest seems to be logs and monitoring stuff
In the next version you will be able to create backups for the main instance of dokploy and also be able to save the whole filesystem that is handled in /etc/dokploy, as well as a function to be able to restore both things, volume information will not be handled, it would complicate it at this point, in any case that could go into another feature, I know it will be very useful for you.
I hope you like it
Nice! BTW I added a template for Backrest which is a really nice self-hosted backup solution, could be interesting to integrate both (eg show how to mount the docker volumes root in Backrest so people can do backups on S3)
In the next version you will be able to create backups for the main instance of dokploy and also be able to save the whole filesystem that is handled in /etc/dokploy, as well as a function to be able to restore both things, volume information will not be handled, it would complicate it at this point, in any case that could go into another feature, I know it will be very useful for you.
I hope you like it
Will this also backup docker volumes?
In the next version you will be able to create backups for the main instance of dokploy and also be able to save the whole filesystem that is handled in /etc/dokploy, as well as a function to be able to restore both things, volume information will not be handled, it would complicate it at this point, in any case that could go into another feature, I know it will be very useful for you.
I hope you like it
What about the encryption please?
