- Free allowance
- Per-account storage is UNLIMITED (stock Mastodon has no per-user media quota at all — media_attachment has only a per-file size validator, no account-level counter).
- Verdict
- fails: quotathe free allowance is too small to matter
- Cost
- free tier
- Identity
- institution?placeholder, not evidence; card unknown, phone unknown
- Binding limit
- per-object-capPer FILE: image_size_limit = video_size_limit = 1419430400 bytes = 1.32 GiB
- Evidence
- reported4 sources; a third party said so
- Freshness
- stale on 2026-11-05checked 2026-10-21 (inherited); stale on 2026-11-05
| Free tier | Per-account storage is UNLIMITED (stock Mastodon has no per-user media quota at all — media_attachment has only a per-file size validator, no account-level counter). Per FILE: image_size_limit = video_size_limit = 1419430400 bytes = 1.32 GiB. That is a 84x relaxation of Mastodon's compiled defaults (IMAGE_LIMIT 16 MB / VIDEO_LIMIT 99 MB). unit GiB; metered on stored-bytes |
|---|
| Price | none stated |
|---|
| Limits | - per-ip-shaping 1.9 TB/day source
- per-object-cap (binding) Per FILE: image_size_limit = video_size_limit = 1419430400 bytes = 1.32 GiB source
request-rate is THE binding limit, and it is severe: stock Mastodon rack_attack ships throttle('throttle_api_media', limit: 30, period: 30.minutes) per authenticated user — 30 media uploads per half hour = 1,440/day. At 1.32 GiB each that is a theoretical 1.9 TB/day/account, so realistically you hit GB-scale throughput only by running many accounts in parallel. Also: 8 media per status (MAX_MEDIA_ATTACHMENTS), 4 statuses/30 min soft on some instances, MAX_VIDEO_FRAMES 36,000 (≈5 min at 120 fps) and MAX_VIDEO_MATRIX_LIMIT 8,294,400 px cap video dimensions, and non-image/video MIME types are rejected by the upload validator. |
|---|
| Identity | institution (inferred, not read) not published |
|---|
| Egress | Free. No egress meter on the instance; media sits behind the instance CDN (often S3/Wasabi/B2-compatible behind a CNAME). |
|---|
| Per-object cap | Per FILE: image_size_limit = video_size_limit = 1419430400 bytes = 1.32 GiB (1417339207 bytes) |
|---|
| Retention | infosec.exchange is one of the largest and best-funded Mastodon instances (Glitch fork 4.8.0-alpha.3) and explicitly runs a relaxed upload policy; still a single volunteer operator, and a 1.3 GiB upload is exactly the kind of thing that gets noticed. Media is permanent by Mastodon semantics (no TTL, no GC), which cuts both ways. |
|---|
| Interface | rest, rclone, cli rest |
|---|
| Tooling | Mastodon REST API v1: POST /api/v1/media (multipart file -> returns media id + url), then POST /api/v1/statuses with media_ids[] to make it permanent. OAuth2 app registration via POST /api/v1/apps (no manual approval on most instances). Any of the many existing clients work; toot CLI, Mastodon.py. Upload-from-URL: POST /api/v2/media with url param. rclone has no Mastodon backend but the API is 3 calls. |
|---|
| Composes with | The key structural fact: NO per-account quota means the ceiling is the instance's disk, and the operator absorbs it. Combined with a 1.32 GiB per-file cap and 8 attachments per status, one status carries 10.6 GiB in a single API call chain. Multiple accounts on the same instance each get the same unlimited-account treatment. Multiply over instances for isolation. |
|---|
| Reliability | infosec.exchange is one of the largest and best-funded Mastodon instances (Glitch fork 4.8.0-alpha.3) and explicitly runs a relaxed upload policy; still a single volunteer operator, and a 1.3 GiB upload is exactly the kind of thing that gets noticed. Media is permanent by Mastodon semantics (no TTL, no GC), which cuts both ways. |
|---|
| Parsed numbers | - has-free-tier 1
- per-ip-shaping 1.9 TB / day
- per-object-cap 1.32 GiB
|
|---|