misskey.gg
misskey.gg · Storage · 1 record · JSON
misskey.gg — Misskey 2026.10, 1 TB drive per user (highest live instance found) Storage
caveatinstitutionno cardDper-object-cap
| Free tier | 1024000 MB = 1 TiB drive capacity PER USER. The per-object cap is 250 MiB: maxFileSizeMb reads 1024 (1 GiB) but the top-level maxFileSize of 262,144,000 bytes is the enforced field. This is the single largest per-user quota located on a live, registration-open fediverse instance. unit TiB; metered on unstated |
|---|---|
| Price | none stated |
| Per-object cap | 250 MiB per object, enforced by the top-level maxFileSize of 262,144,000 bytes (262144000 bytes) |
| Retention | not stated |
| Egress | Free. Media is served from a plain path on the instance domain (observed scheme: https://sss.<instance>/sss/<shard>/<uuid>) with Cache-Control: max-age=31536000, immutable. No egress meter, no bandwidth charge, no signed URL. |
| Identity | institution derived from the record's prose, not from an identity field, and no signup was executed: ccount is an independent counter and registration is open (API reports disableRegistration: false, emailRequiredForSignup: true), each account holds 1 TiB. Ten accounts hold 10 TiB. T |
| Limits |
per-object-cap 1 GiB (maxFileSizeMb=1024, verified 262144000 bytes = 250 MiB on most other instances, 524288000 = 500 MiB on misskey.io). Drive quota 1 TiB/user. Usage-anomaly controls: inviteLimit: 1 per 1440 min does NOT gate open signup. Request-rate: Misskey applies a per-IP rate limiter on /api/drive/files/create (4096 req/hr default per IP, plus per-account limits, 250 MB/hr-ish effective on small instances). |
| Binding | per-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 |
| Interface | rest, rclone rest |
| Tooling | Misskey HTTP API is a clean JSON REST surface: POST /api/drive/files/create (multipart, file field) with an i (token) in the body; POST /api/drive/files/upload-from-url; POST /api/drive/files/delete; POST /api/drive/files (list). Token minted via MiAuth (GET https://<host>/miauth/<uuid>?name=...&permission=write:drive,read:drive) or POST /api/signin with username+password -> returns i, which is then just a query param. No library needed: it is a 20-line requests wrapper. rclone has no Misskey backend; write a thin one. |
| Composes with | driveCapacityMb is a per-user soft counter enforced by the instance, not a hard technical wall — media attached to notes can still be served after the drive is full. Because each account is an independent counter and registration is open (API reports disableRegistration: false, emailRequiredForSignup: true), each account holds 1 TiB. Ten accounts hold 10 TiB. The provider accepts a single POST per account, so a client with mail control can register many. |
| Reliability | Instance is a single volunteer-run host with ~small user count; a 1 TB drive is a published number, not a promise, and one operator decision or a disk-full incident takes everything offline at once. No SLA, no backup guarantee. Treat as 'high capacity, zero durability'. |
| Notes | 1024000 MB = 1 TiB drive capacity PER USER, with a 250 MiB per-object cap: maxFileSizeMb reads 1024 (1 GiB) and the top-level maxFileSize of 262,144,000 bytes is enforced, so a 1 TiB drive at 250 MiB per object needs 4,096 uploads. This is the single largest per-user quota located on a live, registration-open fediverse instance. |
| Evidence rung | documented The quota is a live API field read, not a page claim. The record stays documented because the identity field is inferred from prose, not read from the API. Was documented; now documented. |
| Checked | 2026-10-21 (inherited); stale on 2026-11-20 |
| Parsed numbers |
|
Evidence (5)
| date | source | what it proved |
|---|---|---|
| 2026-10-22 | misskey.gg/api/meta | driveCapacityMb = 1024000 (1,024,000 MB = 1 TiB per user); policies.maxFileSizeMb = 1024 while the top-level maxFileSize = 262,144,000 B = 250.0 MiB is the cap actually enforced; emailRequiredForSignup = true, disableRegistration = false. The per-object cap and the field's own location disagree, which is the trap. |
| 2026-10-21 | misskey.gg/api/meta | probe: POST -> 200, policies.driveCapacityMb=1024000, policies.maxFileSizeMb=1024, maxFileSize=262144000, disableRegistration=false, emailRequiredForSignup=true, version=2026.10.0 |
| 2026-10-21 | misskey.gg/nodeinfo/2.1 | probe: GET -> 200, software.name=misskey, openRegistrations=true |
| 2026-10-21 | sss.misskey.gg/sss/gg/ed101a7b-8b8c-4d91-b67d-cb381562323d | probe: HEAD -> 200, Content-Type: application/octet-stream, Cache-Control: max-age=31536000, immutable |
| 2026-10-22 | probe:https://misskey.gg/api/meta | POST /api/meta {detail:true} 2026-10-22: 200, 3,228 B; policies.driveCapacityMb 1,024,000, policies.maxFileSizeMb 1024, top-level maxFileSize 262,144,000, emailRequiredForSignup true |
More fields (2)
{
"verdict_note": "PLAN.md §3.2 rules qualifies-with-caveat for misskey.gg on the re-probed 1 TiB drive / 250 MiB object / email-required evidence",
"verified_in_pass": [
{
"url": "https://misskey.gg/api/meta",
"date": "2026-10-22",
"via": "fetch-broker POST {\"detail\":true}",
"http_status": 200,
"bytes": 3228,
"sha256": null,
"pattern_found": true,
"what_changed": "no change to the numbers; the field's location is confirmed (maxFileSize is top-level, not under policies)",
"capture": "captures/misskey-meta.json"
}
]
}Unknown or withheld values (3)
$.free_tier.notesprocess$.retention.notesnot-extracted$.retention.statednot-extracted