Zenodo
zenodo.org · 5 records in Storage · JSON
Records 5
- ★ qualifiesZenodo anonymous download throughput (the fetch-serving question)
Storagefree tieridentity institution?card?limit per-object-capevidence documentedstale on 2026-11-21
- caveatZenodo (CERN)
Storagefree tieridentity emailno cardlimit write-gatedevidence documentedstale on 2026-12-02
- caveatZenodo DOI batching (automatic DataCite minting per record)
Storagefree tieridentity emailno cardlimit request-rateevidence documentedstale on 2026-11-21
- caveatZenodo restricted-access records and secret links (working storage, not only an archive)
Storagefree tieridentity emailno cardlimit per-object-capevidence documentedstale on 2026-11-21
- fails: quotaopenaire graph
Storageidentity email?card?evidence reportedstale on 2026-11-05
- Free allowance
- Each record has a default storage quota of 50 GB, with an unlimited number of records under 50 GB, plus an additional allowance of up to 150 GB to distribute across uploads; no period is stated.
- Verdict
- ★ qualifiesusable as stated; the read path was probed
- Cost
- free tier
- Identity
- institution?placeholder, not evidence; card unknown, phone unknown
- Binding limit
- per-object-cap50 GB per record default; 200 GB absolute ceiling on a single record with the 150 GB allowance pooled in; max 100 files per record (new API: 'a limit of 50GB total in the record (and any given file), and up to 100 files in the record').
- Evidence
- documented13 sources; a first-party page was read and the sentence quoted
- Freshness
- stale on 2026-11-21checked 2026-10-21 (inherited); stale on 2026-11-21
| Free tier | Each record has a default storage quota of 50 GB, with an unlimited number of records under 50 GB, plus an additional allowance of up to 150 GB to distribute across uploads; no period is stated. unit GB; metered on stored-bytes; The 50 GB quota applies per record; the 150 GB is one total allowance assigned to records from the storage settings. The per-record cap, the request rate and the retention window are in limits[]. |
|---|---|
| Price | none stated |
| Limits |
No aggregate cap observed. |
| Identity | institution (placeholder) inferred from the category 'academic'; the source record states no identity cost, so this is a class assumption, not evidence |
| Egress | Free and unmetered, and HTTP Range (206) is supported anonymously, which is what makes the parallel read possible: 'accept-ranges: bytes', 'content-range: bytes 0-1023/81165133690'. |
| Per-object cap | not stated |
| Retention | not stated |
| Interface | rest, rclone rest |
| Tooling | zenodo_get (pip) already parallelises; any HTTP client with range support (aria2c -x/-s, rclone non-backend http, curl --parallel) will do. |
| Composes with | Per-connection shaping ~350-480 KB/s means you need concurrency, not accounts. Measured scaling: 1 conn 0.3 MB/s -> 6 conns 2.33 MB/s -> 16 conns 6.01 MB/s -> 32 conns 11.95 MB/s -> 64 conns 23.07 MB/s. Essentially linear, no knee up to 64. |
| Reliability | Single-stream downloads are painfully slow (~215 KB/s on a 100MB range; the same range took 120s to deliver 45MB). Anything that does not parallelise will appear broken. Reading one file sequentially is a ~50x underuse of the link. |
| Evidence note | documented The read path and the served byte count were measured against the record's own object. The quota is still a page claim, so the record is documented and carries the probe. Was documented; now documented. |
| Parsed numbers |
|
Evidence 13
| date | source | what it proved |
|---|---|---|
| 2026-10-22 | help.zenodo.org/docs/deposit/manage-quota/ | 50 GB per record by default, unlimited records, plus a 150 GB pool. Re-read https://help.zenodo.org/docs/deposit/manage-quota/: HTTP 200, 2413 bytes, sha256 c11445727085cd20. Quoted: l: "https://help.zenodo.org/docs/deposit/manage-quota/" fetched_at: "2026-10-22T02:56:33.001Z" --- # Manage storage quota --- Each record comes with a default storage quota of 50GB and you can upload an unlimited number of records under 50GB. For larger files, you also have an additional allowance of up to 150GB that can be distributed across your uploads as needed. You can view detailed information about your quota usage in your |
| 2026-10-22 | help.zenodo.org/docs/deposit/manage-quota/ | 50 GB per record by default, unlimited records, plus a 150 GB pool. Re-read https://help.zenodo.org/docs/deposit/manage-quota/: HTTP 200, 2413 bytes, sha256 c11445727085cd20. Quoted: l: "https://help.zenodo.org/docs/deposit/manage-quota/" fetched_at: "2026-10-22T02:56:33.001Z" --- # Manage storage quota --- Each record comes with a default storage quota of 50GB and you can upload an unlimited number of records under 50GB. For larger files, you also have an additional allowance of up to 150GB that can be distributed across your uploads as needed. You can view detailed information about your quota usage in your |
| 2026-10-21 | source not published | probe: control baseline versus same link — speed.cloudflare.com 10MB -> 23.67 MB/s line rate |
| 2026-10-21 | source not published | probe: curl -r 0-8388607 zenodo record 5656641 iPS.zip -> 206, 388 KB/s, 8.39 MB, 21.6s (single stream) |
| 2026-10-21 | source not published | probe: 32 parallel 2MiB ranges on the same file -> all 206, aggregate 11.95 MB/s, 365 KB/s each |
| 2026-10-21 | source not published | probe: 64 parallel 2MiB ranges on the same file -> all 206, aggregate 23.07 MB/s, 352 KB/s each — i.e. full line rate, linear scaling, no per-IP aggregate cap |
| 2026-10-21 | probe: https://zenodo.org/api/records/5656641/files/iPS.zip/content | throughput re-probe: parallel ranged GET https://zenodo.org/api/records/5656641/files/iPS.zip/content (7.77 GB file, 15 s each) -> 1 conn 0.48 MB/s, 8 conns 4.93 MB/s, 32 conns 19.68 MB/s, all 206 |
| 2026-10-21 | zenodo.org/policies | read live 2026-10-21: 'Total files size limit per record is 50GB. Higher quotas can be requested' |
| 2026-10-21 | developers.zenodo.org/ | read live 2026-10-21: 'a limit of 50GB total in the record (and any given file), and up to 100 files in the record'; rate-limit table 60/min guest, 100/min auth, 30/min search |
| 2026-10-21 | source not published | probe: 1/8/32 parallel range GETs -> 0.48 / 4.93 / 19.68 MB/s, all HTTP 206, server: nginx, content-length 7772590480 |
| 2026-10-22 | probe: https://zenodo.org/api/records/23488904/files/Manual%20T%C3%A9cnico%20Higiene%20Alimentar%20e%20Preven%C3%A7%C3%A3o%20da%20Contamina%C3%A7%C3%A3o%20Cruzada_.pdf/content | ranged GET 2026-10-22: 206 PARTIAL_CONTENT, 1,024 bytes, content-range bytes 0-1023/2556616, accept-ranges: bytes, server nginx; anonymous, no key |
| 2026-10-30 | help.zenodo.org/docs/deposit/manage-quota/ | 50 GB per record, unlimited records, plus up to 150 GB additional allowance |
| 2026-10-30 | help.zenodo.org/docs/deposit/manage-quota/ | the 150 GB is a total allowance assigned to records |
More fields 7
| verified | [{"url": "https://help.zenodo.org/docs/deposit/manage-quota/","date": "2026-10-22","via": null,"http_status": 200,"bytes": 2413,"sha256": "c11445727085cd202d2e0dbbb89721aec071253db935a3816fc347ef0228c92e","pattern_found": true,"what_changed": "no change: the page still states the claim","capture": null}] |
|---|---|
| verify quota | 50 GB per record by default, unlimited records, plus a 150 GB per-account allowance that can be pooled onto a single record (=> 200 GB max for one record). Verbatim: 'Each record comes with a default storage quota of 50GB and you can upload an unlimited number of records under 50GB. For larger files, you also have an additional allowance of up to 150GB that can be distributed across your uploads as needed.' Policy page: 'Total files size limit per record is 50GB. Higher quotas can be requested and granted on a case-by-case basis.' |
| verify per unit cap | 50 GB per record default; 200 GB absolute ceiling on a single record with the 150 GB allowance pooled in; max 100 files per record (new API: 'a limit of 50GB total in the record (and any given file), and up to 100 files in the record'). |
| verify probe | parallel ranged GET https://zenodo.org/api/records/5656641/files/iPS.zip/content (7.77 GB file, 15 s each) -> 1 conn 0.48 MB/s, 8 conns 4.93 MB/s, 32 conns 19.68 MB/s, all 206 |
| verify notes | All quota numbers confirmed unchanged. 1 conn 0.48 MB/s -> 8 conns 4.93 MB/s (10.3x for 8x) -> 32 conns 19.68 MB/s (4.0x for 4x, perfectly linear). The new-API file cap: 100 files per record, which matters for sharding — 50 GB must be split into no more than 100 files, i.e. >=500 MB per file. |
| verify verdict | qualifies-with-caveat |
| verify confidence | high |
Unknown values 4
- per object cap notes: the field may be stated in a source that was not read
- per object cap stated: the field may be stated in a source that was not read
- retention notes: the field may be stated in a source that was not read
- retention stated: the field may be stated in a source that was not read
Zenodo (CERN)
Storage- Free allowance
- Each record comes with a default quota of 50 GB and an unlimited number of records may be uploaded under 50 GB; a further 150 GB additional allowance is held per account and can be distributed across records as needed.
- Verdict
- caveatusable, with a named limit or an unprobed read path
- Cost
- free tier
- Identity
- emailno card, no phone
- Binding limit
- write-gateda DOI is minted on publish and the record is then immutable except for metadata; files may only be added in a 30-day window
- Evidence
- documented12 sources; a first-party page was read and the sentence quoted
- Freshness
- stale on 2026-12-02checked 2026-11-01 (live); stale on 2026-12-02
| Free tier | Each record comes with a default quota of 50 GB and an unlimited number of records may be uploaded under 50 GB; a further 150 GB additional allowance is held per account and can be distributed across records as needed. unit GB; metered on stored-bytes; CERN funds the service, so the quota is a policy that can move; it is not a purchased allowance with a contract behind it. |
|---|---|
| Price | none stated |
| Limits |
A second record is the alternative route and it costs a second DOI. |
| Binding | write-gated The cap is generous for a user's shard sizes; the gate is what decides the workflow, because a mistake after publication cannot be corrected in place, only superseded by a new version. |
| Identity | email A local account asks for a username, full name, affiliation, email address and password, and the email must be confirmed before the first upload; ORCID and GitHub logins are offered as alternatives and neither is required. No card and no institutional check. |
| Egress | free with no metered allowance; the published limits are on request count, not on transferred bytes: a guest may make 60 requests per minute, an authenticated user 100; files are served to an anonymous ranged GET without authentication. |
| Per-object cap | 50 GB per record (50000000000 bytes) |
| Retention | Items are retained for the lifetime of the repository, currently the lifetime of the host laboratory CERN, whose experimental programme is defined for the next 20 years at least; a withdrawn record leaves a tombstone page and the DOI and URL of the original object are retained. |
| Interface | rest, s3-compatible REST deposit API with a token, plus an S3-compatible endpoint for large files. Not a WebDAV or rclone-native backend. endpoint: https://zenodo.org/api |
| Tooling | requests or curl against the deposit API; the S3 endpoint needs a generated key pair |
| Composes with | The useful chain is write-once archive plus a parallel ranged reader: Zenodo holds the durable copy and a Worker or a ranged client serves it, because a single stream is slow but many streams are not. |
| Reliability | CERN-operated and long-lived; the failure mode is policy change rather than downtime. Records are immutable after publication, so a quota reduction would affect new deposits and not existing ones. The binding limit on reading is the per-connection throttle, which parallel ranged GETs defeat; see zenodo-anonymous-download-throughput. |
| Notes | Split across three sub-finding records that each answer one question: anonymous download throughput, DOI batching, and restricted-access records as working storage. This record is the provider itself, so that a document citing Zenodo has one canonical target. |
| Evidence note | documented The quota and the write gate are read from CERN's own help pages on 2026-10-21; the throughput is measured separately in zenodo-anonymous-download-throughput. |
| Parsed numbers |
|
Evidence 12
| date | source | what it proved |
|---|---|---|
| 2026-10-21 | help.zenodo.org/docs/deposit/manage-files/ | 50 GB per record and a 150 GB per-account pool, stated as a shared allowance rather than a per-record guarantee |
| 2026-10-21 | about.zenodo.org/policies/ | the retention policy: records are retained permanently and citable by DOI |
| 2026-11-01 | help.zenodo.org/docs/deposit/manage-quota/ | the 50 GB per-record default and the unlimited record count; the same page states the additional 150 GB allowance is distributed from a per-account pool |
| 2026-11-01 | help.zenodo.org/docs/deposit/manage-files/ | the per-record cap is 100 files and 50,000,000,000 bytes |
| 2026-11-01 | about.zenodo.org/policies/ | retention is bounded by the repository's lifetime and the same page states the tombstone rule for a withdrawal |
| 2026-11-01 | developers.zenodo.org/ | the documented limits are request rates for guests and authenticated users, not byte allowances |
| 2026-11-01 | help.zenodo.org/docs/get-started/create-an-account/ | the sign-up form names the five fields including a free-text affiliation, and the same page requires the email to be confirmed before a first upload |
| 2026-11-01 | help.zenodo.org/docs/deposit/manage-quota/ | the quota page as served on 2026-11-01 |
| 2026-11-01 | help.zenodo.org/docs/deposit/about-records/ | the write gate the record's binding rests on: files and the DOI freeze at publication |
| 2026-11-01 | help.zenodo.org/docs/deposit/manage-files/ | the 30-day file-edit window the write-gated row describes |
| 2026-11-01 | help.zenodo.org/docs/deposit/about-records/ | publication is what mints the DOI, the first half of the write gate |
| 2026-11-01 | probe: https://zenodo.org/api/records/23862367/files/Experimental-data.xlsx/content | an anonymous ranged GET of a public record file answers 206 with Content-Range bytes 0-1023/30670, so reading needs no account |
- Free allowance
- One DOI per record, automatically, free, and unlimited records.
- Verdict
- caveatusable, with a named limit or an unprobed read path
- Cost
- free tier
- Identity
- emailno card, no phone
- Binding limit
- request-rate100 requests per minute authenticated, 30 per minute on the search API, which sets the batch size per hour rather than any record count cap
- Evidence
- documented3 sources; a first-party page was read and the sentence quoted
- Freshness
- stale on 2026-11-21checked 2026-10-21 (live); stale on 2026-11-21
| Free tier | One DOI per record, automatically, free, and unlimited records. DOI count is therefore not a constraint on sharding: a 410-record archive is also 410 citable handles at no extra cost unit objects; metered on object-count |
|---|---|
| Price | none stated |
| Limits |
Content outside the repository's scope is removed and its DOI revoked, which is the only stated ground for losing an identifier after the 30-day window |
| Binding | request-rate Nothing limits the number of DOIs. What limits a batch job is the authenticated request rate, so the practical ceiling is records per hour and not records per account |
| Identity | email an email address, GitHub or ORCID account. No institution is needed to mint a DOI, which is the unusual part |
| Egress | Not applicable to the identifier itself. Retrieval of the deposited bytes is free and unmetered, and the read path is measured in the sibling record |
| Per-object cap | One DOI per record, and the deposition response carries a reserved DOI already set through prereserve_doi, so a batch job gets a citable handle without a separate call |
| Retention | DOIs are permanent and cannot be reused or reassigned. Deleting a record within 30 days revokes the DOI, after which it tombstones. A record cannot be un-published to reclaim the identifier |
| Interface | rest POST /api/deposit/depositions returns a record with a reserved DOI already set, so one call per record yields one identifier |
| Tooling | any HTTP client. zenodo_get and zenodo-cli both wrap the same API for the read side; there is no rclone backend |
| Composes with | Because every record gets a DOI for free, a 410-record archive is also 410 citable handles with zero extra work. This is the mechanism that makes the unlimited-records story practical rather than merely permitted: there is no per-DOI cost and no approval step, so the archive can be sharded to the record boundary and every shard stays citable |
| Reliability | Batch-creating hundreds of records is API-rate-bound only and not quota-bound, so the operational risk is a batch that half-completes and leaves Pending files rather than one that hits a ceiling |
| Notes | The quota, the API and the 30-day window belong to the parent finding and are not restated as new facts here |
| Evidence note | documented What would raise it is a probe that creates a deposition anonymously or with a token and reads the reserved DOI back |
| Parsed numbers |
|
Evidence 3
| date | source | what it proved |
|---|---|---|
| 2026-10-21 | developers.zenodo.org/ | the quickstart creates a deposition, receives a 'doi' and 'prereserve_doi' in the response, uploads through a bucket URL, then POSTs to /publish, and notes the newer file API has 'a limit of 50GB total in the record (and any given file), and up to 100 files in the record' |
| 2026-10-21 | about.zenodo.org/policies/ | 'Content not considered to fall under the scope of the repository will be removed and associated DOIs issued by Zenodo revoked', and on withdrawal that the DOI and the URL of the original object are retained |
| 2026-10-21 | help.zenodo.org/docs/deposit/manage-records/ | deletion is owner-initiated within 30 days after publication; outside that window only justified cases are considered |
More fields 7
| parent finding | Zenodo's public deposit path at 50 GB per record times unlimited records |
|---|---|
| sibling record | storage/zenodo-anonymous-download-throughput covers the measured read path |
| sub finding | yes |
| what the parent record owns | the deposit API, the quota arithmetic, the 30-day window and the visibility model |
| what this record owns | that a DOI is minted per record at no cost, which is what allows the archive to be sharded to the record boundary without losing citability |
| doi per record | yes |
| record count for 20 tib | 410 |
- Free allowance
- The same 50 GB per record and 150 GB per-account pool as the public path.
- Verdict
- caveatusable, with a named limit or an unprobed read path
- Cost
- free tier
- Identity
- emailno card, no phone
- Binding limit
- per-object-cap50 GB per record on the default quota, 100 files per record
- Evidence
- documented4 sources; a first-party page was read and the sentence quoted
- Freshness
- stale on 2026-11-21checked 2026-10-21 (live); stale on 2026-11-21
| Free tier | The same 50 GB per record and 150 GB per-account pool as the public path. Restricting the files neither reduces nor refunds the quota, so the capacity is identical unit GB; metered on stored-bytes; They are the same quota with a different visibility flag, and the difference decides whether Zenodo can be a working set or only an archive |
|---|---|
| Price | none stated |
| Limits |
Metadata is always public even when the files are restricted, so titles, descriptions and the minted DOI leak. That is a property of the visibility model and not a defect in this record |
| Binding | per-object-cap The quota and the visibility are independent, so restricting a record buys privacy and no capacity. |
| Identity | email an email address, GitHub or ORCID account. |
| Egress | Free. A secret link grants 'Can view' on restricted or embargoed files of all current and future versions of that record, with optional expiry |
| Per-object cap | 50 GB per record on the default quota, with the 150 GB account pool distributable across records, and a hard 100 files per record (50000000000 bytes) |
| Retention | A record cannot be deleted after 30 days. Restricted records carry the same rule, so a restricted record is as permanent as a public one and its quota is consumed monotonically |
| Interface | rest the same deposition API; visibility is a field on the draft, set to restricted with an embargo date or a share link, and share links are managed from the record's Links tab |
| Tooling | any HTTP client for the deposition and file APIs, working in the same way as the public path. There is no rclone backend, so uploads are plain HTTP PUT against a bucket URL |
| Composes with | This is what turns Zenodo from a cold archive into something usable as a hot working set: a user can keep data off the public index while still holding 50 GB times N, and still read it programmatically with a token or a shared link. It composes with the 32-connection parallel read measured on the public path, because the throttle is per connection and not per visibility |
| Reliability | Answers the working-storage question: workable for private data, but every record still carries permanently public metadata and a DOI, so it is a leaky private tier and not a private bucket. An interrupted upload leaves a Pending file that must be removed by hand |
| Notes | It does not duplicate the main provider: the quota, the API and the lifecycle are the parent record's, and this one adds only the visibility field and what it costs |
| Evidence note | documented What would raise it is a probe of a restricted record read through a secret link |
| Parsed numbers |
|
Evidence 4
| date | source | what it proved |
|---|---|---|
| 2026-10-21 | help.zenodo.org/docs/share/link-sharing/ | 'Link sharing enables you to create a secret link which provides access to your record. The link can also have an expiry date.' and 'Can view: Grants access to view restricted/embargoed files of all current and future versions' |
| 2026-10-21 | help.zenodo.org/docs/about/whats-changed/ | 'the access right field has now been changed into a visibility field with two options (metadata is always public)' |
| 2026-10-21 | help.zenodo.org/docs/deposit/manage-quota/ | each record comes with a default quota of 50 GB and an additional 150 GB allowance distributable across uploads, with no account-level total documented |
| 2026-10-21 | help.zenodo.org/docs/deposit/manage-records/ | records can be deleted by their owner within 30 days after publication, and outside that window only in justified cases |
More fields 4
| sibling record | storage/zenodo-anonymous-download-throughput covers the measured read path |
|---|---|
| sub finding | yes |
| what the parent record owns | the deposit API, the quota arithmetic, the 30-day window and the DOI behaviour |
| what this record owns | the visibility field, secret links, and the leak of metadata under a restricted record |
openaire graph
Storage- Free allowance
- Not a repository — its dumps are published onto Zenodo (community 'openaire-research-graph'), i.e. it consumes the same 50 GB/record budget everyone else does.
- Verdict
- fails: quotathe free allowance is too small to matter
- Cost
- not stated
- Identity
- email?placeholder, not evidence; card unknown, phone unknown
- Binding limit
- noneno named constraint binds
- Evidence
- reported2 sources; a third party said so
- Freshness
- stale on 2026-11-05checked 2026-10-21 (inherited); stale on 2026-11-05
| Free tier | Not a repository — its dumps are published onto Zenodo (community 'openaire-research-graph'), i.e. it consumes the same 50 GB/record budget everyone else does. 10.8 GB per part. unit none; metered on none |
|---|---|
| Price | none stated |
| Identity | email (placeholder) not published |
| Egress | not recorded |
| Interface | unknown |
| Tooling | not recorded |
Evidence 2
| date | source | what it proved |
|---|---|---|
| 2026-10-21 | zenodo.org/communities/openaire-research-graph/about | the text of Free tier, above |
| 2026-10-21 | zenodo.org/records/17725827 | cited as the basis of the rejection: Not a repository — its dumps are published onto Zenodo (community 'openaire-research-graph'), i.e. it consumes the same 50 GB/record budget everyone else does. 10.8 GB per part. |
More fields 1
| dead end | {"failure_class": "quota","why": "Not a repository — its dumps are published onto Zenodo (community 'openaire-research-graph'), i.e. it consumes the same 50 GB/record budget everyone else does. 10.8 GB per part.","retry_when": null,"first_recorded": "2026-10-21"} |
|---|
Unknown values 7
- chaining: no value was recorded for this field
- egress terms: no value was recorded for this field
- interface: the access interface was not established
- per object cap notes: no value was recorded for this field
- per object cap stated: no value was recorded for this field
- retention stated: no value was recorded for this field
- tooling: no value was recorded for this field