Security & trust

AES-256-GCM encryption at rest on paid plans

Private projects on paid plans store content as ciphertext. By default, per-project keys are managed centrally and wrapped by a hub-held KEK, so the hub can decrypt to provide authorized features such as previews. Managed encryption protects your data at rest, not from Swarmfile itself. For that, use the end-to-end tier. Public projects are plaintext on every plan - anonymous reads are served from unencrypted blocks - and a Free-plan org’s projects are public by definition. One exception on paid plans: git-LFS objects uploaded directly by the stock git-lfs client, and uploads of 64 MiB or more through our built-in LFS agent, are stored without application-layer encryption. LFS objects that go through the block path are encrypted as usual, and git-LFS is refused outright on end-to-end projects. An owner or admin can add a new managed key generation on demand: new writes seal under it, earlier generations stay readable, and stored content is not re-encrypted.

Opt-in end-to-end encryption

For teams that need it, an opt-in tier wraps each project key to your members’ own device keys, so it never reaches our servers in plaintext, with an org recovery key you hold. Content-only: filenames and sizes stay searchable; server-side previews turn off in exchange. Devices can be revoked and keys rotated without re-encrypting stored content - a new generation wraps for the devices that remain.

E2E key recovery without vendor custody

Each device has its own X25519 keypair, and existing members grant access by wrapping the project key to a new device client-side. An optional organization recovery key is split among administrators using Shamir secret sharing (2-of-3 by default), so one lost device or credential need not make the project unrecoverable. An optional key-granter can automate new-device and new-member enrollment for larger teams.

Content-addressed integrity

Every block is BLAKE3-verified on arrival. Corrupt data from a misbehaving peer or transport never reaches the application layer.

Signed, verifiable history

Commit history is hash-chained, and the hub publishes Ed25519-signed checkpoints of it periodically. The standalone swarmfile-verify-history verifier, on PATH with every desktop install, recomputes the chain from each commit’s own facts and checks the checkpoint signatures, with no engine or mount required. See swarmfile-verify-history.

Signed releases & verified updates

Every release is checked and its signature status recorded before it ships: macOS builds carry an Apple Developer ID signature and a stapled notarization ticket, and the Windows Setup.exe/.msi installers are Authenticode-signed (the Windows .zip tools and standalone swarmfile-doctor download are not code-signed yet, and SmartScreen says so on first run). A pre-publish gate checks the signature on the artifact a user actually runs, not just the build inputs. The desktop updater separately verifies the downloaded update payload’s cryptographic signature before replacing installed binaries.

Reed-Solomon 10+4 erasure coding

Adaptive per-chunk shard distribution. The first 10 shards reconstruct the data, so up to 4 slow or offline peers don't slow you down. On a multi-machine office with LAN shard placement enabled, shards are deliberately placed across those machines by rendezvous hash at replication factor 3 (not just opportunistically cached), so losing any one workstation doesn't cost you a shard; placement is inspectable per-file with swarmfile shards.

Per-org tenant isolation

Every organization gets an isolated database rather than a shared table distinguished only by tenant ID. New paid organizations use a dedicated physical storage bucket by default, reached through a credential scoped to that bucket; this provides a structural storage boundary from other organizations. Free organizations, older organizations, and paid organizations that opt out use an organization-keyed namespace in a shared block store. That shared mode relies on fail-closed application-level prefix enforcement rather than physical bucket isolation.

No kernel extension on macOS

The macOS installer ships our kext-free build (FUSE-T), which mounts entirely in user space: no kernel extension, no booting into Recovery to lower to “Reduced Security,” and no system-extension approval on Apple Silicon.

Folder & file ACLs

Per-project grants (read / write / admin, allow / deny, inherited). Resolution walks ancestors via a recursive CTE, and a deny wins. Owners bypass. Projects can be open or protected mode; a write-deny binds delete, create, move and rename-over in both modes. A grant - or a revoked deny - reaches an already-mounted drive’s listing like any other metadata change; a revoke is enforced immediately, and an entry the revoked principal can no longer see drops out on the drive’s next sync. An access revoke goes further: affected machines delete the cached blocks of the revoked files and confirm it back, and the org sees a purge receipt per device under Settings → Access revocations. The revocation itself is fail-closed: it’s recorded before anything is deleted, a machine that missed the first signal can’t be re-fed the file by a peer, and a machine that can’t reach the hub stops serving cached bytes after the default 7-day offline access lease.

Directory sync (SCIM + LDAP)

Bring your own identity provider. SCIM 2.0 bearer tokens, Entra and Okta PATCH dialects, plus a customer-deployed LDAP agent for on-prem AD.

Multi-IdP per tenant

Per-org external IdP config with hard-binding. JWTs are validated against the right JWKS by issuer. Owner-only break-glass via the Swarmfile IdP.

Project-scoped API keys

Headless engines (render farms, CI, NAS nodes) authenticate with a project-scoped API key that is structurally unable to reach any other project, and whose revocation takes effect across the fleet in seconds. It replaces copying a real user’s token onto every machine, which carried that user’s full account access.

Signed, guarded outbound webhooks

Every delivery is signed and timestamped, so a receiver can verify authenticity and reject replays. The signing secret is shown once at creation and stored encrypted; it is not returned through the management API. An SSRF guard rejects private and cloud-metadata addresses at creation and re-checks immediately before every delivery, and redirects are never followed. Endpoints are owner-gated (the same trust tier as an API key or SSO config), and every create, edit, delete, rotate and re-enable is written to the org audit feed. Endpoints auto-disable after repeated consecutive failures.

Hardened identity provider

Our built-in IdP is built against credential attacks: enumeration-safe registration, per-account exponential lockout on repeated failures, best-effort per-IP rate limits on selected authentication-sensitive endpoints, ES256 JWTs, per-user TOTP MFA, and refresh-token rotation with replay detection.

Org-enforceable MFA and verified email

On Starter and up, an owner can require an authenticator app (TOTP) and/or a verified email address for every member, starting immediately or after a grace window. Once enforced, any org-scoped request from a non-complying session, or from a personal access token minted by one, is refused org-wide with a typed error that names the remedy. Enrolling is never gated, the owner keeps an off-switch, and policy changes are audited. Members who sign in through the org’s own IdP are governed by that IdP instead. See Authentication policy.

Ransomware detection

Inline detection watches for many distinct files being overwritten in a short window, per user and machine, and responds in two tiers. The first only alerts owners; nothing is blocked. A larger sweep quarantines that user on that machine: commits pause and queued work is held, not lost (on Windows the drive stays mounted and saves are held locally), until an owner or admin releases it. Lock acquire and renew also check quarantine state.

Versioned history & rollback

Changes are timestamped, and retained versions can be restored within the configured 1-3650-day recovery window. Permanent deletion, retention expiry, account or organization deletion, and other documented lifecycle events can make older data unrecoverable. Swarmfile is not an independent backup; keep a separate copy of critical data.

Controlled change, not blind synchronization

Hub-enforced file locks, long-lived offline checkout locks, and a byte-range lock API prevent incompatible writers from silently overwriting each other. Teams can add protected branches, merge-request approval, atomic multi-file changesets, tags locked once released, and conflict detection for reviewable, attributable change.

Unified activity feed

ACL changes, history events, quarantine incidents, org audit, notifications and unlock requests in one feed (dashboard Activity tab), open to any member - ACL-filtered server-side so members see only events on entries they can read. Live-updating tail (polled); CSV export (100k-row cap) is owner-only on Pro. Cross-system SIEM export remains on the roadmap.

Share links with caps

Optional password gate, expiry, and access-count limits enforced atomically so concurrent requests can’t slip past the cap. Authenticated previews use a scoped session.

Verified-recipient share links

Every public share link now requires the recipient to confirm a one-time emailed link before any content (download, preview, or comments) is served, on top of any password. A 30-day session means a returning collaborator isn’t re-gated on every visit. The share’s owner gets a full log of verified recipients and can block one at any time. A block prevents the next new preview or download; an already-started end-to-end download may continue using its short-lived block token for up to five minutes.

Hub-only data-plane mode

For enterprises that block UDP/QUIC entirely, or that need to eliminate peer IP exposure: an org-level data-plane policy (or the engine-local SWARMFILE_HUB_ONLY toggle) disables peer-to-peer at startup. QUIC never binds, no peer discovery or gossip, swarmfile doctor reports clean. Reads fall through to plain HTTPS against the hosted storage layer. Owner-gated and audited.

Private P2P swarm

Our peer-to-peer transport runs in a private swarm - joining requires a pre-shared key and a custom protocol identifier. Random hosts on the internet can’t dial in to your blocks. A private project’s cleartext is never served peer-to-peer: peers serve only its ciphertext, so encryption is the confidentiality boundary on that plane. Public projects are served in plaintext, because their content is public anyway.

Connectivity diagnostics

swarmfile doctor is a single-binary CLI that walks enterprise IT through proxy, firewall, and DNS checks before they spend hours debugging. Colorized pass / warn / fail for the screen, JSON for ticket attachment. Also runs from the Desktop App (Diagnostics → Run Doctor…) and periodically in the background, with a hub-side /healthz/deep for round-trip probing.

Download for Linux: swarmfile-doctor-x86_64-unknown-linux-gnu

Customer-controlled storage and recovery copies

Pro and Enterprise teams can continuously mirror an eligible managed branch as ordinary files at their real paths into an S3-compatible bucket they control. Enterprise can instead use its own compatible bucket as primary block storage. Self-hosted seed nodes add local availability and performance; on managed encryption they remain ciphertext caches, not independently readable backups.