Feature request: support multiple Docker environments / hosts

[Shyrka973]

Problem. VolumeVault targets a single Docker daemon. There's no per-job host selector in the data model (backup_jobs has source_type / volume_name / host_path but no docker_host / server), and the app relies on the docker CLI's single implicit endpoint. To back up volumes across several Docker hosts today, you must run one VolumeVault instance per host.

Use case. Self-hosted/homelab setups commonly run 4–8 Docker hosts (here: 6). Managing N separate instances (and N onboardings, N upgrades, N sets of destinations) for what is conceptually one backup policy is a lot of overhead.

Proposed direction. A "Docker environments/hosts" concept (à la Komodo/Portainer): register multiple daemons (local socket and/or tcp:// with TLS or a socket-proxy), then let each backup job pick its target host. The volume/host-path pickers and the spawned backup container would run against the selected daemon. Even a minimal version — a global list of daemons + a docker_host column on backup_jobs — would remove the one-instance-per-host requirement.

Happy to help scope this if there's interest.

[Darkdragon14]

Hello 👋,

Yes, exactly.

Sorry, I don’t have a public roadmap yet, but this is definitely the next step I’m currently thinking about.

I’m still trying to figure out the best architecture for it, but I think the most likely direction will be an agent mode rather than directly connecting to multiple remote Docker daemons.

The goal would be to have one central VolumeVault instance, with lightweight agents running on each Docker host. Each backup job could then target a specific host/agent.

Thanks for the detailed proposal — this use case is clearly something I want to support.

[Darkdragon14]

Hi👋,

I’m currently finishing the improvements, missing features, and fixes for users who are having issues.

After that, I’ll start working on this feature.

Thanks for your patience!

[Shyrka973]

Thanks for the update — no rush at all, finishing the in-flight fixes first makes total sense.

Just chiming in to confirm the agent mode is the right call from where I sit. Registering remote tcp:// daemons would mean exposing a Docker socket (root-equivalent) across the LAN; a lightweight agent that runs the backup container locally and talks back to the central instance keeps that attack surface off the wire entirely. Good instinct.

A few things I'd be happy to help scope when you get there, from a 6-host homelab perspective:

• Enrollment / data model: a docker_hosts table + token-based agent registration, then a docker_host_id on backup_jobs — pretty much the minimal version you described, just with the daemon list populated by agents checking in rather than entered by hand.
• Where destinations resolve: does the upload (and the SSRF allowlist / egress guard) run on the central instance or on each agent? That choice ripples into the security model — agents uploading directly means the allowlist has to live agent-side too.
• Per-agent host-path allowlist: VOLUMEVAULT_HOST_PATH_ALLOWLIST becomes per-host, since /data on host A isn't /data on host B.

When it lands I can give it a real-world test across 6 Docker hosts and report back. Thanks again for being so responsive on all of this. 👍