Detach Remote Server and Promote to Standalone Dokploy Instance
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 37.4k
- Forks
- 3k
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 73
Description
What problem will this feature address?
When using Dokploy with remote servers, there is currently no way to safely detach a remote server from the main Dokploy instance and turn it into a standalone Dokploy server.
If a remote server is removed, Dokploy loses ownership of all existing applications, databases, and Docker volumes running on that server. There is no way to re-adopt these existing resources in a new Dokploy instance, which makes infrastructure refactoring and server separation very difficult, especially for stateful services like MongoDB and PostgreSQL.
Describe the solution you'd like
Provide an option to detach a remote server from the main Dokploy instance and promote it to a standalone Dokploy instance.
The new standalone instance should be able to adopt existing Docker resources on that server, including:
- Existing containers
- Existing Docker volumes
- Existing databases (MongoDB, PostgreSQL, etc.)
This process should not require recreating applications or databases and should result in zero data loss.
Describe alternatives you've considered
Current alternatives include manually recreating all applications and databases, or running databases outside of Dokploy entirely.
Both approaches add operational complexity and increase the risk of configuration errors or downtime, especially when managing multiple stateful services.
Additional context
This feature would be especially useful for teams restructuring their infrastructure, migrating from centralized to decentralized Dokploy setups, or separating ownership of remote servers without downtime.
Related concepts:
- Detach Remote Server
- Promote Node to Standalone Instance
- Adopt Existing Docker Resources
- Bring Your Own Database (BYOD)
Will you send a PR to implement it?
Yes
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no files, tests, or entry points. Start by tracing how remote servers and their containers, volumes, MongoDB, and PostgreSQL resources are managed and adopted; done means a remote server can become standalone without recreating resources, data loss, or downtime.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, mongodb, postgresql, typescript
- Domain
- backend, databases, devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100