How to Update Dokploy Safely, Pin a Version, and Move a Dokploy Instance to a New Server

Two operations worry Dokploy users more than the daily work: updating the platform and moving it to a different server. Both are simpler than they sound. The update is one command that replaces the Dokploy container while your applications keep serving; the migration is a scheduled backup of the instance to S3 and a restore on the new server. This guide gives the exact steps from the Dokploy docs (31 October 2026) and the operational habits that make both routine.

Before any update: three checks

1. Read the release notes on the GitHub releases page. Dokploy is 0.x software and minor releases can change behaviour; v0.29.9 dropped Redis from self-hosted installs, v0.30.0 added network management, DNS providers and per-server build queues.
2. Take an instance backup (Web Server, Backups, Create Backup) to an S3 destination. It captures the Dokploy database and /etc/dokploy, which is everything the dashboard knows.
3. Check disk and memory (df -h, free -h); the update pulls a new image and restarts a service.

Update to the latest release

curl -sSL https://dokploy.com/install.sh | sh -s update

The script pulls the current dokploy/dokploy image and updates the Swarm service. The dashboard is unavailable for the seconds the container restarts; your applications, databases and Traefik are not touched and keep serving. Log in again afterwards and check the version in the footer of the dashboard.

Pin a specific version, or roll back

Cautious teams update to a known release rather than "latest". Use the install.sh attached to that release on GitHub:

curl -sL https://github.com/Dokploy/dokploy/releases/download/v0.30.2/install.sh | sh -s update

The same command with an older tag is a rollback: the Dokploy database schema is migrated forward on update, so roll back only to the release you came from and restore the instance backup you took if the downgrade complains. Test updates on a staging Dokploy first if you run several servers; the Dokploy docs' own advice for self-hosting is that you decide when updates happen.

Update the server too

Dokploy runs on Docker and a Linux host, both of which need patches. Enable unattended security updates (unattended-upgrades on Ubuntu and Debian, as the Dokploy hardening guide recommends), and update Docker Engine through the distribution's packages during a maintenance window; a Docker restart stops every container for a few seconds, Dokploy included, and live-restore: true in /etc/docker/daemon.json keeps containers running through a daemon restart.

Move a Dokploy instance to a new server

The supported path is the instance backup and restore. On the old server:

1. Configure an S3 destination under Settings if you have not already.
2. Web Server, Backups, Create Backup to that destination. The archive contains a dump of dokploy-postgres and the /etc/dokploy directory (Traefik configuration, SSH keys, certificates).
3. Take database backups for every database service and volume backups for named volumes holding uploads; the instance backup covers Dokploy's configuration, not your applications' data.

On the new server (for example a MassiveGRID preset from the Dokploy hosting page, Ubuntu 24.04, same Dokploy version):

1. Install Dokploy with the install command, create the first account.
2. Add the same S3 destination.
3. Web Server, Backups, Restore Backup, pick the destination and the archive, review the summary and confirm. Dokploy replaces /etc/dokploy, drops and restores its database and disconnects current sessions; log in again (with the old server's credentials).
4. Under Web Server, Server, use Update IP so Dokploy knows its new address.
5. Redeploy each project so images are built and containers created on the new machine, then restore the database and volume backups into the new services.
6. Point DNS at the new IP. Traefik requests fresh certificates as traffic arrives; restart Traefik if routes look wrong.
7. Reconnect Git providers that referenced the old IP (ones using a domain need no change) and recreate any traefik.me domains, which encode the IP.

Run both servers in parallel until DNS has moved and the new one has served real traffic, then switch the old one off. Keep the backups.

Downtime, honestly

Updating Dokploy: dashboard offline for seconds, applications unaffected. Migrating: applications are offline for the DNS cutover only if you restore data and redeploy before changing DNS; a 300-second TTL set the day before keeps the window to minutes. Databases need a final dump taken after writes stop on the old server, which is the one moment of genuine downtime for stateful apps; schedule it.

Habits that make this boring

• A nightly instance backup on a cron schedule to S3, so a migration or a recovery starts from a fresh copy.
• Database and volume backups on schedules with retention, restore-tested quarterly.
• Version pinning with a monthly review of releases.
• Hosting that rarely forces a migration: the MassiveGRID servers behind the Dokploy presets fail over at the hypervisor level and store disks on Ceph with three replicas, so "the host died" stops being the reason you move, and the 24/7 team will install Dokploy on the new server for you if you ever do.

Frequently Asked Questions

Does updating Dokploy restart my applications?

No. The update replaces the Dokploy dashboard container only; applications, databases and Traefik keep running. The dashboard is unavailable for the seconds the new container takes to start. Updating Docker Engine or the host kernel does restart containers, so do that in a maintenance window with live-restore enabled.

How do I roll back a Dokploy update?

Run the install.sh from the previous release on GitHub with the update argument, for example curl -sL https://github.com/Dokploy/dokploy/releases/download/vX.Y.Z/install.sh | sh -s update. Because the database schema migrates forward on update, roll back only one release and keep the instance backup taken before the update in case the downgrade fails.

Does the Dokploy instance backup include my databases and uploaded files?

No. It contains Dokploy’s own PostgreSQL database and the /etc/dokploy directory, which is the platform configuration. Your applications’ databases are covered by database backups on each service, and uploaded files by volume backups of named volumes. Take all three before a migration.