Your code never leaves your machines. Verify it yourself.
Last reviewed: 22 August 2026
Offsite has no cloud that sees your work. Your agents run on your machines. Your devices mirror them over SSH. This page explains exactly what travels where, and how to check every claim with your own tools.
The architecture, in three sentences
The host runs on your Mac or Linux box. It owns your sessions, your files and all state. The Mac, iPhone and Watch apps are thin mirrors that connect over SSH, directly or through an optional relay. There is no Offsite account, no Offsite database with your data, and nothing of ours in the data path that could read your traffic.
Connection paths
Every connection races the available paths and takes the fastest one that works:
- Local network. Direct SSH to your host. Nothing leaves your LAN.
- Your own VPN or Tailscale. Direct SSH through your own tunnel.
- The Offsite relay, optional. A bridge for when no direct path exists. Inside it runs the same SSH session, encrypted end to end between your device and your host. The relay forwards encrypted bytes and cannot decrypt them. Host-key pinning means even a malicious relay cannot impersonate your host. You can switch it off per host, and the connection pill in the app always shows which path you are on.
What leaves your machines, exactly
| Data | Where it goes | Contents |
|---|---|---|
| Terminal output, code, files, prompts | Your own devices only, over SSH | Never touches our servers. There is no server of ours in that path. |
| Push notifications (only if you enable them) | Our notification function, then Google FCM and Apple | The event type, the session and workspace name, a templated sentence like "api-refactor needs your input", and ids for host, workspace and session. Never terminal content, code or prompts. |
| Relay traffic (only if you enable the relay) | Our relay, running on Cloudflare | Encrypted SSH bytes we cannot read. No keys, no plaintext. |
| Update checks and downloads | get.offsite.sh | A version manifest and the build you install. No identifiers of yours. |
| iOS builds you send to your phone | A signed URL that expires after 48 hours | The app you asked to install, and nothing else from that machine. |
| Feedback (only when you press send) | Our Firebase project and our private team channel | What you typed, the platform and app version, plus a screenshot if you attach one. |
| Telemetry, analytics, crash reports | Nowhere | None is collected. There is no analytics SDK and no crash reporter in the apps. |
One honest nuance, because it is the only place where words describing your work leave your machine. A push notification has to be readable text, or your phone could not show it on the lock screen, so it is not encrypted end to end. It carries the name of the session and of its workspace. Agent sessions name themselves after what they are working on, which is what makes the notification useful and also means the name can describe your work. If a project name is sensitive, rename the session yourself, which always wins, or turn notifications off for that device. The content of your terminal never travels.
A push is also only sent to a device that is not currently connected in the foreground. While the app is open and attached, the same event arrives over your own encrypted connection and no third party is involved.
Keys and authentication
- Every device generates its own ed25519 key on first run. Private keys never leave the device.
- Your host’s SSH key is pinned on first connect. If it changes, Offsite blocks the connection and shows you both fingerprints instead of reconnecting quietly.
- Host state lives in
~/.offsitewith owner-only permissions: directories 0700, files 0600.
Agent permissions
Agents run in one of two modes, per session. Auto keeps the agent inside the workspace under the CLI’s own sandbox and approval rules. YOLO is full autonomy: the agent can do anything your user can do on that host. We do not soften that sentence, because that is what makes unattended overnight work possible. Run work you do not trust in auto mode, or on a host that holds nothing else.
The threat model, in plain words
- SSH access to your host means full host access. Offsite does not add a second permission layer behind SSH. Protect the host the way you protect the machine.
- Anyone with your user account on the host can read Offsite’s state directory. That is a property of running on your machine instead of in our cloud.
- A compromised relay could drop or delay your connection. It could not read or modify your session, because it never holds keys or plaintext.
- Offsite disappearing does not lock you out. Your sessions are plain tmux plus the official CLIs, on your own machine.
Verify it yourself
Do not take our word for any of this.
- Watch the wire. Run Little Snitch or
tcpdumpwhile you work. You will see SSH to your host, our notification function when an event fires, and a version check. Nothing else. - Check the state permissions.
ls -la ~/.offsite - Read what the host runs. The host is readable Python on your own disk, at
~/.offsite/bin. Open it. - Compare the pinned host key with your server’s:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
On our side, every commit runs the host test suite, a fresh install end to end, the Swift tests and a secret scan before a build can be published.
Reporting a vulnerability
Found something? Email robin@offsite.sh with "security" in the subject. We answer fast, we credit finders, and fixes are listed with dates in the release notes.
Related: the privacy policy covers the legal side of the same facts, and the documentation goes deeper on the sharp edges.