This error occurs when your GitLab namespace (user or group) has exceeded its storage quota. Git push operations are blocked until you reduce storage usage or purchase additional capacity. Free tier namespaces have a 10 GiB limit.
The error "remote: GitLab: Namespace storage limit has been reached" means your GitLab namespace has consumed all available storage quota and has been placed in a read-only state. When this happens, you cannot push new commits, upload artifacts, or add any data to repositories within that namespace. On GitLab.com, storage is allocated at the namespace level—meaning the limit applies to all projects combined under your user account or group. Free tier namespaces receive 10 GiB of storage for Git repositories and Large File Storage (LFS) combined. Premium and Ultimate tiers have more generous limits but still enforce a 500 GiB maximum per project. When you hit this limit, GitLab actively blocks `git push` operations at the remote server level, which is why you see the error after your local Git client attempts to upload commits.
First, identify what's consuming your storage:
# In GitLab UI:
1. Go to your project or group
2. Navigate to Settings > Usage Quotas
3. Select the Storage tab
4. Review the breakdown by storage typeFor groups, you'll see storage used by all projects combined. The breakdown typically shows:
- Repository: Git history and files
- LFS Objects: Large files tracked with Git LFS
- Artifacts: CI/CD job artifacts
- Registry: Container images
- Packages: Package registry files
- Wiki: Wiki content
- Snippets: Code snippets
Note that storage calculations update approximately every 90 minutes, so recent deletions may not reflect immediately.
If your repository has grown large due to accidentally committed large files:
# Check which files are largest in your repo history
git rev-list --objects --all | \
git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
sed -n 's/^blob //p' | \
sort -k2 -n -r | \
head -20
# Use git filter-repo to remove large files (DESTRUCTIVE - backup first!)
pip install git-filter-repo
# Remove a specific file from all history
git filter-repo --path path/to/large/file --invert-paths
# Remove files over a certain size (e.g., 50MB)
git filter-repo --strip-blobs-bigger-than 50MWarning: History rewriting requires force-pushing and affects all collaborators. Coordinate with your team before proceeding.
After cleaning, you'll need to force push:
git push origin --force --all
git push origin --force --tagsIf Git LFS is consuming significant storage:
# List LFS files and their sizes
git lfs ls-files -s
# Check total LFS usage
git lfs ls-files -s | awk '{sum += $1} END {print sum/1024/1024 " MB"}'
# Identify large LFS files
git lfs ls-files -l | sort -k3 -n -r | head -20To remove LFS files from tracking:
# Untrack specific file patterns
git lfs untrack "*.psd"
git lfs untrack "*.zip"
# Remove LFS files from history (careful!)
git filter-repo --path-glob '*.psd' --invert-pathsIn GitLab, go to Settings > Repository > Repository cleanup to remove unreferenced LFS objects after history rewriting.
CI/CD artifacts often accumulate and consume significant storage:
# In GitLab UI:
1. Go to Build > Artifacts (or CI/CD > Artifacts in older versions)
2. Sort by size and review large artifacts
3. Delete artifacts that are no longer neededTo prevent future buildup, set artifact expiration in your .gitlab-ci.yml:
job_name:
script:
- build_command
artifacts:
paths:
- build/
expire_in: 1 week # Automatically deleted after 1 weekYou can also bulk-delete artifacts using the GitLab API:
# Delete all artifacts older than a certain date
curl --request DELETE --header "PRIVATE-TOKEN: <your_token>" \
"https://gitlab.com/api/v4/projects/<project_id>/artifacts"If using GitLab Container Registry, old images can consume significant space:
# In GitLab UI:
1. Go to Packages & Registries > Container Registry
2. Review image tags and their sizes
3. Delete old or unused tagsSet up automatic cleanup policies:
# In GitLab UI:
1. Go to Settings > Packages and registries > Cleanup policies
2. Enable cleanup policies
3. Configure rules for automatic tag deletionExample cleanup policy settings:
- Keep the most recent 5 tags
- Remove tags older than 90 days
- Keep tags matching release patterns (e.g., v*, release-*)
If you need more storage and can't reduce usage further:
# Purchase storage units:
1. Go to Settings > Usage Quotas
2. Click "Purchase more storage"
3. Each storage unit provides 10 GiB for $60/yearStorage units are purchased at the namespace level and apply to all projects within that namespace.
Alternatively, consider:
- GitLab for Education: Free for qualifying educational institutions
- GitLab for Open Source: Free for qualifying open source projects
- GitLab for Startups: Free tier for qualifying startups
These programs offer expanded limits without cost.
If storage limits are a recurring problem, GitLab Self-Managed offers unlimited storage:
# GitLab Self-Managed benefits:
- No storage quotas (limited only by your infrastructure)
- Full control over server resources
- Can use GitLab CE (Community Edition) for free
- Better for organizations with large storage needsOptions for self-hosting:
- On-premises servers: Full control, your own hardware
- Cloud VMs: AWS, GCP, Azure with GitLab Omnibus
- Kubernetes: GitLab Helm charts for container deployment
This requires more operational overhead but eliminates storage constraints entirely.
If you need to push urgent changes while resolving storage issues:
# Create a new repository in a different namespace (if available)
# Or use a temporary external Git host
# Add as a new remote
git remote add temp-origin [email protected]:other-namespace/repo.git
# Push your changes
git push temp-origin main
# Later, after fixing storage, sync back
git push origin main
# Remove temporary remote
git remote remove temp-originThis is a temporary measure—resolve the underlying storage issue as soon as possible.
### Understanding GitLab Storage Calculations
GitLab calculates storage using binary units (1024 multiples):
- 1 KiB = 1,024 bytes
- 1 MiB = 1,024 KiB
- 1 GiB = 1,024 MiB
Storage is calculated at the namespace level, meaning all projects under a user account or group share the same quota. This differs from per-project limits.
### Storage Components Breakdown
| Component | What It Includes |
|-----------|-----------------|
| Repository | Git objects, packfiles, loose objects |
| LFS | Large File Storage objects |
| Artifacts | CI/CD job artifacts, test reports |
| Registry | Container images and layers |
| Packages | npm, Maven, PyPI packages |
| Wiki | Wiki pages and attachments |
| Snippets | Project and personal snippets |
### Free Tier Limits (GitLab.com)
- 10 GiB per project for repository + LFS
- 500 GiB maximum per project (hard limit for all tiers)
- Project becomes read-only when limit exceeded
### Premium/Ultimate Limits
- Higher namespace quotas
- Same 500 GiB per-project hard limit
- More generous artifact retention
### Fork Storage Efficiency
GitLab applies cost factors to forks:
- Public forks of public projects: Lower storage cost
- Private forks: Full storage cost
- Forks share object storage with upstream when possible
### Notification Thresholds
GitLab sends notifications at:
- 70%: Email to namespace owners
- 75%: In-app banner appears
- 85%: Email warning
- 95%: Critical warning email and banner
- 100%: Read-only mode, push blocked
### API Methods for Storage Management
# Get project storage statistics
curl --header "PRIVATE-TOKEN: <token>" \
"https://gitlab.com/api/v4/projects/<id>/statistics"
# Get namespace storage
curl --header "PRIVATE-TOKEN: <token>" \
"https://gitlab.com/api/v4/namespaces/<id>"
# Trigger repository cleanup
curl --request POST --header "PRIVATE-TOKEN: <token>" \
"https://gitlab.com/api/v4/projects/<id>/housekeeping"### Repository Housekeeping
GitLab automatically runs housekeeping, but you can trigger it manually:
# In GitLab UI:
Settings > Repository > Housekeeping > Run housekeepingThis runs git gc and git repack to optimize storage.
### Using Repository Cleanup (Requires Push Access)
For removing sensitive or large files from history:
1. Create a list of files to remove (paths or SHA objects)
2. Settings > Repository > Repository cleanup
3. Upload the file with objects to remove
4. GitLab rewrites history server-sideThis is safer than local history rewriting as it handles all refs properly.
fatal: bad object in rev-list input
Git rev-list encounters bad or invalid object
fatal: Out of memory, malloc failed during pack operation
Out of memory during Git pack operation
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server
fatal: unable to access: Proxy auto-configuration failed
How to fix 'Proxy auto-configuration failed' in Git
fatal: unable to access: Authentication failed (proxy requires basic auth)
How to fix 'Authentication failed (proxy requires basic auth)' in Git