DropBridge — drag-and-drop file transfer between your ZimaOS boxes, over the tailnet

I’ve been building DropBridge: a small self-hosted web UI that streams files
straight from one machine to another over your Tailscale tailnet — no cloud, no
size limits, no one-shot upload caps, and folders keep their structure. It’s a single
~14 MB Go binary (stdlib-only, non-root) that runs on any Linux box with Docker +
Tailscale
— and it’s first-class on ZimaOS/CasaOS (dashboard tile + data-disk picker),
which is where I run it.

What it does

  • A live mesh console: every node with online-state, WireGuard link, telemetry
    (disk, uptime, kernel) and real latency to each peer.
  • Drag-and-drop, machine-to-machine transfer — pick a target node, drop a file/folder,
    it streams peer-to-peer.
  • Storage picker: choose exactly which data disk received files land on — it never
    writes to the eMMC or a foreign (exFAT/NTFS) filesystem.
  • Presence/identity via your Tailscale login; a public one-click share link (funnel)
    when you need to hand a file to someone off your tailnet.
  • Non-root, file-secret token, control plane is tailnet-only (LAN/Internet get 403).

Running it on ZimaOS — two things worth knowing
If your Tailscale is the App-Store app (it runs as a container):

  1. Expose its socket to the host — add a bind mount to the Tailscale app:
    /var/run/tailscale -> /run/tailscale, then recreate it (AppID=tailscale).
  2. DropBridge runs with network_mode: host (the shipped compose already does this),
    so it sees your real tailnet IP instead of the Docker bridge gateway — otherwise the
    UI falls back to “demo mode / tailnet identity required”.
    If tailscaled runs as a native host service instead, it just works out of the box.

(Big thanks to Gelbuilding, who test-drove it on a ZimaCube Pro ↔ ZimaBoard and
found both of the above — the installer now checks for the host socket and prints the
fix automatically.)

Get it: GitHub - chicohaager/dropbridge: Self-hosted, tailnet-native peer-to-peer file transfer — any Linux with Docker + Tailscale, first-class on ZimaOS/CasaOS · GitHub (MIT)

Pull the prebuilt, signed multi-arch image (amd64 + arm64) — no build needed:

docker pull ghcr.io/chicohaager/dropbridge:0.2.0
docker compose -f docker-compose.ghcr.yml up -d

Release v0.2.0 (with the demo video + this ZimaOS test package attached):

Feedback very welcome — especially rough edges on real hardware.


About: built by Holger Kuehn (Virtual Services) — a computer scientist
(Diplom-Informatiker, the German master’s-equivalent in CS) and career systems
engineer (VMware vExpert, Microsoft Certified Professional, Oracle DBA).
DropBridge was built AI-assisted and deliberately so: every architectural decision,
the threat model, and the on-hardware verification were mine; the AI removed the
typing and served as a tireless review pair. That’s the opposite of “vibe coding”,
which ships whatever a model emits unread — here, only what a systems engineer stood
behind, tested on real nodes, shipped. A developer who refuses AI in 2026 isn’t more
of a craftsman — just slower; the craft moved up a layer, to judgment, architecture
and verification.

1 Like

One Use Case for DropBridge (already productiv on customer side): Real 3-2-1 Backup - Restic - Zima-Cron-Job

1 Like

This is very impressive work, Holger.

I tested DropBridge on real ZimaOS hardware between my ZimaCube Pro and ZimaBoard, and the idea makes a lot of sense once you see it working.

What I really like is that it is not trying to become another cloud file service. It stays local-first, tailnet-native, and machine-to-machine. For ZimaOS users who already run more than one box, this is exactly the kind of tool that fits the platform.

The live mesh UI is also excellent. Seeing each node, online state, latency, disk info, uptime and kernel details in one view makes it feel much more like a real ZimaOS companion tool rather than just a file uploader.

During testing, the main difference we found was between native Tailscale and the ZimaOS App-Store Tailscale container. On my setup, Tailscale was running as the App-Store container, so that exposed a ZimaOS-specific case that would not show up on systems where tailscaled runs natively.

Holger has already adjusted DropBridge for that case, and the installer now checks for it and gives the correct guidance automatically.

I also like the backup direction you mentioned. A Zima-to-Zima workflow using DropBridge, Restic and Zima Cron makes a lot of sense for real 3-2-1 backup setups, especially for users who want to keep control of their own storage and avoid cloud limits.

For me, this is exactly the type of community project that adds real value to ZimaOS:

local-first
self-hosted
tailnet-aware
tested on real hardware
simple enough for normal users, but still technically clean underneath

Great work, mate. I’m looking forward to seeing where this goes.

2 Likes

DropBridge + Restic — Install & Automated Backup Guide for ZimaOS A step-by-step guide: Install DropBridge on ZimaOS, then protect its data — and the rest of your box — with encrypted, deduplicated Restic backups pushed to an append-only repository over your tailnet, scheduled from the ZimaOS Cron module
download

Excellent work, Holger.

This is a very strong direction for DropBridge. The drag-and-drop transfer is already useful on its own, but combining it with Restic and Zima Cron makes the project much more practical for real ZimaOS use.

The part I like most is that this becomes a proper Zima-to-Zima backup workflow:

source ZimaOS box
DropBridge over the tailnet
Restic encrypted and deduplicated backup
append-only repository
Zima Cron scheduled job

That is a very clean setup for users who want local-first backup without relying on cloud storage or exposing services to the internet.

I also like that the guide focuses on protecting not just DropBridge data, but the rest of the box as well. That makes it much more useful for normal ZimaOS users who may already have AppData, media folders, documents, and other important data spread across different disks.

This is exactly the type of guide that helps the community, because it turns the tool into a real workflow rather than just an app install.

Thanks for putting the ZimaOS-specific guide together. I will go through it properly when I get some time and test the workflow on my own boxes.

1 Like


Great work by Holger on DropBridge.

I tested the latest GitHub release on my Zima setup and now have it running across three ZimaOS machines:

ZimaBoard2
ZimaCube-Pro
ZimaBoard

All three are online over Tailscale with live topology showing:

3 online · 3/3 nodes · WireGuard

The Add node panel is excellent. It detected my tailnet devices, showed online/offline state, tailnet IPs and OS type, and allowed me to add another Zima node directly from the UI.

This now feels like more than a file transfer tool. It feels like a proper Zima-to-Zima tailnet console with storage, latency, uptime, kernel version and Tailscale version visible in one place.

On ZimaOS, the only important setup point I found is that the Tailscale App Store container needs the host socket exposed:

/var/run/tailscale > /run/tailscale

Once that is done, DropBridge works very nicely with host networking and the shared secret.token.

Very polished work by Holger.

1 Like

Update from testing:

I tested a real folder transfer from ZimaBoard2 to ZimaCube-Pro.

The transfer completed to the Cube storage path:

/media/HDD-Storage/DropBridge/incoming

The folder structure was preserved correctly, including nested subcontractor folders such as Contract, Tender, Progress Claim, Shop drawing and Variation.

This was a 500MB+ folder with nearly 300 files, so it was slower than sending a single large file, but it worked.

Important finding:
Using “Choose folder” works correctly.
Dragging a folder directly onto the drop zone currently completes as “Delivered 0”, so folder drag/drop may need a small fix.

Overall, very impressive. DropBridge is now working across three ZimaOS nodes and real folder transfer is confirmed.