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 the honest answer is "that's not automated" or "that's not self-serve yet," 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, and nothing about that changes if your subscription is later canceled (see If you cancel below) - reads aren't gated on billing status. (There is 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.)

One honest limitation: there's currently no CLI or tool that walks a whole project and copies it out programmatically in bulk - swarmfile-migrate only moves data into Swarmfile (from a NAS, S3 bucket, or file list), not out. For now, "mount it and copy the files" is the export mechanism. If you need to script a full-project export, talk to us.

If you cancel or your payment fails#

Canceling doesn't delete anything. What actually happens: the org drops out of its paid subscription state (there's no free tier - canceling doesn't downgrade you to a free plan, it just ends the paid one), and new uploads are blocked once that takes effect. Existing files stay fully readable - nothing about a canceled subscription touches reads, and nothing deletes or archives your data automatically. To resume normal use, you resubscribe.

Two things worth being precise about:

• There's no separate grace period on our side. If a payment fails (card declined, etc.), new-upload blocking can start during that failed-payment state, before the subscription is formally canceled - whatever grace period exists comes from Stripe's own retry schedule, not an additional buffer Swarmfile adds on top.
• If you stop paying and never resolve it, your data isn't automatically deleted. There's no automated cleanup job tied to billing status - an abandoned, unpaid org simply sits in the new-uploads-blocked state indefinitely until either you resubscribe or you contact us to close it out. That's a real limitation, not a hidden feature: don't rely on non-payment as a way to eventually purge data you want gone.

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#

This isn't a self-serve action today - there's no "delete this org" button in the dashboard. If you need an org fully torn down, contact us and we'll handle it directly. We'd rather say that plainly than describe a self-serve flow that doesn't exist yet.

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 tray for pending uploads and let them finish first.

Self-hosted seed nodes as an exit ramp#

A self-hosted seed node keeps a full local copy of a project's data on hardware you own, 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 in the shipping product today. 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 what the Enterprise self-hosted control plane is for: the same code runs entirely on infrastructure you control, up to a fully air-gapped deployment. See Deployment Topologies and talk to us about what that involves 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.