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 in the panel
Open Migrations in the navigation or command palette. Connect a Dokploy or Coolify live API, or upload a Dokploy PostgreSQL dump, select an environment and services, choose an accessible target and generate a redacted plan. Review changes and manual work, then explicitly import configuration. Source/selection/target changes invalidate the review; changes discovered at apply require a fresh plan. The API key stays in page memory and is cleared on source changes, completion or leaving. Imports deploy nothing. Results link to the target and list the secret, database, persistent storage, server, registry and domain work needed before cutover.
Import over the source's API
For a supported source panel (Dokploy or Coolify), 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_123Coolify live API support
Select Coolify in Migrations or use --source coolify. Enable its API and use a team-scoped read token, adding read:sensitive for readable environment values and raw Compose content. The verified v4.4.6 slice covers image/public-Git applications, raw or one-click Compose services, PostgreSQL/MySQL/MariaDB/MongoDB/Redis configuration and HTTP domains. Repository Compose applications and other database engines are reported as unsupported. Runtime names are fresh; source data, server/provider keys, registries, shared-variable libraries, custom commands, ports and proxy middleware need manual setup. Hidden/null/once-only/shared-reference or unrepresentable value groups preserve target values with notes. Imports deploy nothing; only PostgreSQL has separate real database runtime proof.
Import from a database dump
When the old panel is unavailable, use --dump-file panel.sql.gz in place of --url and the API key. The dump is restored in a temporary Postgres container with no network, then removed. Uploaded dumps expire after 24 hours. Plain SQL, gzip and custom pg_dump formats are supported.
Encrypted source env cannot be decrypted by the importer: both keys and values need manual input. Ciphertext is omitted with a warning, and repeating the import preserves values you entered here. File mounts and incompatible named volumes need manual setup; existing target mounts are kept. Database passwords are replaced; update connection URLs and restore application data separately before deploying. Source volumes, data and traffic are not moved automatically.
Approach 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