Bitbucket free plan repo size and user limits you need to know
By Jordan Ellis Published 7 min read
On this page (8 sections)
- The short version
- Bitbucket repo size limit for free plan is 2GB per repository
- How many users allowed on Bitbucket free plan
- What counts toward your repo size and what does not
- What happens when you hit the limit
- Common mistakes teams make before they hit the wall
- How to choose and stay inside the free plan safely
- Questions people still ask
In short: Bitbucket repo size limit for free plan is 2GB hard limit per repository, with warnings starting around 1GB. The free plan also caps you at 5 users total, including you. Exceed either limit and pushes start to fail.
Part of our guide on workspace admins on slack
Most teams hit Bitbucket's 1GB warning long before they expect it — because one video file counts more than a year of code.
| Free users | 5 total users |
|---|---|
| Repo hard limit | 2 GB per repo |
| Warning threshold | 1 GB per repo |
| Workspace cap | No single cap, per-repo |
| File size limit | 2 GB per file push |
| LFS on free | 1 GB storage included |
The short version
- Free plan = 5 users max and ~2GB per repo hard cap, 1GB soft warning.
- Size is counted per repo, not per workspace: large files hit the cap fast.
- Exceed 2GB and Bitbucket blocks pushes until you shrink the repo.
- Use Git LFS or split repos before you hit 1GB to stay safe.
- Need more users or space? Standard plan lifts both limits for a small team.
Bitbucket repo size limit for free plan is 2GB per repository
The common mistake is thinking the limit is per workspace. It is not. Bitbucket measures 2 GB per repository on the free plan, with a 1 GB soft warning that tells you to clean up soon.
You see the warning in the repo settings when you cross about 1 GB. Pushes still work at that point. Cross 2 GB and Bitbucket blocks new pushes until you reduce size. That block is the hard limit.
This figure depends on what you count. Bitbucket counts the .git history, not just the files you see today. A 300 MB video deleted last month still counts until you rewrite history.
If you store binaries, datasets, or build artifacts in Git, you hit 1 GB fast. Text code rarely does. A team writing only code can stay under 1 GB for years. One designer committing PSDs can blow it in a week. The other half of this decision is grain ai cost options for small firms.
- Soft warning: ~1 GB per repo – email and banner, pushes still allowed
- Hard block: 2 GB per repo – pushes rejected until you shrink it
- Absolute docs limit: 4 GB cited for some workspaces, but free enforces at 2 GB
| What you push | Counts toward 2GB? | Why it matters |
|---|---|---|
| Source code and text | Yes | Small, grows slowly |
| Images, PSDs, zips committed directly | Yes, heavily | Fills repo fast |
| Git history and old commits | Yes | Deleting a file does not free space |
| LFS-tracked files | No, separate LFS quota | Keeps repo small but uses LFS storage |
How many users allowed on Bitbucket free plan
You get 5 users total on the free plan. That includes you, the workspace owner. Invite a sixth person and Bitbucket asks you to upgrade.
This is a workspace limit, not a per-repo limit. Five people can access all repos in that workspace on free. You cannot work around it by adding users to one repo only.
Billable users are anyone with access to private repos. Read-only or guest roles still count if they can see code. Remove inactive users and you free a seat immediately. If that sounds like your situation, read up on hybrid team collaboration stack for 15 people across 4 timezones next.
Teams with contractors often trip here. You hire two freelancers for a month and suddenly you have seven users. Plan for that spike before you invite them.
- Free: 5 users max per workspace
- Standard: starts above 5 users with per-user billing
- Count includes admins, developers, and viewers with access
| Plan | Users included | Repo limit |
|---|---|---|
| Free | 5 | 2 GB hard |
| Standard | 6+ (paid per user) | 4 GB |
| Premium | 6+ (paid per user) | 4 GB+ with controls |
What counts toward your repo size and what does not
Bitbucket measures the size of the Git object database for that repo. Every commit, branch, and merge stays in that count. Cloning with --depth 1 does not change the server size.
Large files committed directly are the usual culprit. A single 500 MB dataset doubles a 500 MB codebase. Even if you delete it next commit, Git keeps it in history.
Git LFS moves large blobs out of the repo. The repo then stores a small pointer file. That keeps you under 2 GB, but LFS has its own quota. Free includes about 1 GB of LFS storage.
Artifacts, node_modules, and build folders should never be committed. Add them to .gitignore on day one. They bloat size and they rebuild from source anyway.
- Counts: all commits, branches, tags, and files committed directly
- Does not count: LFS files (counted separately), workspace total is sum of repos
- Check size: Repository Settings > Repository details > Size
- Keeps single source of truth if you stay small
- LFS option avoids history rewrites
- History never shrinks without force push
- LFS quota is small on free
What happens when you hit the limit
At about 1 GB you get a warning banner and email. You can keep pushing. Treat this as your deadline to clean up. Do not ignore it.
At 2 GB Bitbucket rejects pushes with an error about repository size. Pulls and clones still work. You must shrink the repo before anyone can push again.
Shrinking is not deleting the file in a new commit. You must rewrite history with git filter-repo or BFG Repo-Cleaner, then force push. That is disruptive for a team.
LFS has a similar block. Exceed the 1 GB LFS allowance and LFS pushes fail. You then buy more LFS storage or move files out. Storage and repo size are separate blocks.
- Check size in Bitbucket: open repo > Settings > Repository details
- Find large files: run
git rev-list --objects --all | sort -k2locally - Move large files to LFS: install git lfs, track with
git lfs track "*.psd" - Rewrite history if needed: use BFG to strip old large files, then force push
- Verify: push again and confirm size dropped below 1GB
Common mistakes teams make before they hit the wall
Myth: deleting a large file fixes the size. Fact: Git keeps every version. You deleted the reference, not the blob. Size stays until history is rewritten.
Myth: zipping files saves space. Fact: Git compresses already. A 200 MB zip still counts as 200 MB. LFS or external storage is the fix, not archives.
Myth: free means unlimited private repos. Fact: you get unlimited repos, but each is capped at 2 GB and the workspace is capped at 5 users. Many small repos beat one giant monorepo here.
- Mistake: committing
node_modules– fix: add to.gitignoreand use npm ci - Mistake: storing videos in Git – fix: use LFS or cloud storage link
- Mistake: waiting until 2GB to act – fix: clean at 1GB warning
How to choose and stay inside the free plan safely
You can stay on free if you have 5 users or fewer and you keep each repository under 1 GB. That is the practical safe line, not 2 GB. Leave headroom for history.
Split by boundary, not by folder. Put app, docs, and assets in separate repos. A monorepo that holds code plus marketing video will hit the cap even if code is tiny.
Use LFS only for files you must version. For everything else, link to Drive, S3, or Artifactory. Version the pointer or URL, not the blob. You save both repo size and LFS quota.
If you expect a sixth teammate in the next three months, budget for Standard now. The cost of rewriting history under pressure is higher than a few seats. Measure twice.
- Stay safe: keep each repo <1 GB, total users ≤5
- Split repos: code in one, large assets in LFS or external storage
- Automate: add
.gitignorefor builds and block large pushes with a pre-push hook
- Free stays free if you enforce size hygiene
- Small repos clone faster for remote staff
- Needs discipline on LFS and ignores
- Force-push cleanups disrupt the team
Free works for tiny teams that keep repos lean; grow past 5 users or 1GB per repo and Standard is the sensible step.
Questions people still ask
Is the 2GB limit per workspace or per repository?
Per repository. You can have many repos on free, each up to 2GB hard limit. Workspace has no single storage cap, but users are capped at 5.
What happens if I exceed 1GB but stay under 2GB?
You get warnings by email and in the UI. Pushes still work. Use that window to move large files to LFS or rewrite history before you hit 2GB.
Does Git LFS increase my repo size limit?
It keeps repo size small by storing large files outside Git. The repo then holds pointers. LFS storage itself is limited to about 1GB on free, then you need to pay.
Can I pay for more storage and stay on 5 users?
You can buy extra LFS storage without adding users, but you cannot lift the 2GB per-repo hard limit without moving to Standard for more headroom and controls.
How do I check my current repo size?
In Bitbucket Cloud, open the repository, go to Repository settings, then Repository details. Size is shown there. Locally, git count-objects -vH gives an estimate.