Data Residency

Data residency lets you pin an organization's metadata and block storage to a real, infrastructure-enforced jurisdiction - EU or US - chosen once at signup. It's free and self-serve on every paid plan, Starter through Enterprise (Free-plan orgs use shared storage and can't pin a region); there's no price gate and no sales conversation needed to turn it on. FedRAMP and FedRAMP-High storage regions are on our roadmap for Enterprise. Swarmfile itself is not FedRAMP-authorized - if you have that requirement, talk to us before you plan around it.

This page is the operational how-to. For the underlying mechanism - how jurisdiction pinning actually works at the infrastructure level - see Security Architecture.

What this does and doesn't change#

• Platform-enforced, not a convention. This isn't an application-level rule we promise to follow - it's a real, platform-level restriction on where your organization's metadata and block storage physically live. Jurisdiction-pinned storage exists in a namespace that's invisible to any request that doesn't carry the matching jurisdiction; there is no shared code path that could accidentally route around it.
• Covers our system of record, not your own peer-to-peer transfers. Your own team's machines transferring files to each other over the peer-to-peer engine are already authorized devices on your own network - that's not something jurisdiction pinning governs, the same way a cloud region guarantee doesn't follow your own laptop once you've downloaded a file. If you have your own downstream residency commitment to your own clients, you can additionally turn on cloud-only mode (Settings → Network) to disable peer-to-peer entirely for that org.
• Global by default. If you don't choose a jurisdiction at signup, your org runs on our standard global infrastructure - this is a purely additive choice, not a change to what already exists.
• Immutable, on purpose. There is currently no way to change an org's jurisdiction after creation - not a missing feature, a deliberate one. Both your metadata store and your block storage have their jurisdiction fixed at creation by the platform itself; moving one means migrating to entirely new infrastructure, not flipping a setting. Choose carefully at signup.

Choosing it#

Pick Data residency on the signup form (or the organization-creation screen if you're joining as an existing user with no organization yet) - the choice is right next to the organization name field. Leaving it on Global (default) is the same as not having this feature at all; picking European Union or United States pins the org immediately upon creation, and a confirm dialog gates the choice specifically because it can't be undone.

FedRAMP and FedRAMP-High aren't in the self-serve picker: they're on the Enterprise roadmap, not available today. If you have a FedRAMP requirement, talk to us directly.

Known limitations today#

• No self-serve upgrade path. If your org is already running on global infrastructure, there's no way to move it to a pinned jurisdiction after the fact. This is the same "provisioning is a one-time, creation-time decision" constraint as Dedicated Storage, for the same underlying reason - neither your metadata store nor your block storage can be relocated once created.
• Org-level, not per-project. One jurisdiction covers every project in the organization; there's no way to pin an individual project to a different region from its siblings today.
• FedRAMP is roadmap, not self-serve. There's no in-app indicator for it, and Swarmfile is not FedRAMP-authorized - ask us before planning around it.