Migrating from Dokploy
A manual migration path from Dokploy, the data that transfers, and how to validate the result.
Status: manual migration
Notploy does not ship an automated Dokploy importer. Migration is a manual process performed on a Notploy installation you control. This page describes the supported approach, what transfers cleanly, what does not, and how to validate the result. There is no one-click "import Dokploy" button.
Notploy and Dokploy share a lineage: both orchestrate Docker containers and Traefik, and both use projects, applications, databases and Compose stacks. That makes a manual migration tractable. It does not make it automatic.
Before you start
- Inventory the source. List every Dokploy project and its services: applications (with source repository, build type and environment variables), databases (type, version, credentials, backups), and Compose stacks (compose file,
.env, volumes, domains). - Back up everything on the Dokploy side. Database dumps, volume data and the compose files. A migration you cannot roll back is not a migration.
- Back up on the Notploy side. If you are adopting an existing Notploy installation, take a database backup first. See Upgrade, backup and restore.
- Prepare destinations. Configure the Git providers, registries, SSH keys and S3 destinations you will need in Notploy.
What transfers, and how
| Dokploy concept | Notploy equivalent | How |
|---|---|---|
| Project | Project | Recreate; names and descriptions are informational. |
| Application | Application | Recreate the source, build type and variables. |
| Compose stack | Docker Compose | Re-create from the same docker-compose.yml. |
| Database | Database | Create a new instance and restore a dump. |
| Environment variables | Environment variables | Copy values; re-enter secrets. |
| Domain | Domain | Re-add and let Notploy issue a certificate. |
| Volume data | Volumes / Volume backups | Copy data or restore from backup. |
Re-enter secrets manually
Copying an encrypted configuration blob across platforms is neither reliable nor safe. Re-enter secrets explicitly on the Notploy side, or source them from a secrets provider.
What does not transfer
- Encrypted settings and secrets. They are platform-specific; re-enter them.
- Traefik configuration. Notploy regenerates routing rules from domains you configure.
- Docker images not in a registry. Rebuild or push them to a registry first.
- Version-specific behavior. A service that relied on a Dokploy-specific default may need adjustment.
Procedure
- Create the project and its environment(s) in Notploy.
- Recreate each application: add the source, pick the build type that matches the original, and set its variables.
- Recreate each Compose stack from its compose file; move repository-sourced files into mounts as needed.
- Create databases and restore their dumps into the new instances. See Restore.
- Copy volume data — via backup/restore where possible.
- Add domains and let certificates issue. Keep the old stack serving traffic until the new one is verified.
- Cut DNS over last, and keep the old installation available for rollback.
Post-migration validation
A project appearing in the UI proves nothing. Verify each item:
- Every application builds and its latest deployment reaches
running. - Each service responses correctly behind its domain over HTTPS.
- Environment variables are present and correct (no startup crashes).
- Databases contain the expected data (spot-check tables/collections).
- Compose stacks behave as before, including volumes and networks.
- Backups are scheduled and a test restore succeeds.
- Auto-deploy webhooks fire on a push.
Distinguish three things when you report status: what was imported (configuration re-entered), what was verified (builds and runs), and what is operational (serving traffic you depend on).
Rollback
Until the destination is validated, keep the source Dokploy installation running and do not decommission it or its data. If validation fails, point DNS back and continue on the source.