fshy

fshy / Storage

SourceForge File

sourceforge.net · Storage · 3 records · JSON

SourceForge File Release System (FRS) + project web space Storage

★ qualifiesany-phoneno cardphoneDper-object-capdisagrees

sourceforge.net · paas · storage/sourceforge-file-release-system-project-web-space · JSON · compare

Sibling records disagree:

Free tierNO PUBLISHED QUOTA. The Service Quotas page says verbatim: 'There are currently no fixed capacity limits around usage of our services. In lieu of specific disk usage caps (quotas), we may contact projects if they are using significant storage.' It then gives a soft expectation rather than a cap: 'Keep disk usage to a reasonable level: 5GB or less is ideal. 20-30GB may be permissible. (limits may vary and be flexible depending on the situation)'. So the real number is 20-30 GB of tolerated storage per project, soft, and multiplied by unlimited projects per account.
unit GB; metered on stored-bytes
Pricenone stated
Per-object capper-object-cap: 'Individual files larger than 10 GB (10000000000 bytes)
Retentionper-object-cap: 'Individual files larger than 10 GB will not replicate out to our mirrors and can not be downloaded.' That is the hard number and it is published. retention: indefinite - download stats are keyed to path+filename and files are never pruned for age; but the docs warn 'Users are responsible for backing up all of their files
EgressFree and genuinely CDN'd: 'Unlimited bandwidth for Open Source projects' (create page) plus 'a geographically-distributed network of mirror servers, which receive copies of the files and dispense them to users'. No billing relationship anywhere. Downloads 302 to a geo-selected mirror (zenlayer.dl.sourceforge.net from this vantage) and are served by nginx.
Identityany-phone derived from the record's prose, not from an identity field, and no signup was executed: only gate is ODF-compliant OSS licensing + a one-time phone/SMS PIN). At the tolerated 20-30 GB/project that is 20-30 GB x N projects x N accounts. The real find is that the number is
Limits
  • per-object-cap per-object-cap: 'Individual files larger than 10 GB source
per-object-cap: 'Individual files larger than 10 GB will not replicate out to our mirrors and can not be downloaded.' That is the hard number and it is published. retention: indefinite - download stats are keyed to path+filename and files are never pruned for age; but the docs warn 'Users are responsible for backing up all of their files. SourceForge.net will not restore individual files.' request-rate: none published; the docs instead route large uploads to rsync for resume. Filename charset is restricted (no & : % ? / * $, may not start with space or dot).
Bindingper-object-cap the per-object cap sets the shard size and therefore the object count; it bounds the total more tightly than any headline quota
Interfacesftp, scp, rsync, ssh sftp
ToolingNative sftp/scp/rsync-over-ssh, no wrapper needed. FRS host frs.sourceforge.net path /home/frs/project/PROJECT_UNIX_NAME/; web host web.sourceforge.net path /home/project-web/PROJECT_UNIX_NAME/htdocs. SFTP is batch-scriptable with key auth ('Use key-based authentication, since password entry can't safely be automated'). rsync is the documented path for anything over 100 MB because it resumes. Read side has machine APIs: /projects/<name>/best_release.json (JSON with bytes/md5sum), /projects/<name>/rss?path=/ (per-file size in files:size), and downloads.sourceforge.net/project/....
Composes withEach account can register unlimited projects ('you automatically are given administrator rights for that particular project'; the only gate is ODF-compliant OSS licensing + a one-time phone/SMS PIN). At the tolerated 20-30 GB/project that is 20-30 GB x N projects x N accounts. The real find is that the number is NEGOTIABLE and unpublished - 'If you are planning to do something which consumes huge amounts of disk, please ask first' - so the ceiling is a support ticket, not a wall. Two independent storage surfaces per project (FRS + project web htdocs), plus git/hg/svn repos, plus wiki/ticket attachments.
ReliabilityThe only fragile part is the soft quota: 20-30 GB 'may be permissible' means a project that grows to hundreds of GB gets an email, not a hard stop - enforcement is discretionary. SFTP is reachable and live (banner SSH-2.0-OpenSSH_7.4 on port 22). One structural caution: the FRS host deliberately does not list the project directory over SFTP ('your project directory is available, even if you cannot see it listed'), so clients must use absolute paths and cannot enumerate.
NotesNO PUBLISHED QUOTA. The Service Quotas page says verbatim: 'There are currently no fixed capacity limits around usage of our services. In lieu of specific disk usage caps (quotas), we may contact projects if they are using significant storage.' It then gives a soft expectation rather than a cap: 'Keep disk usage to a reasonable level: 5GB or less is ideal. 20-30GB may be permissible. (limits may vary and be flexible depending on the situation)'. So the real number is 20-30 GB of tolerated storage per project, soft, and multiplied by unlimited projects per account.
Evidence rungdocumented The absence of a fixed cap is stated on the page as re-read. Was reported; now documented.
Checked2026-10-21 (inherited); stale on 2026-11-20
Parsed numbers
  • $.limits[0].value limit:per-object-cap 10.0 GB
Evidence (10)
datesourcewhat it proved
2026-10-21sourceforge.net/p/forge/documentation/Disk%20Quotas/'There are currently no fixed capacity limits around usage of our services... 5GB or less is ideal. 20-30GB may be permissible.'
2026-10-21sourceforge.net/p/forge/documentation/Release%20Files%20for%'Individual files larger than 10 GB will not replicate out to our mirrors and can not be downloaded.'
2026-10-21sourceforge.net/p/forge/documentation/SFTP/host frs.sourceforge.net, path /home/frs/project/PROJECT_UNIX_NAME/, key-based batch mode
2026-10-21sourceforge.net/p/forge/documentation/rsync/'rsync over SSH is a supported file transfer method for our File management service'
2026-10-21withheldprobe: TCP connect frs.sourceforge.net:22 -> 'SSH-2.0-OpenSSH_7.4' (SFTP endpoint live, anonymous banner)
2026-10-21downloads.sourceforge.net/project/sevenzip/7-Zip/24.09/7z240probe: GET -> 302 to zenlayer.dl.sourceforge.net/?viasf=1&fid=... then 200, Content-Length 1637343, downloaded and sha256 bdd1a33de78618d16ee4ce148b849932c05d0015491c34887846d431d29f308e
2026-10-21withheldprobe: ranged GET bytes 0-1048575 on /project/clonezilla/.../clonezilla-live-20261018-resolute-amd64.iso -> 206, Content-Range: bytes 0-1048575/640679936 (a 640 MB object, ranges honoured, mirror path works)
2026-10-21sourceforge.net/projects/sevenzip/best_release.jsonprobe: GET -> JSON with bytes 1868068, md5sum, filename (machine-readable release metadata, anonymous)
2026-10-21sourceforge.net/p/forge/documentation/Create%20a%20New%20Progate is 'all projects must be Open Source Software, with a license compliant with the Open Source Definition' plus a phone PIN; no editorial review step
2026-10-22sourceforge.net/p/forge/documentation/Disk%20Quotas/200, 3,189 B on 2026-10-22: 'There are currently no fixed capacity limits around usage of our services'
Unknown or withheld values (5)
  • $.evidence[4].url private-url
  • $.evidence[6].url private-url
  • $.free_tier.notes process
  • $.per_object_cap.notes not-extracted
  • $.retention.notes not-extracted

SourceForge File Release System (FRS) — frs.sourceforge.net Storage

caveatinstitutionno cardDper-object-capdisagrees

sourceforge.net/p/forge/documentation/Release%20Files%20for% · paas · storage/sourceforge-file-release-system-frs-sourceforge-net · JSON · compare

Sibling records disagree:

Free tierNo fixed quota. SourceForge's own docs: 'There are currently no fixed capacity limits around usage of our services. In lieu of specific disk usage caps (quotas), we may contact projects if they are using significant storage.' Guidance: '5GB or less is ideal. 20-30GB may be permissible (limits may vary and be flexible depending on the situation)'. So ~20-30 GB per project as a practical band, with no hard number.
unit GB; metered on stored-bytes
Pricenone stated
Per-object cap10 GB per file (10000000000 bytes)
RetentionSourceForge.net will not restore individual files', and releases persist indefinitely (OpenOffice's mirror alone carries 166.4 MB files from 2015)
EgressFree and unmetered. Every release is 'automatically distributed to our worldwide network of download mirrors'. Downloads are served from per-mirror hostnames (zenlayer.dl / twds.dl / cfhcable.dl).sourceforge.net behind Cloudflare. Project Web states 'Unlimited bandwidth for Open Source projects' and 'Our project web servers frequently handle more than 50M hits per day'.
Identityinstitution derived from the record's prose, not from an identity field, and no signup was executed: s plain SFTP so it is limited by SSH session count, not an API quota. Retention: none — 'Users are responsible for backing up all of their files. SourceForge.net will not restore ind
Limits
  • per-object-cap 10 GB per file source
per-object-cap: 10 GB per file — 'Individual files larger than 10 GB will not replicate out to our mirrors and can not be downloaded', so the only way past it is to shard. Request-rate: none published; upload is plain SFTP so it is limited by SSH session count, not an API quota. Retention: none — 'Users are responsible for backing up all of their files. SourceForge.net will not restore individual files', and releases persist indefinitely (OpenOffice's mirror alone carries 166.4 MB files from 2015). Reliability: signed mirror redirects are short-lived (see reliability_note).
Bindingper-object-cap the per-object cap sets the shard size and therefore the object count; it bounds the total more tightly than any headline quota
Interfacesftp, scp, rsync, rclone sftp
ToolingNative SFTP, SCP and rsync — all three documented with working example commands on the FRS page ('scp file.zip [address removed]:/home/frs/project/fooproject/release1'). Reaches rclone via its built-in sftp backend (rclone.org/sftp), and restic/borg/rsync directly. No third-party wrapper needed. Probe: TCP to frs.sourceforge.net:22 -> open.
Composes withOne account, many projects. Each project gets an independent tree at /home/frs/project/<unixname>/ and its own mirror distribution; one project admin can hold release-technician rights on many projects. Chained: (20-30 GB practical per project) x (N projects per account) x (N accounts). At 20 projects that is already 400-600 GB; the 10 GB/file mirror limit forces sharding, which is free because FRS is directory-based. Second chain: the same upload endpoint feeds project *web* space at /home/project-web/<unixname>/htdocs served as <unixname>.sourceforge.io, which is a separate quota-less static origin.
ReliabilityTwo real hazards found by probing. (1) The signed mirror URL from downloads.sourceforge.net 301s to a per-mirror host with an expiring token; when I reused a token ~9 s later all 16 parallel GETs returned 301 with 0 bytes. You must re-resolve the redirect per session, or the mirror silently returns HTML. (2) There is no hard cap, which means the cap is discretionary — SourceForge mails 'over-quota' notices (the 2006 Inkscape notice shows a 100 MB soft quota on the shell/group dir) and can contact projects using 'significant storage'. Treat it as a soft ceiling that a human can raise or lower.
NotesNo fixed quota. SourceForge's own docs: 'There are currently no fixed capacity limits around usage of our services. In lieu of specific disk usage caps (quotas), we may contact projects if they are using significant storage.' Guidance: '5GB or less is ideal. 20-30GB may be permissible (limits may vary and be flexible depending on the situation)'. So ~20-30 GB per project as a practical band, with no hard number.
Evidence rungdocumented re-read from read-broker on 2026-10-22 (HTTP 200, 3189 bytes, sha256 5e5877b1fd03b2c6). The page states the number in the record; the claim is documented, not measured.
Checked2026-10-21 (inherited); stale on 2026-11-20
Parsed numbers
  • $.limits[0].value limit:per-object-cap 10.0 GB
Evidence (8)
datesourcewhat it proved
2026-10-22sourceforge.net/p/forge/documentation/Disk%20Quotas/no fixed capacity limits, 10 GB per file soft. Re-read https://sourceforge.net/p/forge/documentation/Disk%20Quotas/: HTTP 200, 3189 bytes, sha256 5e5877b1fd03b2c6. Quoted: sourceforge.net/p/forge/documentation/Disk%20Quotas/feed.atom 'RSS') [Search](https://sourceforge.net/p/forge/documentation/search 'Search') # Service Quotas There are currently no fixed capacity limits around usage of our services. In lieu of specific disk usage caps (quotas), we may contact projects if they are using significant storage. Projects should: - Keep disk usage to a reasonable level: 5GB or less is ideal. 20-30GB may be permissible. (limits may
2026-10-21sourceforge.net/p/forge/documentation/Disk%20Quotas/'There are currently no fixed capacity limits around usage of our services... 5GB or less is ideal. 20-30GB may be permissible'
2026-10-21sourceforge.net/p/forge/documentation/Release%20Files%20for%SFTP/SCP/rsync example commands; 'Individual files larger than 10 GB will not replicate out to our mirrors and can not be downloaded'
2026-10-21downloads.sourceforge.net/project/sevenzip/7-Zip/24.09/7z240probe: GET -> 302 -> zenlayer.dl.sourceforge.net -> 206 Partial Content, Content-Range: bytes 0-1023/1637343, body starts 4d5a 9000 ('MZ') — real PE bytes, not an error page
2026-10-21withheldprobe: 32 parallel ranged GETs on Apache_OpenOffice_4.1.15 (4000000-byte ranges) -> 68,311,515 bytes in 4632 ms = 14.06 MB/s aggregate
2026-10-21withheldprobe concurrency curve on the same file: N=4 -> 2.52 MB/s, N=8 -> 8.18 MB/s, N=16 -> 7.77 MB/s, N=32 -> 14.06 MB/s. Non-linear and still climbing at 32; the cap is per-connection, not per-IP.
2026-10-21withheldprobe: TCP connect frs.sourceforge.net:22 -> open (SFTP/SCP/rsync upload path live); :873 (plain rsync) -> timeout, so use rsync-over-SSH
2026-10-21withheldprobe: one 166.4 MB release listed on sourceforge.net/projects/openofficeorg.mirror/files/ (200) — large files really are hosted, not theoretical
More fields (1)
{
 "verified_in_pass": [
  {
   "url": "https://sourceforge.net/p/forge/documentation/Disk%20Quotas/",
   "date": "2026-10-22",
   "via": "read-broker",
   "http_status": 200,
   "bytes": 3189,
   "sha256": "5e5877b1fd03b2c60d57741e1636a2a8ac1e848dfaab19f9f5a0a02f00054ea2",
   "pattern_found": true,
   "what_changed": "no change: the page still states the claim",
   "capture": "captures\\sourceforge-frs-sourceforge-net-p-forge-documentation-disk-20quotas-.txt"
  }
 ]
}
Unknown or withheld values (7)
  • $.evidence[4].url private-url
  • $.evidence[5].url private-url
  • $.evidence[6].url private-url
  • $.evidence[7].url private-url
  • $.free_tier.notes process
  • $.per_object_cap.notes not-extracted
  • $.retention.notes not-extracted

SourceForge Project Web (<project>.sourceforge.io) Storage

caveatemail?card?R

sourceforge.net/p/forge/documentation/Project%20Web%20Servic · paas · storage/sourceforge-project-web · JSON · compare

Free tierNo quota stated anywhere on the page — the docs grant each project a vhost and say nothing about a byte limit. Practically it is the same filesystem family as FRS (uploaded over the same SFTP), so expect the same discretionary 20-30 GB band.
unit GB; metered on unstated
Pricenone stated
Per-object capnot stated
Retentionnot stated
Egress'Unlimited bandwidth for Open Source projects' (sourceforge.net/create). 'Our project web servers frequently handle more than 50M hits per day; we handle server scaling, caching, load balancing, and performance tuning.' Served through Cloudflare.
Identityemail (placeholder) not published
Bindingnone no constraint in the record binds at this scale; the record carries no limit of a kind the vocabulary names
Interfacesftp, scp, rsync sftp
ToolingSame SFTP/SCP/rsync upload path as FRS but to /home/project-web/<unixname>/htdocs. Static files come back over plain HTTPS on <unixname>.sourceforge.io — no client, no API, just a web origin. Custom domains supported via the Custom VHOST service.
Composes withA second independent quota-less origin per project, free once you already have the project. Because it is a static web origin rather than a download mirror, it is the natural Cloudflare-fronted serving layer for anything in FRS: serves as the hot/serving tier while FRS holds the archive. N projects -> N vhosts.
ReliabilityProbed live: https://libreoffice.sourceforge.io/ -> 200 with 134,123 bytes of real HTML; https://gimp.sourceforge.io/ -> 403 (project redirects elsewhere). https://gparted.sourceforge.io/ -> 302 to the project's own domain. Expect some projects to 403/302 depending on their custom-VHOST config; a fresh project should serve its own root.
NotesNo quota stated anywhere on the page — the docs grant each project a vhost and say nothing about a byte limit. Practically it is the same filesystem family as FRS (uploaded over the same SFTP), so expect the same discretionary 20-30 GB band.
Evidence rungreported One page read moves it to documented.
Checked2026-10-21 (inherited); stale on 2026-11-04
Evidence (4)
datesourcewhat it proved
2026-10-21sourceforge.net/p/forge/documentation/Project%20Web%20Servic'each project is provided the PROJECT.sourceforge.io subdomain'; 'frequently handle more than 50M hits per day'; SFTP path /home/project-web/PROJECT/htdocs
2026-10-21sourceforge.net/create/'Unlimited bandwidth for Open Source projects'
2026-10-21libreoffice.sourceforge.io/probe: GET -> 200, 134123 bytes, text/html
2026-10-21gparted.sourceforge.io/probe: GET -> 302 Location: https://gparted.org/ ; GET https://gimp.sourceforge.io/ -> 403
Unknown or withheld values (7)
  • $.free_tier.notes process
  • $.identity_cost.detail defaulted
  • $.identity_cost.kind identity-defaulted
  • $.per_object_cap.notes not-extracted
  • $.per_object_cap.stated not-extracted
  • $.retention.notes not-extracted
  • $.retention.stated not-extracted