PeerTube

Federate independent instances with ActivityPub and extend channels into the wider Fediverse

PeerTube is not one central service: independent video hosting providers interoperate as a federation. Published videos can carry descriptions and tags and become discoverable across the video fediverse, not only on the origin instance.

Viewers can follow channels from PeerTube as well as ActivityPub-compatible services such as Mastodon or Pleroma. RSS provides another subscription path, so discovery and following are not locked to one website.

Sources: [2]

Cover VOD, live streaming, embeds, and APIs in one video-publishing platform

Alongside normal video uploads, PeerTube supports live and permanent streams and embeddable players. Administrators can customize the interface and decide how content from other instances is listed or subscribed to.

For integrations, the project publishes an OpenAPI schema for its REST API and ActivityPub documentation, giving custom clients and operational tooling stable extension surfaces.

Sources: [2]

Use WebRTC P2P and inter-instance caching to spread delivery load beyond the origin

Viewers can exchange video data through WebRTC P2P, reducing the bandwidth concentrated on the server during concurrent viewing. Friendly instances can also cache one another's videos as a redundancy mechanism.

Neither mechanism eliminates origin infrastructure or storage. Effectiveness depends on peer participation, NAT and network conditions, and redundancy configuration, so bandwidth and storage still need to be sized for expected viewers and bitrates.

Sources: [2][4]

For communities, education, and independent media that want local governance plus federation

PeerTube fits teams that want to operate a video service per organization or community while still connecting discovery and subscriptions to other PeerTube instances and the Fediverse. It is especially relevant when operators want control over publishing policy, interface, and federation boundaries rather than dependence on one advertising platform or vendor.

Video self-hosting is infrastructure-heavy: plan for FFmpeg, PostgreSQL, Redis, Nginx, storage, and bandwidth

The v8.3.0 dependency guide requires Node.js 22 LTS, pnpm 10+, PostgreSQL 14+, Redis 6.2+, FFmpeg 4.3+, and related system software. The production guide explicitly advises against production deployment behind a low-bandwidth connection.

Transcoding consumes CPU while video media, thumbnails, torrents/HLS, and caches consume storage. A public deployment also needs TLS, reverse proxying, backups, monitoring, SMTP, and capacity management as part of normal video-service operations.

Sources: [5][4]

Upgrading to v8.3.0 requires a manual post-start migration in addition to database migrations

The v8.3.0 release notes warn that startup migrations can take several minutes on databases with many local or federated videos, so operators should plan a short period of downtime.

After the database migration completes and PeerTube is running, an 8.3-specific migration script must also be executed manually. Backups and upgrade rehearsal matter, and plugins or clients that use changed APIs should be included in regression testing.

Sources: [3]

Federation expands reach but also requires explicit inter-instance and moderation policy

Administrators can tune whether videos from another instance are listed while still allowing users to subscribe to them. A decentralized topology does not remove governance work: operators still decide which instances to federate with and which remote content appears locally.

For public communities, terms of use, abuse handling, remote-content policy, and follow/block rules should be designed alongside the technical federation settings.

Sources: [2]

AGPL-3.0 applies; modified network deployments should review source-availability obligations

PeerTube code is published under GNU Affero General Public License v3.0 or later. The AGPL is designed to preserve source availability when modified software is offered as a network service.

The compliance questions differ between running the unmodified project and operating a public fork with custom changes, so organizations maintaining modified deployments should review the AGPL terms before launch.

Sources: [2][6]