1 line
in .lfsconfig
Your git remote stays on GitHub. Only the large objects go to Swarmfile, through stock git-lfs.
Comparison
Swarmfile vs. GitHub LFS
Keep GitHub for code, pull requests and CI. Point your repo’s lfs.url at Swarmfile for the big files. This page is about that split: what changes for your large objects, what doesn’t, and where staying all-in on GitHub is the better call. Last reviewed October 2026.
The frame that matters
256 GiB
per object
Chunked, resumable pushes through the swarmfile-lfs transfer agent. Stock git-lfs works up to ~100 MB.
$0
egress, every plan
Storage is billed like any other content. Downloads, CI included, are never metered.
Where GitHub is stronger today: one place for code, PRs and Actions, the ecosystem, no second vendor, and a full git host. We don’t hide it. See the full side-by-side below.
IncludedPartial or with conditionsNot offeredA highlighted row marks where one side clearly leads.
How the split works
Capability
Swarmfile
GitHub LFS
Where code, PRs and CI live
Stay on GitHub. Swarmfile is only the LFS endpoint here:
git push still goes to GitHub, git lfs push / pull go to Swarmfile.✓Code, pull requests, Actions and LFS objects all in one place.
Setup
◐Commit an .lfsconfig whose lfs.url points at your Swarmfile project, then store a project-scoped credential once per clone. Stock git-lfs, nothing else required.
✓Built in:
git lfs track and push. No extra endpoint or credential.GitHub App onboarding
◐Coming soon: a GitHub App that opens the .lfsconfig setup pull request and mints the credential for you. The manual setup works today.
Not needed; LFS is part of the repo.
Nothing about your code workflow moves. Your git remote stays on GitHub; one committed line in .lfsconfig sends the large objects to Swarmfile instead.
Large objects
Capability
Swarmfile
GitHub LFS
Per-object size ceiling
✓Up to 256 GiB per object (within your project quota) through the swarmfile-lfs transfer agent, which pushes in chunks and resumes an interrupted upload. Stock git-lfs pushes objects up to ~100 MB with no agent.
◐A plan-dependent per-file size limit. Check GitHub's docs for the limit on your plan.
Checkout behaviour
✓Stock
git lfs pull / checkout download objects as usual. Pushed objects can also be reflected onto the project's mounted drive, where apps stream just the byte ranges they read instead of downloading the whole file.◐Objects download to the working tree on checkout or pull (include/exclude filters narrow which ones).
Deduplication & chunking
✓Objects pushed through the chunked agent are stored as content-addressed blocks, deduplicated against each other and against the same content on the mounted drive. Re-pushing an unchanged object transfers nothing.
◐Whole objects keyed by their SHA-256: an identical file is stored once, but a changed file is a new whole object.
Storage & bandwidth billing
Capability
Swarmfile
GitHub LFS
Storage
Billed like any other project content, inside the per-seat allowance (100 GiB/seat on Starter, 500 GiB/seat on Pro).
Metered LFS storage. Verify current allowances and prices at docs.github.com.
Bandwidth / egress
✓Free and unlimited on every plan: a CI job pulling assets on every build costs nothing extra.
◐Metered LFS bandwidth. Verify current allowances and prices at docs.github.com.
The line that changes the math for CI-heavy teams: Swarmfile bills storage and never meters downloads.
Locking
Capability
Swarmfile
GitHub LFS
File locking
✓
git lfs lock / locks / unlock on every tracked path. When a path is also on the mounted drive, the git-lfs lock and the drive lock are the same server-side lock, so nobody can check it out twice by two routes.✓
git lfs lock / locks / unlock, with lockable files kept read-only until locked.Encryption, git access & leaving
Capability
Swarmfile
GitHub LFS
Encryption at rest
◐Read this one carefully. Objects uploaded directly by the stock git-lfs client, and 64 MiB+ uploads through the desktop app's built-in agent, are stored without application-layer encryption. git-LFS is refused on end-to-end-encrypted projects. A binary that must be encrypted at rest belongs on the mounted drive, not in LFS.
Stored on GitHub's platform under GitHub's own security controls. See GitHub's docs for details.
Exit path
✓
git lfs fetch --all, then git lfs push --all to any other LFS server. Stock git-lfs, no Swarmfile software installed.✓The same stock git-lfs commands.
`git clone` of the project
◐
git clone swarmfile://<org>/<project> works today for projects with git view enabled, through the git-remote-swarmfile helper the desktop installers include. Fetch and --depth shallow clones work; pushing through git isn't built.✓It's a full git host: clone, push, shallow clones, the lot.
Where Swarmfile is stronger today
- Big objects, resumable. The swarmfile-lfs transfer agent pushes objects up to 256 GiB in content-addressed chunks, and an interrupted push picks up where it stopped. Stock git-lfs keeps working for everything up to ~100 MB.
- Downloads are never metered. Egress is free and unlimited on every plan, so a build farm or a CI matrix pulling the same assets on every run doesn't grow the bill. You pay for storage, like any other project content.
- The same bytes on a drive. Reflect pushed objects onto the project's mounted drive, and artists who never touch git open them in their own apps, streaming only the ranges they read. Deduplication spans both surfaces, so it isn't stored twice.
- One lock for git and the drive. A `git lfs lock` on a path that also lives on the drive is the same lock a desktop user takes, so a file can't be checked out twice by two routes.
- Walk away with stock tools. `git lfs fetch --all` pulls every version back out with no Swarmfile software installed; point lfs.url anywhere else and push. The exit is the standard one.
Where GitHub is stronger today
- One place for code, pull requests, Actions and LFS. Nothing to wire up, and no second endpoint in .lfsconfig. If your large files fit GitHub's limits and its billing works for you, that simplicity is worth a lot.
- No second vendor. One contract, one bill, one set of permissions and credentials. Pointing LFS at Swarmfile means a project-scoped credential per clone and another account to administer.
- The ecosystem. Every tool, integration and CI recipe already assumes GitHub. Ours work with stock git-lfs, but the defaults assume GitHub.
- A full git host. Push and everything else a git host does. Swarmfile's `git clone swarmfile://` covers clone and fetch (shallow included), for projects with git view enabled.
- No encryption caveat to read. On Swarmfile, objects uploaded directly by stock git-lfs (and 64 MiB+ uploads through the desktop app's built-in agent) skip application-layer encryption, and end-to-end-encrypted projects can't use LFS at all. We'd rather you know that up front.
Keep GitHub. Move the big files.
If your binaries fit GitHub’s limits and its LFS billing works for you, stay put. If you’re hitting the per-file ceiling or paying for every CI download, point lfs.url at Swarmfile; the setup is a config change, not a new workflow.