how it works
What's under the mount
The architecture, how your footage stays safe, the exit story, and the honest limits, for when you're evaluating JuiceMount seriously, not skimming. Back to the overview.
The technology stack
For the technically curious. Your NLE talks to a normal Finder volume: an NFS share served from localhost, tuned for Finder. Behind it the hot path stays on your Mac: SQLite for metadata, an SSD block cache with pinning, a write spool that keeps uploads moving on slow connections. Underneath, JuiceFS breaks file data into chunks stored as S3 objects on your NAS, with metadata in Redis.
Architecture notes, including the security model, live in the repo
JuiceFS is the open storage engine underneath: it chunks your files into objects and keeps the metadata. JuiceMount is everything that turns it into an editor's drive: a Finder-tuned NFS layer and a SQLite directory mirror so listings and search answer locally, an SSD block cache with pinning and offline files, a write spool that acks locally and trickles up, a menu-bar app with the four-state health system, and a Manager web UI for migrations, trash, and backups, packaged as one docker compose up.
Could you run raw JuiceFS instead? Yes. The format is open, and that's the point. You'd just be wiring the NFS layer, the caching, the pinning, the menu bar, and the day-2 ops yourself.
How your data stays safe
Speed is the easy question. Here's the one a burned editor actually asks: how do I lose footage with this, and what stops it.
A crash can't swallow an upload
Writes ack at local-SSD speed, then the spool trickles them to the NAS. Pull the plug mid-upload and the queued blocks are still on your SSD; they re-send on relaunch. Nothing is reported as safely stored until it is.
The map is backed up, not just the bytes
JuiceFS keeps file data as plain objects and the file → block map in Redis. Lose that map and the bytes survive but the filesystem can't name them, so the metadata dumps to your object store on a schedule (--backup-meta, hourly by default). Worst case is about an hour, and a corrupt Redis is a restore-from-dump, not lost footage.
If a box dies, the bytes are still readable
The on-disk format is open and documented: restore the latest metadata dump, point it at the objects, remount; or read the volume with the stock juicefs client, no JuiceMount involved. The menu bar shows degraded and fault states before they bite.
The honest caveat: a failed disk is your failed disk. RAID on the NAS and the offsite mirror the calculator turns on by default are what stand between you and data loss; JuiceMount surfaces the state, but you own the storage. What you trade for that, in full.
What it's not (yet)
JuiceMount is not a team-wide, multi-department collaboration platform. No review pages or approvals, no AI media search (filename search is instant today; content-aware search is roadmap), no Windows client; macOS only, and you run the NAS. One caveat from the README worth repeating: identical paths on every Mac is the designed multi-machine workflow, but heavy simultaneous multi-editor use hasn't been soak-tested yet.
The indie filmmaker and small-post-team tool: the raw performance of the Suite / Shade / Iconik / LucidLink category, none of the cost, on hardware you can tinker with. A real mount, a status system that tells the truth, and chunks you can walk away with.
The near roadmap, in the order it's scored: codec-aware Quick Look (spacebar previews for R3D, ARRI, BRAW, ProRes RAW), traffic-light backup verification on every project, bandwidth-aware auto-switching to offline mode on cellular, and project snapshots. The full roadmap is public. On the drawing board beyond it: a larger, Finder-adjacent app for browsing the library with richer metadata.
Your bytes are your bytes.
LucidLink speed, on the NAS you already own. Free, forever. Scrub 100 GB files touching only the blocks you play, pin projects for offline, and write at local-SSD speed while uploads trickle in behind you.
And leaving stays free in both directions: the built-in migration tool moves an existing library in, and your bytes sit in JuiceFS's open, documented format the whole time; the stock juicefs client reads the volume with no JuiceMount involved. The exit story, animated.
S3 and cloud collaboration have their place; this changes the cost equation for small teams so speed doesn't force inferior infrastructure.
What you'll need: a Mac on macOS 14+ and any box that runs Docker: a TrueNAS, a Synology, an old tower. The server stack is one docker compose up; the README's quick-start walks the rest.