Supported Platforms & System Requirements

Swarmfile ships desktop installers for macOS, Windows, and Linux, plus command-line tools with each. This page lists what runs where, what each installer includes, and the limits worth knowing before you plan a deployment.

At a glance#

Download them from swarmfile.com/download, or ask for the stable releases.swarmfile.com/latest/... URLs for a scripted install.

macOS#

• One universal build for Apple Silicon and Intel; macOS 11.0 or later, enforced by the installer.
• Use the .pkg: it installs the Desktop App, the engine as a LaunchAgent, the go-nfsv4 helper, and symlinks for every CLI tool into /usr/local/bin.
• The .dmg installs the Desktop App, whose bundle carries the engine, the runner, and the CLI binaries - but it doesn't set up the engine's LaunchAgent service, the go-nfsv4 mount helper, or the /usr/local/bin symlinks, so the engine isn't running as a service and the CLI isn't on PATH. On first launch the tray opens Diagnostics with the Reinstall action so one click puts them in place.
• Mounting is kext-free: Swarmfile bundles a patched FUSE-T, so there is no kernel extension, no Recovery Mode step, and no system-extension approval on Apple Silicon. A legacy macFUSE build path exists in the codebase but is not what the public installer ships.
• macOS 15+ additionally requires Local Network permission for LAN discovery; the app asks for it, and headless engines running outside the app bundle need to inherit it (or run as a LaunchDaemon). See Network Requirements.
• Installers are signed with a Developer ID and notarized/stabled.

Windows#

• x64 and ARM64 builds; Windows 10 or Windows 11. Both install per-machine into C:\Program Files\Swarmfile and add that folder to the machine PATH, so the CLI is available to every account.
• Use the bundled Setup.exe for people: it chains WinFsp, the Visual C++ Redistributable, and the WebView2 runtime, skipping whatever is already present. Windows Server/VDI images usually need those three staged by your own tooling first.
• Use the bare .msi for scripted rollouts (msiexec /i Swarmfile-x64.msi /qn /norestart): it installs only the app and expects those prerequisites to be present. It checks for WinFsp and the VC++ Redistributable during install and refuses with a message naming whichever is missing, rather than failing later with a side-by-side error; WebView2 isn't part of that gate, so stage it too. Repair and upgrade are never blocked by these checks. See Deploying to Your Team.
• Two Windows-specific behaviors worth knowing:
  • Symlink creation is refused on the mount. Windows needs Developer Mode (or a specific privilege) for an unprivileged process to create symlinks, so Swarmfile refuses consistently instead of failing for some users; reading, following, and listing symlinks all work.
  • PowerShell's Remove-Item cannot delete a directory on the mount; cmd's rmdir, Explorer, and Win32 RemoveDirectory work normally. This is a known difference in what the cmdlet does on its way in, not a filesystem contract bug.
• Release builds are Authenticode-signed.

Linux#

• x86_64 only. The .deb requires libwebkit2gtk-4.1-0, libgtk-3-0, and libfuse2; install it with apt and the dependencies resolve normally.
• It installs per-user systemd units (swarmfile-engine, swarmfile-tray) enabled globally, so new logins start them with no extra action; a user already logged in needs to log out and back in (or start the units) for them to take effect. The Desktop App unit is conditioned on a graphical session, so it does nothing on a headless box.
• The .deb does not touch your firewall; on a host with a default-deny inbound policy, allow UDP from the local subnet - see Linux firewalls.
• .rpm is not published today. The package is built and validated internally; if you run RHEL/Fedora/OpenSUSE, talk to us about a supported .rpm path.

Hardware and disk#

There is no formal RAM or CPU minimum: the engine is a native service, and the mount is a filesystem driver, both modest by desktop standards. The numbers that matter are disk-related:

• Local cache: 10 GiB by default (cache_max_bytes). Files you touch are cached locally and evicted as the cache fills; it is not a copy of the project. Adjust it in the Desktop App's settings or swarmfile cache set <GiB>.
• The mount reports at least 1 GiB of free space to applications even when the cache is full but evictable, so a "disk full" error from your app reflects local disk pressure, not the project's size.
• A seed/NAS node is different: it pins whole projects, so size its disk for the projects it serves. The sample seed config suggests a 100 GiB cache as a starting point and raising it to 1 TiB or more on a capable NAS.
• Project metadata, not file bytes, has a per-project limit of roughly ten million files and versions combined - very hard to reach unless you keep every version of a very large tree forever. See Project storage limit.

File and object size limits#

Content is chunked (FastCDC, 256 KiB-4 MiB chunks) and manifests are segmented once they grow past ~40,000 chunks, so a file on the mounted drive has no practical small size cap - multi-terabyte files work; the manifest structure extends rather than truncating. Two specific ceilings are worth planning around:

• git-LFS objects: 256 GiB maximum. A single LFS object beyond that is refused. Stock git lfs push also runs into the provider edge's ~100 MB request cap before then, which is why large pushes need the desktop transfer agent - see git-LFS.
• Hub-mediated downloads assemble up to 900 manifest segments per read; segmented manifests keep large files readable, but a very large stock git-lfs download over the hub can be refused where the desktop agent would succeed.

Platform capability differences#

The filesystem semantics are the same everywhere for ordinary work (create, read, write, rename, delete, locking). A short list differs by platform:

The full per-operation table, including the declared gaps (hard links, fcntl advisory locks, sparse files), is in Filesystem Compatibility & Conformance.

Where to go next#

• Release Channels & Updates - how installs update, staging vs production hosts, and reinstalling.
• Deploying to Your Team - silent install and MDM/GPO rollout.
• Network Requirements - the firewall allowlist before rollout.