Guides
Getting StartedWorking with FilesFile PreviewsDeployment TopologiesVersion ControlBranches & MergingRunner (Headless CI)Sharing & CollaborationRFIs & SubmittalsNotifications & InboxSearchTrash, History & RollbackMigrating Existing Data
Admin & IT
Organizations, Projects & MembersIdentityPermissionsSelf-Hosted Seed NodesSecuritySecurity Architecture (Whitepaper)End-to-End Encryption SetupBilling & PlansOperationsDeploying to Your TeamData Portability & Offboarding
Reference
Filesystem Compatibility & ConformanceEngine Config File (config.json)Network Requirements
CLI Reference
swarmfileswarmfile-doctorswarmfile-migrateswarmfile-searchswarmfile-seedswarmfile-brlock
Browse docs
Guides
Getting StartedWorking with FilesFile PreviewsDeployment TopologiesVersion ControlBranches & MergingRunner (Headless CI)Sharing & CollaborationRFIs & SubmittalsNotifications & InboxSearchTrash, History & RollbackMigrating Existing Data
Admin & IT
Organizations, Projects & MembersIdentityPermissionsSelf-Hosted Seed NodesSecuritySecurity Architecture (Whitepaper)End-to-End Encryption SetupBilling & PlansOperationsDeploying to Your TeamData Portability & Offboarding
Reference
Filesystem Compatibility & ConformanceEngine Config File (config.json)Network Requirements
CLI Reference
swarmfileswarmfile-doctorswarmfile-migrateswarmfile-searchswarmfile-seedswarmfile-brlock
Docs / Admin & IT / Organizations, Projects & Members

Organizations, Projects & Members

An organization is the top-level container for your team: it owns projects, members, billing, and identity configuration. Everything in Swarmfile lives inside exactly one org.

Creating an organization#

There's no separate "create your workspace" step. When you sign up at /start, you register and an org is created for you in the same flow - you go straight from registration into Stripe Checkout to pick a plan. The org gets a slug auto-derived from what you typed at signup; if that slug is already taken, it's auto-resolved to something unique so signup never blocks on a collision.

The org slug matters beyond cosmetics - it's part of every public share link (/s/:orgSlug/:token).

Renaming your org#

As owner, you can rename the org's display name or its slug from Settings at any time.

Renaming the name is cosmetic. Renaming the slug is not: it invalidates every outstanding public share link tied to the old slug, and there's no redirect kept from old to new. Anyone with an old share link loses access silently. Because of that, changing the slug requires retyping the current slug as confirmation before it takes effect - treat it as a real, disruptive action, not a settings tweak.

Projects#

A project is a mounted filesystem within an org. Owners and members with sufficient permissions can:

  • Create a new project
  • Rename a project
  • Archive a project (read-only, unmounts for day-to-day use, reversible)
  • Soft-delete a project (removed from active use, recoverable for a retention window)

Each project runs in one of two modes:

  • Open mode - more permissive by default, suited to small teams or early-stage projects
  • Protected mode - enforces explicit ACL grants on folders and files

Mode selection and the underlying ACL model are covered in Permissions - this page only covers project lifecycle, not access control.

Inviting members#

Members are invited by email. An invite generates a link; the invitee accepts it to join the org. There is no separate "member role" concept layered on top of this - what an accepted member can actually see and do is entirely governed by the ACL system described in Permissions. Don't look for a role picker on the invite screen; there isn't one.

If your org has SSO or SCIM configured, provisioning can happen from the identity provider side instead of manual email invites - see Identity.

Who can see plan and usage standing#

Any org member - not just the owner - can see the org's current plan and usage standing: seats, storage, and how close the org is to any limits. This is surfaced in both the tray's plan panel and the web dashboard.

This is a deliberate choice, not an oversight. Owner-only areas of the dashboard - billing and usage administration - stay restricted to owners. Permissions administration and quarantine are open to admins as well as owners. The audit log itself is open to any member (ACL-filtered - you see events on entries you can read); only its CSV export, plus quarantine and org-policy events within the feed, stay owner-only. But plan and usage visibility is open to everyone on the org, so a member isn't left guessing why an upload is being throttled or what tier the team is on.

Seat count itself isn't something you set manually - it's derived from live org membership and kept in sync automatically. Details are in Billing & Plans.