Bitbucket: "Your LFS push failed because your account is out of file storage"
Git LFS files are kept apart from the repository, and each Bitbucket plan includes a fixed amount of storage for them: 1 GB on Free, 5 GB on Standard, 10 GB on Premium, and 5 GB on academic and community plans (Atlassian's Storage policy for Git LFS). Bitbucket refuses an LFS push that would go over it, with the line above (as quoted in community questions since 2020). On Standard and Premium, storage over the allowance is added instead, 100 GB at a time for $10 a month.
The workspace's plan, not yours
The storage belongs to the workspace in the repository's URL (bitbucket.org/<workspace>/<repo>). In the 2020 question above, the person had bought Standard, but Atlassian's support found that the repository's workspace was still on Free. Check Workspace settings › Plan details of that workspace.
Free has two different 1 GB limits
- Git LFS file storage, 1 GB: this page. A push of LFS files fails with the line above.
- Workspace storage, 1 GB: all the workspace's repositories together, without LFS. Since May 29, 2025, a Free workspace over it is put in read-only mode, and git says
Your workspace has exceeded the 1 GB limit and has been placed in read-only mode.(Bitbucket's size limits).
The plan page shows both, and they are easy to mix up. In a June 2025 community question, the workspace was read-only while the page said "0 MB of file storage used – 1 GB remaining". Atlassian's answer: that line is the LFS storage; the workspace limit is the one labeled "workspace storage".
What counts
Bitbucket counts the total size of the LFS files stored, in GB (Manage your plan and billing). That is every version ever pushed, not only the current one: a 300 MB file changed and pushed four times uses 1.2 GB. To see the versions in your clone's history, with Git LFS 3.7 on October 30, 2026 (one 3 MB file, committed three times):
git lfs ls-files --all --size 2e7639338e * design.psd (3.1 MB) d9471aaa39 * design.psd (3.1 MB) bd63248c71 * design.psd (3.1 MB)
Without --all, it showed one line: only the file in the current commit. To see the usage on Bitbucket, workspace admins open Workspace settings › Git LFS, which also shows how much each repository uses.
Free the space
A repository admin opens Repository settings › Git LFS, which lists all the LFS files of the repository, and deletes files from the actions menu (Atlassian's Use Git LFS with existing Bitbucket repositories). Before you do:
- It can't be undone. Back up the files first.
- The pointers stay in the history. Checking out a branch, tag or commit that points to a deleted file fails with a download error (the 404 below).
- Rewriting history doesn't free the space. Atlassian says that with BFG only the pointers in the repository are removed; the LFS files themselves stay stored until you delete them on the Git LFS page.
To check out old commits after that, Git LFS can leave the pointer text in place of a file it can't download: git config lfs.skipdownloaderrors true, or GIT_LFS_SKIP_DOWNLOAD_ERRORS=1 for one command. Commands then report success even when a download failed, which can mislead scripts and builds.
Other LFS errors
- HTTP 413, as in
LFS: Client error: https://api.media.atlassian.com/upload/… from HTTP 413: one file is larger than 10 GB (Atlassian's HTTP 413 article). The storage policy says there is no limit on the file size, but this article names 10 GB per file. Compress the file or split it. - EOF while uploading a large file (
http: Put https://media-api.atlassian.io/upload/…: EOF): the upload timed out. Push over HTTPS instead of SSH, and raise the time limit withgit config lfs.activitytimeout 60(Atlassian's Troubleshoot Git LFS in Bitbucket). - 404, on clone or checkout (
[404] Object does not exist on the server): the pointer is in the repository, but the file is not in Bitbucket's store: it was never uploaded, it was deleted on the Git LFS page, or the repository is a fork. Bitbucket does not copy LFS files to a fork, and merging a pull request from a fork doesn't copy them into the original repository either (Current limitations for Git LFS). For a fork, copy them from the original:git remote add old-origin <original> git lfs fetch --all old-origin git lfs push --all origin
October 26 and December 3, 2026
Git LFS storage is one of the four usage meters that Atlassian is moving to Atlassian Administration, with build minutes and the two Packages meters (Manage your plan and billing):
- Monthly plans, rolling out from October 26, 2026: the allowances are pooled for the whole organization instead of each workspace. With one workspace, nothing changes in practice.
- Annual plans, from December 3, 2026: so far they weren't billed for LFS storage over the plan's limits. From then on, storage over the allowance is billed at the published rate ($10 per 100 GB), pooled for the organization.
Billing admins see the usage under Usage → Meters in Atlassian Administration. If an annual workspace has piled up LFS storage over its allowance, December 3 is the date to clean it up by.
Bitbucket pull requests in IntelliJ IDEA
Pull Request Inbox for Bitbucket, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the pull requests waiting for your review, with diffs and discussions, inside the IDE. A file kept in Git LFS shows as empty in its diffs: Bitbucket's API sends LFS files to Atlassian's media host, and the plugin doesn't follow it there with your token. The review inbox, diffs and discussions are free; approving, commenting and merging are Pro (US$1.50 a month, with a 30-day trial).
Get it on JetBrains Marketplace
Bitbucket and Atlassian are trademarks of Atlassian; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by Atlassian or JetBrains.
More: "Repository is over the size limit (4 GB)" · "Your push failed because the account has exceeded its user limit" · Bitbucket pull request plugins for IntelliJ IDEA, compared · 日本語