Data Portability & Offboarding

Straight answers to the questions that usually come up during procurement: how do we get our data out, what happens if we cancel or downgrade, and what does uninstalling actually remove. Where something isn't automated or self-serve, it's stated as such rather than glossed over.

Getting your data out#

Because a Swarmfile project is a real mounted drive rather than a walled-off web UI, there's no special export step: copy files off the mount with Finder, Explorer, cp, rsync - whatever you'd normally use. There's no throttle or block on bulk reads while your org is in good standing, and any method below works right up until the moment you cancel - which, as If you cancel or your payment fails explains, starts a countdown rather than leaving reads available forever. If you're leaving, export first. (There is also a WAN bandwidth throttle you can optionally schedule for office hours, but that's a setting you control for your own network's sake, not a vendor-imposed export limit.)

For a scripted or continuous bulk export, Branch Mirror (Pro/Enterprise) does exactly this: it continuously exports a project branch into an S3-compatible bucket you control, as fully-hydrated real files at their real paths - not Swarmfile's internal format - a practical continuous export. The honest caveats: it's configured per branch, it's asynchronous (changes land in your bucket within a few hours - about three on an active project, about six while it is idle - not instantly), it tracks the branch continuously rather than capturing a point-in-time snapshot, so it complements a scheduled backup rather than replacing one, it's managed-tier only (end-to-end encrypted projects are refused, since the hub can't decrypt them to hydrate readable files), and it requires a Pro or Enterprise plan. One thing worth knowing in your favor: an already-running mirror keeps syncing even through the grace period described below, when the mount and web app are otherwise locked out - set it up before you need it, not after. swarmfile-migrate, by contrast, only moves data into Swarmfile, not out. If you'd rather not stand up a mirror, "mount it and copy the files" is always available as the manual export mechanism - talk to us if you need help.

If you use Swarmfile as a git-LFS server, there's a third exit that's fully self-serve and needs no Swarmfile software at all: git lfs fetch --all pulls every LFS object into your local git-LFS store with stock git-LFS, git lfs fsck verifies each one, and you then repoint .lfsconfig at any other LFS server (GitHub, GitLab, an S3-backed server, self-hosted) and git lfs push. Because your source lives in your own git host and only the binary objects are in Swarmfile, this gets those objects out with standard tooling and no vendor dependency - see Leaving Swarmfile in the git-LFS guide. On each machine that pushed large objects, run swarmfile-lfs uninstall to remove the transfer-agent wiring from git config once you're done (committed .lfsconfig files and stored credentials are separate - the command tells you what it left alone).

If you cancel or your payment fails#

Both paths lead to the same place: a 28-day grace period during which the org's content is inaccessible, followed by permanent deletion. There is no indefinite post-cancellation read state - treat cancellation as a deletion deadline and get your data out first (see Getting your data out).

If you cancel deliberately (via the Stripe Customer Portal): the org leaves its paid subscription state (there's no free tier it falls back to - it doesn't become a Free-plan org), and for the first ~24 hours nothing else changes, a deliberate cushion so an accidental click can be undone by resubscribing. After that window the org is flagged as unsubscribed and the standard grace period begins, exactly as if a payment had failed:

• A real 28-day grace period runs, tracked independently of Stripe's own retry schedule - from the moment the cancellation is flagged, not shortened or extended by whatever dunning timeline Stripe itself runs.
• Reads are blocked too, not just new uploads - everywhere, not only the mount. The desktop mount, the web dashboard's own download/preview, and public share links you've handed out all stop serving that project's content for the whole window, not only once the deadline nears. The dashboard and billing page themselves stay reachable so you can resubscribe. The one deliberate exception is Branch Mirror: an already-running mirror keeps exporting through the grace period, covered above.
• We email the org owner as the window closes (day 1, 7, 21, and the 27th day) so there's real warning before anything happens, not a surprise.
• If the 28 days pass with nothing resolved, the org's data is permanently deleted - and so is the owner's account, if they don't belong to any other org. This includes every project, file, and version in the org, the underlying storage, and the org itself; it also includes the owner's Swarmfile login if that org was their only one (an owner who's a member of another org keeps their account either way). This is genuinely irreversible.

If a payment fails and is never resolved (a declined renewal, an expired card, and Stripe's own retries are exhausted): the same 28-day window starts from the moment the payment first failed, with the same blocked reads, the same reminder emails, and the same permanent deletion at the end.

Resubscribing at any point before the 28 days are up cancels the countdown entirely and restores access, with nothing lost. If a payment is failing and you want your data out, do it before the window closes - and if you want to leave without a deadline, either export first and then cancel, or ask us to delete the org outright (below) once your export is done.

If you downgrade over your new plan's limit#

Downgrading (Pro to Starter, for instance) when your stored data exceeds the smaller plan's included allowance doesn't delete or lock anything either. The included allowance is a billing threshold, not a hard ceiling - you'd simply be billed overage on the excess, exactly as if you'd grown into it gradually on your current plan. New uploads only actually get blocked if you cross a much higher hard ceiling (an abuse backstop, well above what any plan advertises as included) - existing files remain fully readable at every point in between.

Deleting an organization entirely#

If you want an org torn down on your own schedule - not because of a lapsed payment - the org owner can do it from the web dashboard: Settings → Organization → Delete organization. It asks you to retype the org slug, and to enter your password if your account has one; it must be done from an interactive sign-in - an API key or personal access token can't perform it. It then cancels any active subscription, revokes the org's API keys, disconnects any connected GitHub App installation, and deletes the org, its projects, its files, and its stored data. The purge writes durable audit rows that outlive it, so the org deletion remains auditable after the data is gone; if the credential revoke stalls, the purge reports credential_revoke_pending rather than success. It is immediate and irreversible, so make sure your export is complete first. Admins and members won't see the control; it's owner-only. If you'd rather have us handle the deletion, contact us and we'll do it directly.

The automatic 28-day path described above is the one exception: that deletion is triggered by billing status, not a support request, for the reasons explained there.

Uninstalling the desktop client#

Uninstalling a machine never touches your account or org data - that all lives on the hub, not the machine you're uninstalling from. What the uninstaller does not do, on any platform, is clear that machine's local cache (the block cache, upload queue, and local metadata database) - that's left in place, in case you're reinstalling rather than fully decommissioning the machine.

The one real risk: Swarmfile's writes are designed to return instantly and upload in the background - a save is only visible to your teammates once it's actually finished uploading to the hub, which for a large file can take a while after the save itself completes locally. If you uninstall (or, more precisely, wipe that machine's local Swarmfile cache) while an upload is still queued and hasn't finished confirming with the hub, that specific save is lost - it never makes it to the hub, and nobody else ever sees it. Reinstalling on top of the same, un-wiped cache resumes the queue and finishes the upload normally; wiping the cache and starting fresh does not. In practice: before decommissioning a machine, check the Desktop App for pending uploads and let them finish first.

Self-hosted seed nodes as an exit ramp#

A self-hosted seed node fetches and mirrors a project's data through hardware you own - keeping a warm local cache on it - which sounds like a natural answer to "what if the hosted service goes away." For the standard managed (encrypted) tier - the default, and what most projects use - it's a more qualified answer than that framing suggests: what the seed node holds is ciphertext, and reading it depends on a decryption key fetched live from the hosted hub. There's no offline fallback for that key. So a seed node is a genuine speed and reliability win for your office day to day - most reads served locally, less dependence on your internet connection - but it isn't an independently readable backup you could fall back to if the hosted service were ever permanently unreachable.

If true offline independence - not just a warm local cache, but a fully self-contained deployment with no dependency on our hosted infrastructure at all - is a hard requirement, that's the Enterprise self-hosted control plane: the same code running entirely on infrastructure you control, available on Enterprise (a fully air-gapped deployment is on the roadmap) - see Deployment Topologies and talk to us about what it would involve for your environment.

Where to go next#

• Billing & Plans - how plan switching, seats, and overage actually work.
• Self-Hosted Seed Nodes - running your own warm cache tier.
• Security Architecture - the full key-custody and threat-model detail behind the encryption note above.