GitHub File Size Limits Explained for Teams and Copilot

GitHub hard-blocks any single file larger than 100 MiB from regular Git history unless you use Git Large File Storage (Git LFS). It also warns when a file exceeds 50 MiB, and the web UI refuses uploads larger than 25 MiB. Those three numbers, documented in GitHub's guide to large files, explain most failed pushes teams hit when model checkpoints, media, or agent-generated archives land in a repo that also powers GitHub Copilot and CI.

GitHub enforces hard and soft size limits on repository files so clones, pushes, and hosting stay performant. Beyond those caps, you need LFS, Releases, or external distribution. Thinking of the limit as "100 MB max" is incomplete. The full picture is a stack of thresholds that fire at different moments:

• 25 MiB: Maximum file size when you add a file through the GitHub browser UI.
• 50 MiB: Git still accepts the push, but you get a warning. Performance cost starts here.
• 100 MiB: Hard block for normal Git objects. The push is rejected without LFS.
• Repository size (recommended): Keep repos ideally under 1 GB, and strongly under 5 GB, so clones stay manageable.
• On-disk repository size (guidance): GitHub's repository limits docs recommend staying near or under 10 GB for the compressed .git size.
• Push size: Enforced at 2 GB per push.
• Single Git object: Recommended under 1 MB for best health; enforced at 100 MB.

GitHub uses MiB in the large-files docs. Teams usually call this the "GitHub 100MB limit." Leave a small buffer under each threshold so a file that is "about 100 MB" does not trip the hard block.

These rules protect full Git object history. A 120 MiB binary committed once is not a one-time cost. Every clone, fetch, and fork pays for it, and rewrites later are painful. That is why GitHub steers large binaries toward LFS, Releases, package registries, or a file-sharing layer outside the repository. A coding agent or GitHub Copilot session that dumps a weight file, scraped zip, or long video into the working tree hits the same 100 MiB wall on the next git push. Treat the limit as a design constraint, not a surprise error.

Helpful references: Fast.io Workspaces, Fast.io Collaboration, and Fast.io AI.

When a push fails for size, GitHub is almost always rejecting a single blob that exceeds 100 MiB, not the whole repository. The error typically names the path and size. Common sources: a dragged-in PDF or ISO, a build artifact under dist/, a dataset an agent downloaded into the repo root, or an older commit that already contains the blob so tip-only fixes fail.

Confirm the oversized object

From the repository root:

git rev-list --objects --all \
  | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \
  | awk '/^blob/ {print $3, $4}' \
  | sort -n \
  | tail -20

That lists the largest blobs. Anything above ~104857600 bytes (100 MiB) is your hard block. Before the next commit, also scan the working tree:

find . -type f -size +50M -not -path './.git/*'

Recent commit, not yet pushed

If the giant file is only in the last unpushed commit, GitHub's recovery path is:

1. git rm --cached path/to/GIANT_FILE (keeps the file on disk)
2. git commit --amend -CHEAD
3. git push

Amending matters. A new commit that only deletes the file still leaves the blob in history, so the push can still fail.

Older commits already on the remote

Once the object is on GitHub, remove it from history with git filter-repo (preferred) or a careful interactive rebase, then force-push with a coordinated team plan. Filter operations rewrite SHAs. Coordinate open branches, and keep a backup clone.

Files between 50 MiB and 100 MiB may push with a warning. That is not a green light. Repeated large binaries slow every clone, GitHub Actions runner, and machine user. Browser uploads hit a separate 25 MiB cap; use a local git push for larger tracked files and still respect the 100 MiB Git object limit.

When you need a large file next to a project, GitHub offers two first-party paths, plus patterns that keep binaries out of Git entirely.

Git Large File Storage (Git LFS)

Git LFS stores a small pointer in the repository and keeps the real content in LFS storage. Clones pull pointers first, then fetch LFS objects as needed. That preserves history links without stuffing full binaries into every packfile.

Per-file LFS maximums depend on plan (GitHub docs):

• GitHub Free / Pro: 2 GB per file
• GitHub Team: 4 GB per file
• GitHub Enterprise Cloud: 5 GB per file

Files above 5 GB are rejected by Git LFS. LFS also has bandwidth and storage quotas. On Free and Pro accounts, included LFS bandwidth and storage are 10 GiB each. Team and Enterprise Cloud include 250 GiB each. Exceeding free quota without a payment method can block new LFS pushes or LFS downloads for the rest of the billing period, depending on bandwidth vs storage exhaustion.

LFS fits when developers need versioned large assets at known repo paths and sizes stay under your plan max and budget. It is weaker when assets rewrite often (each full-file push burns storage again), when recipients are clients who should not clone, or when you are shipping one-off installers to non-developers.

GitHub Releases for binaries

GitHub recommends

Releases when you need to distribute large binaries with a project. Releases package notes plus downloadable assets. Total release bandwidth is not capped the same way Git objects are, but each individual release file must stay under the Git LFS maximum for your plan. Use Releases for versioned installers and tagged datasets, not as a general team drive.

Package managers and external stores

GitHub steers teams away from stuffing dependencies and large databases into Git. Prefer npm, Maven, Bundler, container registries, or object storage (S3, GCS, Azure Blob) for bulk data. For SQL dumps, use a file sharing service rather than the repo.

A practical layout: source and configs in Git; build artifacts in Releases or a registry; working datasets, media, and client packs in object storage or a collaborative workspace. Object storage solves capacity. It does not solve handoff: permissions, expiring links, searchable docs, or a place where GitHub Copilot-adjacent automation and people share the same files. That is the gap most "just use LFS" pages leave open.

Most articles stop at "enable LFS." Teams building with agents, GitHub Actions, and client delivery need a decision tree.

Choose plain Git (no LFS) when every file is text-ish, well under 50 MiB, and belongs in code review. Config, source, prompts, and small fixtures stay here.

Choose Git LFS when large binaries must version with the repository for developers who clone the project. Example: a 180 MiB sample media pack that the build system expects at a fixed path, and every engineer needs the same revision.

Choose GitHub Releases when you are shipping a versioned download to users or CI that pins a tag. Example: a 1.2 GB offline installer attached to v2.4.0.

Choose object storage (S3 or similar) when pipelines need cheap bulk storage, lifecycle rules, and programmatic access, and humans rarely browse the files.

Choose a collaborative workspace when the problem is handoff, not just storage: agents produce large outputs, humans review them, clients download selected packs, and you need permissions, version history, and searchable context without forcing a git clone.

A concrete agent flow: keep application code on GitHub so GitHub Copilot and PR review stay close to source; write heavy outputs (renders, exports, datasets, PDFs) to a workspace path, not ./artifacts inside the repo; share that folder with branded Send or Exchange links for clients, or keep it internal with folder-level permissions; commit only small pointers (manifest JSON, checksums, stable URL).

Alternatives first, then the workspace layer:

• Local disk or NAS: Fine for one machine. Weak for remote agents, CI, and clients.
• Google Drive / Dropbox / Box: Familiar for people. Weaker for agent-native access and MCP tooling.
• Amazon S3: Strong bulk store and lifecycle control. You still build sharing UI, permissions, and search.
• Fast.io: An intelligent workspace where agents and humans share the same files. Enable Intelligence Mode so uploads are indexed for semantic search and citation-backed chat. Use chunked uploads for large files (plan-dependent, up to 40 GB), per-file version history, branded shares for client delivery, and a consolidated MCP toolset over Streamable HTTP at /mcp (legacy SSE at /sse). Ownership transfer lets an agent-built org move to a human without losing structure.

Fast.io is not a Git host. It fills the lane GitHub docs point at when large databases and bulky distribution should live on a file sharing service. For teams mixing GitHub Copilot-assisted coding with agent pipelines, that split keeps the repo fast and working files usable. Plans: Solo $29/month, Business $99/month, Growth $299/month, each with a 14-day free trial that requires a credit card.

Keep large agent files out of Git history

Use a shared Fast.io workspace for datasets, exports, and client packs while GitHub stays lean for source and GitHub Copilot. MCP-ready access, version history, and branded shares, starting with a 14-day free trial.

Start 14-Day Trial

GitHub Copilot works best when the repository stays a code workspace, not a dump for every generated asset. Official GitHub docs do not claim Copilot bypasses file size limits. The limits apply to the repository and Git protocol regardless of which editor or assistant wrote the file. Treat Copilot, other coding agents, and human contributors as equal sources of oversized commits.

Patterns that keep Copilot-assisted repos healthy

• Ignore heavy paths by default: put data/, models/, renders/, *.gguf, and export directories in .gitignore unless you track them with LFS on purpose.
• Write agents to external storage. If automation produces a 500 MiB report pack, land it in object storage or a workspace, then commit a short summary and link in the PR.
• Prefer shallow CI clones. GitHub notes that shallow clones cost less than full clones when read volume is high.
• Use package managers for dependencies instead of vendoring giant trees that push monorepos past the 1 to 5 GB comfort zone.
• Run git-sizer (the tool GitHub points to for repository analysis) when clone times degrade.

Agent and human handoff without bloating Git

Keep code and prompts on GitHub for review, history, and Copilot context. Put runtime files in a shared workspace with Intelligence enabled so teammates can ask which export holds a given document without downloading every zip. Deliver to clients with time-bound or revocable shares instead of repo collaborator seats. Audit code through Git history and workspace activity for the file side.

Fast.io supports that split with workspaces, hybrid search (full-text plus semantic), Metadata Views when you need structured fields from PDFs or invoices, webhooks for reactive steps, and ownership transfer when an agent finishes setup and a human takes the org. Pair that with GitHub for source and avoid the false choice between stuffing everything into LFS and scattering files across chat attachments.

Quick reference for a file larger than 100 MiB: Git LFS if developers must version it with source; a GitHub Release asset if it ships with a tag; object storage for training or bulk pipelines; a collaborative workspace when people must review, search, or deliver it; history rewrite plus re-homing if it was committed by accident. Recovery is mechanical. The architecture choice is what stops the next outage.

Use this as a runbook the next time size limits appear in CI or on a developer laptop.

Immediate response: capture the path and size from the rejection, confirm whether the commit is unpushed, move the large file to a local backup outside the repo, remove it from history (amend for tip-only, filter-repo for deeper history), push the cleaned history, and verify a fresh clone.

Prevention in the repo: add a pre-commit check that rejects staged files over about 40 MiB unless the path is LFS-tracked; document in the README where large artifacts should go; keep LFS rules narrow (*.psd, *.mp4) so random zips do not burn quota; watch LFS storage and bandwidth in GitHub billing before release weeks.

Prevention in agent workflows: give agents a dedicated output workspace instead of write access to the monorepo root; store manifests in Git and binaries elsewhere; prefer chunked uploads and share links for client delivery over emailing multi-gigabyte zips; index docs where humans and agents can query them rather than re-cloning media-heavy repos for context.

Stay under 100 MiB per normal object, treat 50 MiB as a smell, keep repositories lean, and put large files on the path that matches the audience: LFS for developer-coupled assets, Releases for versioned downloads, object storage for bulk pipelines, and a shared intelligent workspace when agents, teammates, and clients need the same files without a git clone.