About rbox
Hi, I'm Brian.
I'm a professional software engineer with 13 years of experience. I'm a full-stack engineer at Dfinitiv, Inc., and rbox is an independent project I built and operate in my spare time.
rbox is built and solely operated by me through Brian Via Digital Services, LLC, a company I formed in 2023. I handle the engineering, infrastructure, billing, security, support, and everything else that comes with it.
I've wanted this since 2017
Back in 2017, I wanted to keep all of my code in Dropbox. The problem was that Dropbox didn't have a .dropboxignore file. Syncing endless copies of node_modules, build output, and other dependencies made keeping multiple computers in sync basically impossible.
I've almost always had a fleet of machines: a server in my basement, Linux machines, Windows in the past, and now macOS and Linux. I kept wishing there were a version of Dropbox made specifically for development workspaces, but building it myself wasn't realistic at the time.
Then a few weeks ago, Theo mentioned wanting “Dropbox for devs” and explicitly called out a .dropboxignore file—the same thing I'd imagined years ago but Dropbox never shipped. With Claude Fable now available, it finally felt like something I could attempt.
Theo describing the problem at 22:58
Now I don't need to remember to run git pull on machines I haven't touched in days or weeks. If I'm working from the road, my laptop has the latest work from my server—including the Git state that hasn't been pushed anywhere yet.
I test it on my real development folder
Before turning rbox loose on everything, I made several backups. Most of my code was already on GitHub anyway, so the worst likely outcome was having to re-clone a bunch of repositories and run npm install again.
Then I dogfooded it on my entire development folder: more than 100 repos, over 100,000 files, lots of worktrees and branches, and LLM-assisted development churning out new work all day. It's currently running on an M2 Max MacBook and two Ubuntu 24 machines.
At times things did break and I had to fix them manually. Each one became a new case the daemon had to handle and a new criterion to validate. I also spent weeks tuning performance so it could scale with the available CPU and internet throughput instead of falling over on a real workspace.
I've been running it continuously for a few weeks now without data loss. Occasional hiccups still happen, but I'm getting more confident in it by the day.
Why I can't read your code
rbox is end-to-end encrypted because I never wanted to be responsible for anyone else's readable code—or become another surface area for an attack. I don't care to have your code, and I wouldn't expect you to simply trust me with it.
The daemon encrypts your files before uploading them. It makes you save a recovery key, and new devices can only be paired by you from an already signed-in device or the web UI. The service stores encrypted blobs, but I can't read their contents. The full details and the honest limitations are on the security page.
I'm exploring external auditing. I'm also open to releasing the client and APIs as open source if that's what developers need before they feel secure trusting rbox with their work.
What rbox intentionally doesn't sync
rbox explicitly ignores dependencies and build output. It keeps your Git state in sync when there are no conflicts, but it doesn't attempt to install or manage your dependencies for you. If two machines run different operating systems, syncing those generated files between them can be the wrong thing to do anyway.
Common directories like node_modules and dist stay local. If the defaults don't cover something in your workspace, you can add custom glob rules in an .rboxignore file.
The honest alpha caveats
rbox is still in alpha, and everybody is currently using it for free. I haven't accepted a dime of payment yet. It's still worth keeping a backup, especially while the product is this new.
The most recent hiccup I've seen is Git refusing to fast-forward a repo on its own. When that happens, rbox keeps the repo stuck in place instead of guessing or overwriting work. The daemon supplies its best guess for how to resolve it, then waits for you to handle the conflict manually.
There are also mass-delete protections built in, so a random rm -rf ~/dev on one device doesn't automatically propagate across your whole fleet.
If rbox ever shuts down
You won't lose the files on your devices; they just won't stay automatically in sync anymore. If I ever have to shut down the hosted service, I'll open-source the code so existing users can run it in their own Cloudflare accounts.
Where the service runs
rbox runs entirely on Cloudflare: Workers and WebSockets for the API, R2 for encrypted file blobs, D1 for account and device metadata, and Durable Objects to coordinate syncing. Your machines run a local Bun daemon.
The production R2 buckets are currently placed in Cloudflare's Eastern North America location. That describes their current placement, not a legal guarantee that all service data stays inside the United States. Cloudflare operates global infrastructure, and some metadata and processing may happen outside your country. The privacy policy has the formal details. Stripe handles payments and Clerk handles authentication.
Talk to me
If something goes wrong, email support@rbox.to or DM me. I'm pretty responsive, and if you're willing to provide anonymized logs, I'll help you work through the issue personally.