Network attached volumes as a first class citizen and platform default
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?
I am frustrated that there is seemingly no way to use NFS volumes outside of docker-compose applications where you can define them.
While I understand that Dokploy is not and does not aim to be k8s, it is very nice in k8s that you can set a default storage provider to a configured network CSI allowing you to by default run all your volumes on network attached storage. I think this is a powerful default and something i was bummed to see that Dokploy did not support on really any level. Especially with first class support of clustering via swarm, this feels like a natural next step to helping people build moderately HA or even just horizontally scalable Dokploy solutions.
There is definitely a user base who has large, redundant, and readily available network attached storage, and this would also allow Dokploy Nodes to be configured (hw-wise) to be on low storage devices.
Describe the solution you'd like
Phase 1: Create NFS/CIFS volumes as a first class citizen, on the volume create dialog offer NFS/CIFS as an option to give a path, params, etc. This will allow manual creation of NFS/CIFS volumes.
Phase 2: Allow an NFS/CIFS volume config to be the default for the platform, i.e. if you create a postgres db, it will by default use an NFS volume and not a local host docker volume without you thinking about it, or going in and manually swapping out the volume to a new network attached one.
Describe alternatives you've considered
I believe docker-compose deployments can create these currently, but its a weird feature to have gated to docker-compose deploys (which have other drawbacks) when you support clustering as a first class citizen.
The only other workaround I can imagine is using bind mounts, pointed at NAS mounted to each host in the same location, but then you give up volume backups, and portability.
It feels like there does not need to be so much compromise to use network attached storage and scale horizontally more easily.
Additional context
I will call out in full transparency. this is basically a replica of this issue (which has no traction): https://github.com/Dokploy/dokploy/issues/790. But with more context, and a very loose plan of how I imagine it could happen/roadmap. Also I am willing to build a PR of Phase 1 if wanted.
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
Start by locating the volume create dialog and the existing docker-compose volume handling. Define the scope for Phase 1 around manually creating NFS/CIFS volumes with paths and parameters, then investigate how platform defaults are applied to database volumes for Phase 2. Done means the selected phase is implemented and its volume behavior is verified across the relevant deployment flow.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, docker-compose, typescript
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100