Known Limitations

Swarmfile covers a wide surface - a mounted drive, version control, git, LFS, identity, billing - and some of it is deliberately not built, or works differently from the tool it replaces. This page collects the limits that most often decide a fit, stated plainly rather than left for you to discover during a rollout. Each entry links to the page that owns the detail.

If a hard limit here is a blocker for your team, tell us - it is how we decide what to build next. For the exhaustive per-subsystem gap list, see Filesystem Compatibility → Declared gaps.

What revoking access can and can't reach#

Revoking access - a removed grant, a removed member, a revoked guest, or a revoked device key - is enforced by the hub on every request immediately, and affected machines are told to delete their cached copy of the revoked files (removed from the drive's listing, cached file data purged, and a purge receipt the organization can see under Settings → Access revocations). Three boundaries are worth knowing before you plan a rollout around it:

A machine that never reaches Swarmfile can't be told. An offline computer deletes its cached copy the next time it reaches the hub. The organization bounds that delay with the offline access window, which is on by default (7 days): a machine that hasn't reached the hub within the window pauses local access (even to kept-offline files) until it reconnects. An organization that turns the window off has no upper bound on how long a disconnected machine keeps serving what it already cached.
Deletion is not cryptographic erasure on the managed tier. Cached files on managed and plaintext projects are deleted; on end-to-end encrypted projects the key is dropped so what remains is unreadable. In neither tier can Swarmfile reach bytes an application already read (they live in that app's memory), the operating system's page cache, or copies made by a third-party previewer or backup tool.
A removed member's own unsynced saves are kept. Work they saved that never uploaded stays on their computer, held rather than deleted, and uploads if access is restored (on encrypted tiers it is unreadable once the project key is dropped). Removal revokes access; it does not destroy their unuploaded work.

No Unreal Engine or Unity source-control plugins#

There's no Unreal Editor or Unity source-control provider for Swarmfile today, so those editors' built-in check-out and submit buttons won't talk to it. Teams work on the mounted drive directly and use the Desktop App or the swarmfile CLI for locks and commits.

This is separate from Revit/SolidWorks-class worksharing, which needs no plugin on Windows: there, Swarmfile honors the native OS exclusive-open lock the application already takes and turns it into a hub-enforced claim across machines. Detail: Moving from Perforce → Not supported.

No Perforce history importer#

There is no tool that reads a Perforce server's revision history and replays it as Swarmfile commits. A migration brings the head revision across; history in Swarmfile starts from there, and the old Perforce server stays around read-only for anything older. If you need the old revisions auditable, plan to export or retain them rather than decommissioning the server on cut-over. Detail: Moving from Perforce → Not supported, Migrating Existing Data.

No git rebase or history rewriting#

Swarmfile history is an append-only, server-side DAG of whole-file commits. It isn't rewritten - you can't squash, rebase, or clean up a run of autosaves into one tidy commit.

What you can do instead: swarmfile commit --amend -m "…" changes the most recent commit's message only (contents and history are untouched), and describe or tag puts a name on any past commit, including a bare autosave. restore and revert move history forward as new commits rather than erasing it. Detail: Coming from Git → What genuinely has no equivalent, Git and Swarmfile → Compatibility at a glance.

Importing an existing repository converts or skips some git shapes#

swarmfile git import brings a GitHub, GitLab or local repository into a project, but the git view is not a full git server, so a few things are converted rather than carried byte-for-byte:

Annotated tags have no equivalent and are imported as lightweight tags on the same commit (the default; --annotated-tags skip leaves them out, fail stops before creating anything) - tag messages and signatures are not preserved.
A branch the git view cannot hold - one containing submodules (.gitmodules), git-LFS pointers, or an octopus merge - is skipped and listed by the import; if the problem is on the source's default branch, the import refuses before creating the project.
Upstream rewriting and deletion stay out of sync. Re-running the import adds new commits, branches and tags; a force-pushed (rewritten) upstream branch is refused rather than mirrored, and branches or tags deleted upstream are not deleted in the project - remove those there with the normal branch and tag commands.
Git-LFS objects aren't fetched by the importer. An LFS-using default branch is refused and an LFS-using side branch is skipped, rather than importing pointer files with no objects behind them.

What you can do instead: keep the source as history-of-record until the import is verified, and prefer git push/git-LFS as the ongoing bridge when the repository keeps moving. Detail: swarmfile git import, Git and Swarmfile → Compatibility at a glance.

git-LFS isn't available on end-to-end encrypted projects#

A stock git-lfs client can't hold the per-user key, so git-LFS is refused on end-to-end encrypted projects. It works on managed-key and unencrypted projects, with one carve-out worth knowing: objects uploaded directly by the stock git-lfs client - and uploads of 64 MiB or more through the Desktop App's built-in LFS agent - are stored without application-layer encryption. Smaller uploads through the built-in agent, and every upload through the standalone swarmfile-lfs agent, are encrypted like any other block. If a binary must be encrypted at rest, keep it on the mounted drive rather than routing it through LFS. Detail: Git-LFS → Which projects it works on, Security → Encryption.

Git materialization follows your access today#

A clone or fetch reads the whole of every commit it walks - each commit's tree exactly as it was archived - and access is evaluated against the access you hold today:

A folder restricted for you now means any commit whose tree contains it can't be handed over whole; a clone or fetch that has to walk one is refused with a message saying so, rather than returning a repository with silent holes. Grant read and the same clone succeeds - including commits made while you were restricted; materialization is not frozen to the access of the commit's date.
Restricting a folder retracts it from clones at once, for new commits and old ones alike.

The mounted drive, swarmfile materialize and git all follow the access you hold today. The access that existed when a commit was made is still recorded, and an explicit point-in-time history view can ask for that replay - it is not what git reads. Detail: Clone a project → What a clone contains.

A release copy is a snapshot of files and directories#

Copying a release - the web Copy to my org action or swarmfile clone … --into - lands the release's files and directories as a new snapshot on the destination's default branch. It is not a fork of the project: no history, no tags, and no later sync from the original.

The web action always creates a public project (it copies a public release). For a private destination, copy through the Desktop App's CLI instead - it seals the blocks on your machine before they upload (see Publishing releases → Getting a copy).
Symlinks are not part of a public release, so a copy contains none; directories are recreated from the manifest's paths.
A copy adds files; it never overwrites. A same-name file with different content refuses the copy, and a destination whose default branch is protected refuses it (409) until the protection is lifted.

Encryption tier is fixed at project creation#

Managed (the default), end-to-end, and plaintext (public) are chosen when a project is created and never change afterward. Upgrading a plan, or deciding later that you want E2E, does not retroactively encrypt an existing project - you create a new project at the tier you need and bring the content across. Choose deliberately at creation if encryption posture matters. Detail: Getting Started → Creating a project, Security Architecture → Unencrypted tier.

There's no email-domain auto-detection. A member signing in with SSO enters their organization's slug (the short name in the org's Swarmfile URL), or follows a direct per-org sign-in link an admin can share - rather than typing an email and being routed to the right identity provider automatically. It is a one-step onboarding cost for non-technical staff; the per-org link removes it on a machine an admin provisions. Detail: Getting Started → Signing in, Identity.

Switching accounts requires an app restart#

Switching to a different account while the app is running is refused (account_switch_requires_restart). Any unsent work from the previous account stays on your machine, quarantined rather than lost. The requested sign-in is kept: restart when the Desktop App offers it and the switch completes. This is most visible to freelancers and contractors working across several client orgs in a day. Detail: Getting Started → Signing in.