Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Does Git LFS storage count toward the 1 GB workspace limit, and can LFS garbage collection be run?

AnToine van Maarle
Contributor
September 7, 2026

We are on a Free plan workspace and recently started seeing this warning on push:

WARNING This workspace is getting close to the 1 GB size limit

Before we decide how to act on it, I would like to get two things straight, because the documentation does not answer them and the answer changes what we should do.

What we measured

Our main repository, with all refs fully repacked, is about 198 MB. Roughly 164 MB of that is a set of 186 binary files (DLLs, EXEs and installers) that ship with our desktop application.

We also have one branch that is no longer used but still carries Git LFS pointers from an earlier migration attempt. The LFS objects behind it are around 173 MB.

Adding up every repository in the workspace that we can measure locally gets us to roughly 331 MB, so we cannot account for the remaining part of the 1 GB from our side.

Questions

1. Does Git LFS storage count toward the 1 GB workspace storage limit on the Free plan?

The plan pages list a separate LFS allowance per plan, which suggests LFS is tracked separately, but neither Storage policy for Git LFS with Bitbucket nor What are the repository and file size limits? states this explicitly. We would like a definitive answer, because it decides the next question.

2. Would migrating our active branches to Git LFS actually reduce our workspace usage?

This is where we are stuck. Git stores those binaries compressed, and they compress well:

StorageSize
Compressed in Git today169 MB
Uncompressed originals324 MB

As far as we understand, Git LFS stores the original file, uncompressed. So if LFS does count toward the workspace limit, moving these files to LFS would nearly double what they consume rather than reduce it.

Is that correct? We would rather not carry out a history rewrite across three release branches only to end up worse off.

3. Can you run garbage collection on the LFS storage of a repository?

We understand that deleting the branch that references the old LFS objects does not free the storage, and that Bitbucket Cloud has no self-service garbage collection for LFS. If you can run it for us, we would like to request that for the unused branch described above. Please let us know what you need from us.

4. Where can we see the storage breakdown per repository for a workspace, and does that figure include LFS?

We can see a total, but we would like to know which repository accounts for what, and whether the number shown includes LFS objects or only the Git repository itself.

Thanks in advance.

1 answer

1 vote
Viswanathan Ramachandran
Community Champion
September 7, 2026

Hi @AnToine van Maarle 

Git LFS storage is tracked separately from standard repository storage. You cannot manually trigger remote Garbage Collection for Git or LFS. To answer your questions

1. Does LFS count toward the 1 GB workspace limit?

No. Standard repository storage and Git LFS have completely separate 1 GB quotas on the Free plan.

2. Does migrating active branches to LFS reduce workspace usage?

Not automatically. Simply tracking new files with LFS leaves old large files in your Git history. You must rewrite repository history (using tools like BFG Repo-Cleaner) to purge historical binaries and reduce standard storage.

3. Can you run LFS garbage collection?

Locally, yes; remotely, no. Run git lfs prune  locally to free space on your machine. For clearing unreferenced remote LFS space often requires a quick request to Atlassian Support.

4. Where is storage breakdown shown, and does it include LFS?

No, LFS is listed separately.

  • Standard Repo Size: View under Repository settings > Repository details (or Workspace settings > Plan details).

  • LFS Size: View under Workspace settings > Git LFS.

 

Please note: regarding rewriting history

It is a good practice for local work, but carefully for remote.

  • Local/Unpushed: Excellent practice to clean up messy commits 

  • Remote/Shared: High risk. Rewriting pushed history requires a force push, which can break teammates workflows only do it to clear security leaks or purge large files for LFS migrations.

Ben
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
September 9, 2026

Hi @AnToine van Maarle 

In addition to @Viswanathan Ramachandran response - I can confirm that your workspace is well within the 1GB limit (it's at about 50%).

To clarify - it's not possible for us to run garbage collection against LFS storage.

Please let us know if you have any further questions.

Cheers!

- Ben (Bitbucket Cloud Support)

AnToine van Maarle
Contributor
September 10, 2026

...

AnToine van Maarle
Contributor
September 10, 2026

 

 

Hi Ben,

Thanks for confirming both points.

What we are still stuck on is that LFS storage appears to only ever grow. We measured what is actually stored for our repository over the ten months our history was on LFS:

Distinct files tracked by LFS274
LFS objects stored for them461
Files with more than one version stored120
Storage taken by superseded versions50.2 MB (20%)

That is measured only over the refs in our own clone, so the real figure is higher. A single update of one file, PynxMail.dll, added 13.4 MB that can never be removed.

Our workspace currently uses about 575 MB of the 1 GB LFS quota, and roughly 79 MB of that is no longer referenced by any branch or tag.

We understand this for content that never changes. But the files we would want in LFS are vendor DLLs and redistributable installers that get replaced every few releases — and every replacement adds permanently. That turns the 1 GB quota into a one-way counter.

So, concretely:

  1. When a workspace reaches the 1 GB LFS quota, what are the options? Is deleting and recreating the repository the only way to reset that counter?
  2. Does deleting a repository release its LFS storage, and how soon does that show up?
  3. Is any form of LFS retention or pruning on the roadmap?

We are not asking for an exception — we are trying to decide whether to adopt LFS at all, and the answer to the first question decides it for us.

Thanks,
AnToine

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
PERMISSIONS LEVEL
Product Admin Site Admin
TAGS
AUG Leaders

Atlassian Community Events