Dokploy / Dokploy/dokploy

Network attached volumes as a first class citizen and platform default

Open
#3,814 0 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.