Who Driftless is built for
The current release targets trusted deployments — your own family or personal devices on a server you control. Several design choices follow from that assumption, so it is worth understanding them before you expose the server more widely.
How clients authenticate
A device logs in once with a username and password and receives a bearer token, which it sends on every API call. The server stores only a hash of each token, never the token itself. Passwords are stored as bcrypt hashes. Tokens do not currently expire, so treat a logged-in device's config as a secret; revocation and expiry are planned.
How the admin is protected
The admin UI uses a separate server-side session cookie with a same-origin guard, independent of client tokens. Admin access and sync access cannot be exchanged for one another.
Storage and de-duplication
Chunks are de-duplicated globally: identical content is stored once no matter how many users have it. Reads are still authorized per user — you can only download a chunk that one of your own file versions references. One consequence of global de-duplication is that whether a given chunk already exists is detectable through the sync API. That is acceptable among trusted users; for mutually distrusting tenants, optional per-folder end-to-end encryption is on the roadmap.
Putting the server online safely
Driftless does not terminate TLS itself yet, so do not expose plain HTTP to the internet. Two good options:
- Private network (recommended): keep the server on a private mesh such as Tailscale and reach it from your devices over that network. Nothing is exposed publicly.
- Reverse proxy: put a TLS-terminating proxy such as Caddy or Traefik in front of the server and let it handle certificates.
Either way, the server should sit behind something that provides HTTPS before it is reachable from outside your home or office.