Docs
Migrate from another panel
Import one environment over the source panel's API where the importer speaks it, recreate the rest, cut DNS when green.
Import over the source's API
For a source panel the importer speaks (Dokploy today), nixploy import inspect / plan / apply reads one project environment through its REST API with a read-capable key, translates it to a version-2 nixploy.yaml plus the env values, and applies both. Nothing is deployed: services land idle with a list of notes for what did not carry over (git provider connections, basic-auth passwords, database passwords, compose mounts, custom certificates), and you deploy each one when the notes are handled.
1export NIXPLOY_IMPORT_API_KEY='<source api key>'
2nixploy import inspect --source dokploy --url https://old-panel.example.com
3nixploy import plan --source dokploy --url https://old-panel.example.com --source-project prj_123
4nixploy import apply --source dokploy --url https://old-panel.example.com --source-project prj_123Approach for everything else
- Install Nixploy on a fresh host (or parallel to the old one)
- Recreate projects / environments / services (or deploy equivalent templates)
- Attach domains, verify TLS and health
- Lower DNS TTL, flip A/AAAA records, watch traffic
- Decommission the old panel when stable
Concept map
- A project elsewhere ≈ Nixploy project + environment
- Application / service ≈ application, compose, or database service type
- Traefik labels ≈ Nixploy Domains (managed YAML, not hand-edited labels)
- S3 backups ≈ Destinations + backup schedules
- Compose stacks you already have ≈ a compose service (paste the file, clone it from Git, or point at a raw URL)
One difference worth planning for: each environment gets its own private overlay network, so a service resolves only services of its own environment. Put things that talk to each other in one environment. The deep guide lives in the repo: docs/migrate-from-another-panel.md.
Also see the repository guides under docs/ · REST API reference