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.
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.
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:
| Storage | Size |
|---|---|
| Compressed in Git today | 169 MB |
| Uncompressed originals | 324 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.
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.
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)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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 LFS | 274 |
|---|---|
| LFS objects stored for them | 461 |
| Files with more than one version stored | 120 |
| Storage taken by superseded versions | 50.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:
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.