Docs

The short version: install rbox and run rbox setup on your first machine. To add another, run rbox pair on the first and paste its token into rbox setup on the new one. The recommended setup choice starts encrypted background sync and resumes it after reboot.

Install

curl -fsSL https://rbox.to/install.sh | sh

The installer supports Apple-silicon macOS and Linux on x64 or arm64. It needs curl and either sha256sum or shasum. Open a new terminal after installation, or source the shell file the installer names.

Set up your first machine

Start in the directory you want to sync. The normal first-account path uses browser signup; you do not need a bootstrap secret.

rbox setup

1. Choose Create a new account. At the account-bootstrap-secret prompt, leave it blank to sign up in your browser, then approve the code.
2. On a genuinely new account, accept Set up encryption on this first machine now?. rbox shows a 24-word recovery phrase and offers to save a plaintext recovery-kit file. Store either copy somewhere safe: there is no escrow, and rbox cannot recover it for you.
3. Choose Create a new workspace from a directory, then confirm the directory (the current directory is the default). The optional workspace name is visible to rbox and is not end-to-end encrypted: Enter accepts the suggested directory-derived name; enter - for no name.
4. Choose how to handle gitignored files. The default, Sync everything (current behavior), still applies the workspace-root .gitignore. Skip gitignored untracked files also applies nested.gitignore files while keeping tracked files in sync.
5. Setup writes the machine-local .rbox/workspace.json, publishes files first, then attaches Git history in a resumable second push.
6. At the start-sync step, the recommended first choice isStart background sync now and on machine boot. You can instead start it now only, or choose Not now.

If you were given an account bootstrap secret and enter it instead of using browser signup, setup also opens plan checkout. If checkout does not activate, setup binds the workspace without syncing and tells you to run rbox subscribe.

Add a second machine

Easiest path: when setup finishes on your first machine, it offersSet up another machine now — that generates the pairing token for you on the spot. You can also do it any time by hand:

On the first, already-enrolled machine:

rbox pair

The printed pairing token is a bearer secret that carries wrapped encryption key material. It is shown once, expires in about ten minutes, and can be used only once. Paste it only into the hidden prompt on the machine you are adding.

Install rbox on the new machine, then run:

rbox setup

1. Choose Log into an existing account.
2. Choose Paste a pairing token and paste the token.
3. Choose Sync an existing workspace, select the workspace, and choose its local directory.
4. Let the initial reconcile finish, then choose whether to start background sync now and on machine boot, start it now only, or leave it stopped.

Pairing both authorizes and enrolls the new machine for encryption. The first machine stays enrolled, and you do not re-enter the recovery phrase.

Bare rbox and automation

On an unenrolled machine outside a tracked workspace, bare rboxopens the same guided setup flow. Inside a workspace it shows status and actions; on an enrolled machine outside one it offers to create or join a workspace.

For scripts, rbox init is the noninteractive setup surface. Joining assumes the machine is already signed in and enrolled; a workspace id alone is not enough on a fresh machine:

rbox init --new --bootstrap <secret>
rbox init --workspace <id> --no-interactive   # already signed in and enrolled

Fresh CI runners and agents should normally use the keyed setup flow inAgents & CI below.

Everyday commands

rbox track ~/code/myapp                        # bind a directory (no first sync)
rbox track ~/code/myapp --workspace ws_ab12cd34 # join an existing workspace instead
rbox untrack [path]                            # stop syncing (local unbind; remote untouched)

rbox start [path]     # start background sync
rbox stop [path]
rbox logs [path] --follow

rbox sync [path]      # sync once (pull, then push)
rbox push [path]
rbox pull [path]

rbox status [path]    # workspace state + conflict metrics

rbox status is the one to reach for when you want to know what's actually happening — it shows sync health, whether the background daemon is running, and any conflicts, all without a network round-trip for the parts that don't need one.

What doesn't sync

Build output and dependency directories (node_modules,dist/, and friends) are ignored automatically. The workspace-root.gitignore participates by default; during new-workspace setup you can also enable nested .gitignore handling for untracked files. Use .rboxignore for anything you want excluded specifically from sync without changing what Git tracks.

rbox ignore "*.local.json"     # append a pattern (creates .rboxignore if it doesn't exist yet)
rbox ignore --list             # print the effective merged rule set

.rboxignore is a normal file, so it syncs like anything else — everyone on the workspace ends up with the same ignore rules automatically, no separate configuration step.

One sharp edge worth knowing: newly ignoring a pattern that matches files already synced is forward-only by default. Those files stop syncing future changes, but they are not deleted from your other machines — their last-synced copies just stay put. If you actually want a file gone everywhere, delete it locally first and let that delete sync, then add the ignore pattern.

Git-state and checkout sync

Your branch checkout, HEAD, index, and stashes follow you automatically, end-to-end encrypted via git bundle. When the receiving repo has no local divergence, rbox applies the checkout for you. If local work would be overwritten, it defers the checkout and makes that visible inrbox status instead.

rbox git resolve <repo>                              # inspect a deferred checkout
rbox git resolve <repo> take-theirs --confirm <token> # apply the incoming state

Git-state sync is on by default; opt a device out with:

rbox track ~/code/myapp --git false

Devices & account

rbox pair                      # mint a one-use token on an enrolled machine
rbox setup                     # on the new machine: existing account → paste token
echo <token> | rbox connect    # non-wizard alternative on the new machine
rbox login                     # authorize a new machine
rbox key recover               # re-enroll it from your recovery phrase

rbox device list
rbox device revoke <device-id>

Agents & CI (beta)

Ephemeral machines — CI runners, devcontainers, coding-agent sandboxes — can join a workspace with no human in the loop. Mint a key once, on a machine that's already enrolled:

rbox key create-ci --expires 90d       # prints RBOX_KEY — shown once, store it as a secret

Then in any fresh VM, one command pulls the workspace into the current directory and can keep it syncing:

RBOX_KEY=… rbox setup --workspace=myapp --dir .                         # pull, then exit
RBOX_KEY=… rbox setup --workspace=myapp --dir . --daemon --pull-only    # shared pull-only key
RBOX_KEY=… rbox setup --workspace=myapp --dir . --daemon                # writing agent; its own key
curl -fsSL https://rbox.to/agent.sh | sh -s -- --workspace=myapp --dir . # no rbox installed yet

A key can be shared across any number of pull-only machines (--daemon --pull-only). Give each machine that writes its own key.

Treat RBOX_KEY like an SSH private key: it carries the ability to decrypt your account's data, which is exactly what lets a server-blind service work headlessly. Keys expire (90 days is a good default), rbox key revoke cuts one off instantly, and the server itself only ever stores a hash of it — never the key, never your plaintext.

Benchmark methodology

The landing-page figures were measured July 13, 2026 on the live fleet using rbox v1.6.0 with shipped defaults. They are operational measurements, not synthetic best-case projections.

• First sync: elapsed time from starting setup on a new machine until all 120,000 files (9.7 GB) were usable locally. Older history continued attaching in the background.
• Change propagation: time from an edit on one enrolled machine until it was applied on another; 16.7 seconds at p50 across 233 events.
• Commit admission: server processing time to admit a commit, measured at roughly 281 ms after the latest improvements.
• Checkout follow: a field run carried the branch checkout, HEAD, index, and stash to another machine in a 71-second round-trip.
• Upload throughput: large-content transfers ran at the effective line rate.

All payloads followed the normal end-to-end encrypted path; benchmark traffic did not bypass encryption or use a special server mode.

Full command reference

The CLI documents itself — rbox help for the full grouped list, or rbox <command> --help for flags and examples on any one command. That's generated straight from the binary, so it's always exactly what your installed version supports.