Large files
Live on FastFSRuns on FastFS
A file over files.external_over bytes goes to FastFS, which stores it for gas only. The release holds its https URL and sha256, and the gateway serves it under the release's own path.
Setting
"files": { "external_over": 32768, "store": "fastfs" }How Harbour Board uses it
- The Board's hero photo is 493,183 B. It was uploaded to FastFS and first sealed as an external file in release 4.
- The gateway serves it at
/assets/img/harbour.png, and its sha256 is16cca451…8ccf.
Proof on testnet
| The file on FastFS | test.fastfs.io |
|---|---|
| Sealed in release 4 | 44t7hUBp… |
| Served through the gateway | /assets/img/harbour.png |
Check it without a key: curl -fsS https://harbour-board.ss251.workers.dev/assets/img/harbour.png | shasum -a 256 The view helper is in the repository README, and scripts/judge.sh runs these checks.
What you trust
FastFS is one operator. If it drops a file, the release still points at it and the sha256 still says what it should be. Pinata and Filebase stores exist in the CLI and were never run against the live services. NEARFS accepted uploads on testnet and never served them, so it is not the default.
Limits
| Serving | A FastFS upload was served about 5 minutes after upload |
|---|
Every flag is in the command reference, generated from quay up --help.