The PeerTube on AWS by FOSSonCloud pattern now ships PeerTube 8.2.3, up from 8.1.5. That spans the 8.2.0 feature release plus three patch releases — two of which contain meaningful security fixes, one of them critical.
What changed
8.2.0 — ownership transfers, bulk moderation, and botnet defenses
- A reworked video ownership transfer experience — a proper table UI under My Videos → More → Ownership Changes, notifications when a transfer is requested, accepted, or rejected, and bulk accept/reject actions.
- Bulk accept/reject for registration requests, plus filterable, clickable type and state tags across the job, follow, and registration-request lists.
- Full environment-variable configuration — the entire PeerTube configuration can now be set via environment variables.
- New server plugin hooks.
- New bandwidth-throttling configuration keys —
download.max_total_bytes_per_secondanddownload.max_bytes_per_ip_per_second— added specifically to help instances survive botnets attempting to download their entire video catalog.
8.2.1 — XSS fix
Fixed an XSS vulnerability in the JSON-LD data injected into the video watch page (GHSA-jxwq-h9xv-hr28), and added toot:discoverable support for actors.
8.2.2 — the serious one
- Critical: the actor that signs an ActivityPub activity wasn’t verified against the video’s actual host (GHSA-g9p4-f7h8-hc86).
- High severity: a flaw in how HLS files are proxied from object storage (GHSA-93rr-g3x2-ffv4).
- Several medium-severity fixes and hardening improvements: ZIP export validation, admin-config HTML escaping, and caption file validation.
8.2.3 — continued hardening
The current patch level, continuing the same line of fixes.
Why it matters
The 8.2.2 actor/host verification bug is the one to understand. In ActivityPub, trust is built on signatures: when your instance receives an activity claiming to be about a video, it needs to confirm that the actor who signed that activity actually has authority over that video’s host. Without that check, a hostile instance can assert things about content it doesn’t own — and on a federated platform, that’s a trust-model failure, not just a bug. If your instance was on anything before 8.2.2, treat this as a priority update even though it isn’t brand new.
The bandwidth throttling keys in 8.2.0 answer a very concrete operational problem PeerTube instances have been hitting: botnets that crawl and download an entire video catalog, running up egress costs and saturating the instance for real viewers. On AWS, where data transfer out is a metered line item, this is a direct cost-control lever, not just a performance one.
The ownership transfer rework and bulk registration handling are quality-of-life wins for admins running instances with active contributor communities — both were previously fiddly enough that people avoided them.
What you should do
- Confirm you’re on 8.2.2 or later. Fresh deployments from the pattern are on 8.2.3. If you have an older instance running, the federation trust fix makes this a priority update.
- Set the new bandwidth throttling keys.
download.max_total_bytes_per_secondanddownload.max_bytes_per_ip_per_secondare opt-in — they do nothing until you configure them. Pick limits that comfortably exceed normal viewing patterns but cap catalog-scraping behavior, and revisit them against your actual egress bill. - Review your instance’s egress spend while you’re in there. If you’ve seen unexplained transfer costs, throttling is the mitigation.
- Consider moving configuration to environment variables now that the full config supports it — it makes the pattern’s deployment story cleaner and keeps secrets out of config files.
- Tell your creators about the ownership transfer UI if your instance hosts multiple contributors. The new notifications mean transfers no longer silently sit unnoticed.
Version details in this post come from PeerTube’s own release notes and GitHub security advisories. If you hit anything upgrading the pattern, open an issue on GitHub.
— FOSSonCloud