GitLab.com Git LFS
- Free allowance
- 10 GiB free storage PER PROJECT on the Free tier, and that 10 GiB explicitly covers 'the project's repository and Large File Storage (LFS)'.
- Verdict
- caveatusable, with a named limit or an unprobed read path
- Cost
- free tier
- Identity
- email?placeholder, not evidence; card unknown, phone unknown
- Binding limit
- noneno named constraint binds
- Evidence
- reported5 sources; a third party said so
- Freshness
- stale on 2026-11-05checked 2026-10-21 (inherited); stale on 2026-11-05
| Free tier | 10 GiB free storage PER PROJECT on the Free tier, and that 10 GiB explicitly covers 'the project's repository and Large File Storage (LFS)'. Premium/Ultimate: 500 GiB per project. CONFIRMED: LFS is IN the quota while containers, packages, build artifacts, snippets, uploads and wikis are OUT. unit GiB; metered on stored-bytes |
|---|---|
| Price | none stated |
| Identity | email (placeholder) not published |
| Egress | Unmetered — GitLab does not bill or publish any LFS bandwidth quota. The only transfer-side control is a rate limit: 'Git LFS requests are subject to authenticated web request rate limits ... 1000 requests per minute per user. Each Git LFS object uploaded or downloaded generates an HTTP request'. |
| Per-object cap | not stated |
| Retention | not stated |
| Interface | rest, git git |
| Tooling | git-lfs. Also Oras-style raw access is not available; LFS is protocol-only. GitLab REST API v4 for project/namespace management (useful for automating project-per-shard). |
| Composes with | 10 GiB per PROJECT, and projects are free and unlimited within a namespace — GitLab's own excess-storage example totals 30 GiB across three projects with no namespace-level cap. 50 projects = 500 GiB, 100 = 1 TiB. This is the cleanest 'trivially repeatable' LFS case because each project is an independent 10 GiB bucket behind the same account, unlike GitHub where the 10 GiB is per account. |
| Reliability | Read-only state is reversible only by purchasing storage, so a blown project is stuck. The 1000 req/min limit bites hard on many-small-files datasets during clone, and GitLab's own docs warn multi-file projects 'may encounter an HTTP rate limit error' in CI. |
Evidence 5
| date | source | what it proved |
|---|---|---|
| 2026-10-21 | docs.gitlab.com/user/storage_usage_quotas/ | 'Only the project's repository and LFS are included in the storage limit. The container registry, package registry, and build artifacts are not included' + 'Each project in a Free tier namespace on GitLab.com has 10 GiB of free storage' |
| 2026-10-21 | docs.gitlab.com/administration/settings/account_and_limit_se | 'It includes repository files and Git LFS objects (even when stored in external object storage), but does not include: Artifacts, Containers, Packages, Snippets, Uploads, Wikis' |
| 2026-10-21 | docs.gitlab.com/rate_limits/git/ | '1000 requests per minute per user' for LFS |
| 2026-10-21 | docs.gitlab.com/user/gitlab_com/ | 'Repository size including LFS | 10 GB'; 'Maximum push size | 5 GiB' |
| 2026-10-21 | gitlab.com/gitlab-org/gitlab.git/info/lfs/objects/batch | probe: POST -> HTTP 200 |
Unknown values 5
$.binding_noteboilerplate$.per_object_cap.notesthe field may be stated in a source that was not read$.per_object_cap.statedthe field may be stated in a source that was not read$.retention.notesthe field may be stated in a source that was not read$.retention.statedthe field may be stated in a source that was not read