- Free allowance
- 50 GiB per user and no daily upload cap: the instance config reports user.videoQuota 53687091200 and user.videoQuotaDaily -1
- Verdict
- caveatusable, with a named limit or an unprobed read path
- Cost
- free tier
- Identity
- emailno card, no phone
- Binding limit
- per-object-capno byte cap published, but the instance transcodes every upload at the source resolution and sets alwaysTranscodeOriginalResolution true, so the delivered file is not the uploaded file
- Evidence
- measured5 sources; a live request was made and its output kept
- Freshness
- stale on 2026-12-07checked 2026-10-22 (live); stale on 2026-12-07
| Free tier | 50 GiB per user and no daily upload cap: the instance config reports user.videoQuota 53687091200 and user.videoQuotaDaily -1 unit GiB; metered on stored-bytes; registration is open with no approval and no email verification: signup.allowed true, requiresApproval false, requiresEmailVerification false. The instance is HitTube, server version 8.3.1, serverCountry France |
|---|
| Price | none stated |
|---|
| Limits | - per-object-cap (binding) no byte cap published, but the instance transcodes every upload at the source resolution and sets alwaysTranscodeOriginalResolution true, so the delivered file is not the uploaded file source
- write-gated an account is required to upload; registration is open with no approval and no email verification source
The instance reports 201 local videos totalling 21,058,245,956 bytes with 2 registered users, so the operator's disk holds about 21 GB of other people's content. Two users and 21 GB is the scale of the goodwill a 50 GiB quota is drawn on |
|---|
| Identity | email an email address, and the instance does not verify it: signup.requiresEmailVerification is false and requiresApproval is false. No card, no phone |
|---|
| Egress | Free and unmetered: downloads are enabled by default (publish.downloadEnabled true) and there is no egress line item. HLS is enabled and splitAudioAndVideo is false, so the stream is a single rendition set |
|---|
| Per-object cap | Not published as a byte cap. The instance transcodes to 720, 1080 and 2160 and sets alwaysTranscodeOriginalResolution true, so the file that comes back is a transcode and not the bytes that were uploaded |
|---|
| Retention | No stated expiry while the instance runs. |
|---|
| Interface | rest the PeerTube REST API at /api/v1, with open registration and no token required to read the config or list videos; upload needs an account and a token |
|---|
| Tooling | any HTTP client against /api/v1. PeerTube's own client and third-party uploaders work; there is no rclone backend and no WebDAV, so a pipeline is the upload API or nothing |
|---|
| Composes with | A 50 GiB per-account tier with no daily cap is the largest video-platform allocation found and it does not chain into a storage stack, because the read path returns a transcode. Its role would be as a distribution surface for content that is already video, and not as a store for arbitrary bytes |
|---|
| Reliability | A single-admin volunteer instance in France with two registered users and 39 followers. The config carries a custom support banner and an a-ads iframe, so it is ad-funded and personal. An instance of this size disappears with one hosting decision |
|---|
| Notes | The instance is live and measurable: 50 GiB per user, no daily cap, open registration with no email verification. The caveat that the audit did not name is the one that matters more than the quota: the instance transcodes every upload, so it returns transcoded renditions and not originals |
|---|
| Evidence note | measured the instance configuration and statistics were read live from /api/v1/config and /api/v1/server/stats on 2026-10-22. The quota, the daily cap and the transcode flag are the instance's own reported values. What would raise confidence in the capacity is an upload, which needs an account and was not created |
|---|
| Parsed numbers | |
|---|