PeerTube and the quiet case for a video web that no single company owns

Most video platforms ask you to trust a single company with three separate powers at once: it stores your files, it decides who sees them, and it profits from your attention. PeerTube pulls those powers apart. It is free and open-source software anyone can download, run, and inspect. It is decentralized, meaning there is no central peertube.com where all videos live. And it is federated, meaning the many independent servers running the software can talk to each other and share content, so a viewer on one server can watch, comment on, and follow channels hosted on another.

The meaning packed into free, decentralized and federated

Those three words are doing precise work, and they are worth separating because they are often blurred together. “Free” here refers to freedom rather than price, though PeerTube happens to be both. The code is released under the AGPL-3.0 licence, which means anyone can read it, modify it, and redistribute it, and any modified version deployed as a network service must also publish its source. That licence choice is not incidental. It is a legal guarantee that PeerTube cannot quietly become a closed product later, because the terms travel with every copy.

“Decentralized” means the platform is a network of separate installations, each called an instance. An instance is a normal website with its own address, its own administrator, its own registration rules, and its own moderation policy. A university can run one. A film collective can run one. A single person with a cheap server can run one. None of them depends on Framasoft, the French non-profit that develops the software, to keep operating. If Framasoft disappeared tomorrow, every existing instance would keep serving its videos.

“Federated” is the part that turns a scattered set of servers into something that feels like a network. PeerTube uses the ActivityPub protocol, the same standard that connects Mastodon, to let instances subscribe to each other. When one instance follows another, new videos from the followed instance appear in the follower’s interface, even though the video file itself never moves. The bytes stay on the origin server; what travels between instances is the metadata and the social layer of follows, comments, and likes.

The practical consequence is a video web with a very different shape from YouTube. On YouTube, one company sets the recommendation algorithm, the advertising rules, the monetization thresholds, and the content policy for billions of videos. On PeerTube, each instance sets those things for its own corner, and there is no engagement-maximizing algorithm ranking videos to keep you watching. Videos surface chronologically or by category, not by predicted watch time. That design choice is central to how Framasoft describes the project: it treats a viewer as a person to inform rather than a profile to sell.

It helps to be clear about what PeerTube is not. It is not a company, not a single website, and not an attempt to become the next global monopoly. Framasoft has said plainly that replacing YouTube was never the goal. The aim is to offer something structurally different that runs in parallel, for people and organizations who want control over how their video is hosted, moderated, and shown. That framing matters for judging the project fairly. Measured as a would-be YouTube killer, PeerTube looks small. Measured as public-interest infrastructure that gives communities a way to publish video on their own terms, it looks like one of the more durable experiments the open web has produced. The rest of this analysis takes the second measure seriously while being honest about the limits that come with it.

The origin story from a solo developer to a Framasoft project

PeerTube did not start as an institutional project. It began with one developer, known publicly by the handle Chocobozzz, who set out to build a peer-to-peer alternative to YouTube. The earliest prototype used WebTorrent, a way to run BitTorrent-style transfers directly inside a web browser, so that viewers watching the same video could share pieces of it with each other and reduce the load on the hosting server. The logic behind that choice reveals the founding problem PeerTube exists to solve: a single organization cannot afford the bandwidth and storage needed to host video for a mass audience, so a free alternative to the video giants has to spread that cost across many machines rather than concentrate it in one place.

In 2017, Framasoft contacted Chocobozzz. The non-profit was running a multi-year programme called Contributopia, aimed at building ethical alternatives to the centralized services people had grown dependent on. Rather than commission a new project from scratch, Framasoft chose to support work already underway. It hired the developer to keep building PeerTube full time, with attention to design and usability, areas where a solo technical project often struggles. That decision set the pattern that still defines the project: a very small paid team, heavy reliance on outside contributors, and an organization whose mission is education about digital freedom rather than growth for its own sake.

Money for the first stable release came from the crowd. In 2018, Framasoft launched a campaign on the French platform KissKissBankBank with a goal of €20,000. It raised €53,100, more than double the target, a signal that appetite for a non-corporate video platform was real even if the audience was niche. The first public beta arrived in March 2018, and the first stable version, PeerTube 1.0, in October 2018. The response was quick for a project of its size. By June 2018, only a few months after the beta, 113 instances were publicly reachable, together hosting more than 10,000 videos.

A concrete early adopter showed why the idea resonated. In June 2018, the Blender Foundation, the organization behind the open-source 3D software, began experimenting with a PeerTube instance to distribute copies of its videos, prompted in part by its content disappearing amid changes to how YouTube monetized channels. That episode captured the core anxiety PeerTube speaks to: creators who build an audience on a platform they do not control can lose their work, their reach, or their income overnight when the platform changes its rules. A federated model where you can run your own server, or trust a community that does, is a hedge against that risk.

The project’s trajectory since then has been steady rather than explosive. There was no venture funding, no aggressive user acquisition, no pivot toward advertising. Development advanced version by version, paid for by a mix of donations and grants, with periodic crowdfunding campaigns tied to specific goals such as live streaming or the mobile app. That slow, deliberate pace is part of the story. It explains both why PeerTube has survived for years where flashier alternatives folded, and why it still lacks some of the polish and reach that a well-capitalized company could have delivered in a fraction of the time. The origin as a passion project absorbed into a mission-driven non-profit continues to shape everything about how PeerTube is built and how fast it can move.

Framasoft, the non-profit that steers the project

To understand PeerTube’s decisions, you have to understand who makes them. Framasoft is a small French non-profit association, founded to promote free software and its culture to a French-speaking audience, and it has been doing that work for over two decades. It describes itself as a popular-education organization focused on digital issues, and PeerTube is only one item in a long catalogue of projects. The association runs around twenty free web services under its Dégooglisons Internet (“De-google-ify the Internet”) campaign, which offers alternatives to the tools of the large platforms, and by its own account it helps roughly two million people a month move away from Big Tech services.

The scale of the organization is worth stating plainly, because it reframes everything the project does. Framasoft has run with about ten employees and roughly twenty-five volunteers across all its work. PeerTube itself, one of the most technically ambitious things the association makes, has for most of its life been developed by a single full-time employee with help from volunteers. That changed only recently, when Framasoft hired a second developer, Wicklow, to work on the mobile application, doubling the paid PeerTube workforce to two. When you weigh PeerTube against YouTube, Vimeo, or Rumble, this is the comparison that matters most. One of these is maintained by a two-person core team inside a non-profit; the others are built by hundreds or thousands of engineers backed by advertising revenue or investment capital.

Framasoft’s governance also shapes the product in ways that are easy to miss. The association operates with co-directors rather than a single chief executive, and it has publicly resisted the binary, purist streak that sometimes runs through free-software activism. In interviews, its representatives have distanced the group from the attitude that using any mainstream tool makes someone a bad person, and have acknowledged the Western biases baked into a lot of tech counterculture. That posture translates into product choices. PeerTube includes a tool to synchronize a channel automatically from YouTube or Vimeo, which a stricter organization might have refused to build on principle. Framasoft built it because it lowers the barrier for creators who want to move without abandoning the audience they already have.

The funding structure reinforces the independence. Framasoft states that roughly 75 percent of its funding comes from grassroots donations spread across its fifty-plus projects, with the remainder from grants. Because the money is not tied to advertisers, shareholders, or a single large sponsor, the association can make decisions that would be commercially irrational, such as refusing to add tracking, declining advertising entirely, and keeping the software free for anyone to run. It also means the project is perpetually under-resourced relative to its ambitions, which is the honest counterweight to its independence.

There is a deliberate political stance underneath all of this. Framasoft frames the concentration of the web in a handful of American platforms as a symptom of what it calls surveillance capitalism, and it positions its tools as small “bubbles of freedom” outside that system. Whether or not you share that framing, it explains the consistency of PeerTube’s choices across its history. Every major decision, from the licence to the absence of an algorithm to the reliance on donations, follows from a view that video hosting should be a commons that communities govern, not a product a company sells. That is the lens through which the technical architecture, examined next, was designed.

The federation model explained without the jargon

Federation is the idea that makes PeerTube more than a pile of disconnected websites, and it is worth walking through carefully because it is the source of both the platform’s strengths and its most persistent frustrations. Start with the basic unit: the instance. An instance is a single installation of the PeerTube software running on a server somewhere. It behaves like an ordinary website. People visit it, browse videos, create accounts if the administrator allows registration, and upload their own videos into channels they control. Each instance has an administrator who sets the rules: who can register, how much storage each user gets, what content is allowed, and crucially, which other instances this one will connect to.

That last power is where federation begins. One instance can choose to follow another. When it does, it subscribes to that instance’s videos, and new uploads from the followed instance appear in the following instance’s listings. The key detail is that following is asymmetrical. Instance A can follow Instance B to display B’s videos without B having to follow A back. This is unlike a mutual friendship and more like a subscription. An administrator builds up the catalogue their community sees by choosing which instances to follow, and they can stop following at any time.

The mechanics of what actually moves between servers surprise people. When Instance A follows Instance B and a viewer on A watches one of B’s videos, the video file itself stays on B. Federation passes the metadata, the title, description, thumbnail, and the location of the video, along with the social interactions, but not the underlying media. The viewer’s browser eventually fetches the video from the instance that hosts it. This keeps the storage burden with the origin server and avoids endlessly copying large files across the network, though it also means that if the origin instance goes offline, its videos become unavailable everywhere, since no one else holds a full copy by default.

Federations form when several instances with compatible rules follow each other, creating clusters of shared content. A group of instances that all host, say, science communication might follow one another so their communities can discover each other’s work. These federations are independent and can overlap. There is no master list every instance must join, and no central authority that can force one instance to carry another’s content. An administrator who wants a tightly curated, safe environment can follow only a handful of trusted instances, or none at all, and run a completely standalone island. An administrator who wants maximum reach can auto-follow broadly and accept whatever comes in.

This is the governance model that federation really delivers, and it is more interesting than the technology. Moderation is distributed rather than centralized. No single company decides what is acceptable across the whole network. Each administrator moderates their own instance and decides which other instances to trust. When an instance hosts content a community finds unacceptable, other instances can defederate, cutting the connection so that offending content no longer appears in their listings. This gives communities real control over their own space. It also creates the coordination problems examined later, because harmful content on one poorly moderated instance can still reach viewers on others until administrators notice and block it.

The mental model that works best is email. Nobody owns email. Countless independent mail servers run compatible software and exchange messages using shared protocols, and you can send a message from your provider to someone on a completely different one. PeerTube aims to be that for video: a shared protocol, many independent operators, and content that flows between them without anyone sitting in the middle. The comparison also flags the weakness. Email’s openness is exactly what makes spam and abuse hard to stop, and federated video inherits a version of the same tension between openness and control.

ActivityPub and the Fediverse connection to Mastodon

The protocol underneath PeerTube’s federation is ActivityPub, a standard published by the World Wide Web Consortium for decentralized social networking. It is the same protocol that powers Mastodon, Pixelfed, and a growing set of other services collectively known as the Fediverse, short for federated universe. Because PeerTube speaks ActivityPub, it is not an isolated video network but a video-shaped participant in a much larger social web. This is one of the project’s genuinely distinctive advantages, and it is easy to underrate until you see it working.

Here is what that interoperability looks like in practice. A Mastodon user can follow a PeerTube channel directly from their Mastodon account, without creating a PeerTube account at all. When that channel publishes a new video, it appears in the Mastodon user’s timeline as a post. If the Mastodon user replies to that post, the reply shows up as a comment on the video’s page in PeerTube. Interactions flow across the boundary between two entirely different applications built by different teams, because they share a protocol. It is one of the clearest demonstrations anywhere of what federation is supposed to achieve: a social layer that is not trapped inside a single app.

The technical implementation is more careful than the friendly description suggests. PeerTube uses the server-to-server side of ActivityPub. Each instance has a dedicated actor that announces new videos so that following instances are notified. A video is uploaded by an account, which is itself an actor, and it is also announced by the channel it lives in. Remote actors can follow the account or the channel to be notified of new videos. Messages between servers are signed with HTTP Signatures using the private key of the account that sent them, so a receiving instance can verify that a message genuinely came from where it claims. Failed requests are retried several times, which matters on a network of independently run servers with uneven uptime.

The payoff of building on an open standard rather than a private protocol is resistance to vendor lock-in and to censorship. Because no company owns ActivityPub, no company can revoke access to it, change its terms, or shut it down. A creator’s channel is addressable and followable from any compatible service, which means their audience is not held hostage inside one app. If a creator’s instance becomes unwelcoming, they can move to another instance, and while the migration is not perfectly smooth today, the underlying design assumes portability rather than capture.

There are limits to the interoperability that honesty requires stating. Following a PeerTube channel from Mastodon works well, but the reverse experience, discovering and navigating PeerTube’s full catalogue from inside another Fediverse app, is uneven. Different services implement ActivityPub with different emphases, and video is heavier and more complex than the short text posts Mastodon was built around. Some interactions degrade gracefully across the boundary and some do not. The protocol guarantees that basic follows and comments can cross between services; it does not guarantee that every feature of one app is legible inside another.

The strategic point is that PeerTube’s bet is tied to the health of the whole Fediverse, not just to its own adoption. Every new Mastodon user is a potential PeerTube viewer without any additional signup. Every improvement to ActivityPub tooling benefits video alongside microblogging. As the Fediverse has grown, particularly during the periods when users left centralized platforms in waves, PeerTube gained a distribution channel it did not have to build itself. That shared fate cuts both ways, since the Fediverse remains far smaller than the platforms it competes with, but it means PeerTube is not fighting for relevance alone. It is one organ in a larger body of interoperable, community-run services that rise and fall together.

Peer-to-peer playback and the move from WebTorrent to HLS over WebRTC

The “peer” in PeerTube points to a technical idea that sets it apart from almost every other video platform: viewers can help deliver the video to each other. The problem this solves is bandwidth. When a video suddenly becomes popular, the server hosting it faces a spike in demand that a small operator cannot afford. Peer-to-peer delivery spreads that load. While you watch a video, your browser can share the chunks it has already downloaded with other people watching the same video at the same time, so the origin server does not have to send every byte to every viewer.

PeerTube’s approach to this has evolved significantly, and the history matters because it explains some confusion that still circulates. In the early years, PeerTube used WebTorrent, an implementation of the BitTorrent protocol that runs inside a web browser. Each server hosted a torrent tracker, and each browser viewing a video also seeded it to others. It was an elegant fit for the founding vision, but it carried real costs. WebTorrent required storing video in a particular way, and supporting it alongside the newer delivery method meant keeping two encoded copies of every video, which roughly doubled storage requirements.

With the release of version 6.0.0, PeerTube removed the legacy WebTorrent path and standardized on a different technique: HLS with peer-to-peer over WebRTC. HLS, or HTTP Live Streaming, is the widely used standard that breaks a video into small segments and lets a player fetch them at whatever quality the viewer’s connection can handle, which is why quality adapts smoothly as your bandwidth changes. Normally HLS has no peer-to-peer component; the player simply downloads segments from a web server. PeerTube extended it with a custom loader that simultaneously pulls video chunks from the web server and from other viewers via WebRTC, the browser technology for direct peer connections. The result keeps the adaptive-quality benefits of standard HLS while adding the load-spreading benefit of peer delivery.

The engineering reasoning behind the switch was pragmatic rather than ideological. The HLS-based player gives a better viewing experience, supports the adaptive streaming that modern audiences expect, and lets an instance store a single set of files instead of two. PeerTube’s own documentation recommends enabling HLS and, unless there is a specific reason otherwise, disabling the old Web Video path to avoid doubling storage. WebTorrent compatibility still lingers in the system for those who want it, but it is discouraged, and the practical default across the network today is HLS with optional P2P.

Peer-to-peer delivery comes with a privacy trade-off that deserves to be stated clearly rather than buried. WebRTC works by exchanging connection information between peers, and that information can include IP addresses. When two viewers share chunks of the same video directly, each can in principle see the other’s network address. For most public content this is a minor concern comparable to countless other web interactions, but for sensitive or private videos it is a real consideration. This is why careful instance operators disable peer-to-peer on private and unlisted videos, so that watching a restricted video does not expose viewers to one another. It is also why viewers who prefer not to contribute bandwidth or reveal their address to other peers can opt out of P2P sharing.

The honest assessment is that peer-to-peer playback is more useful in theory than it usually is in practice, and PeerTube’s own trajectory reflects that. The technique genuinely helps during traffic surges, when many people watch the same thing at once, which is exactly the moment a small server is most at risk. For the long tail of videos with a handful of viewers spread across time, there are rarely enough simultaneous peers for P2P to matter, and the heavy lifting falls back to the server and to the mirroring system covered next. Peer delivery is best understood as one tool for bandwidth resilience rather than the magic that lets a hobbyist server carry YouTube-scale traffic. It lowers the ceiling on cost during spikes; it does not remove the need for real infrastructure.

Inside a PeerTube instance, from upload to transcoding to delivery

Following a single video from upload to playback is the clearest way to see how an instance actually works, and it exposes where the real costs and failure points sit. The client you interact with in a browser is a single-page web application written in TypeScript on the Angular framework. The server is a Node.js application that now requires a recent version of the runtime, backed by a PostgreSQL database that stores metadata: accounts, channels, video records, comments, follows, and the state of every background job. The video files themselves live on disk or in object storage, not in the database.

When someone uploads a video, the instance does not simply save the file and serve it back. It runs the file through transcoding, the process of converting it into the formats and resolutions needed for reliable playback. A phone might upload a large file in a codec that many browsers cannot play smoothly, so the instance re-encodes it into web-friendly formats and generates multiple resolution variants, for example 240p, 360p, 480p, 720p, and 1080p, so the adaptive HLS player can switch between them based on the viewer’s connection. Transcoding is done with FFmpeg, the standard open-source media tool, and it is by far the most demanding thing an instance does.

The cost of transcoding is the single most important practical fact about running PeerTube, and new operators consistently underestimate it. Producing a default ladder of resolutions can take on the order of 1.5 to 3 times the video’s duration per resolution on a single CPU core. Encoding a ten-minute video into five resolutions can therefore occupy a processor for a long stretch, and if transcoding runs on the same machine that serves the website, a busy upload queue can saturate the CPU and degrade playback for everyone. This is why experienced administrators enable only a few resolutions at first, cap concurrent transcoding jobs to match real hardware, and expand carefully rather than switching on every option at launch.

PeerTube’s answer to the transcoding bottleneck is remote runners, introduced in the version 6 era and extended since. A runner is a separate program that connects to the instance over HTTP and WebSocket and takes on transcoding jobs, and it does not need a public IP address. This means an administrator can offload the CPU-intensive work to a different server, or even a spare computer at home, keeping the main instance responsive while heavy encoding happens elsewhere. The same runner system was later extended to automatic transcription using Whisper-based speech recognition, so instances can generate subtitles without adding that load to the main server. For an organization running many uploads, the ability to scale transcoding horizontally across runners is one of the more important operational features PeerTube offers.

Once a video is transcoded, the state is written back to the database, the file is optionally moved to object storage if the instance is configured to use it, and the video is dispatched to the instance’s ActivityPub followers so it appears on federated servers. Object storage matters more than it sounds. Video storage grows faster than almost anyone expects, and running out of disk on a single server is one of the most common early failures. Moving files to a dedicated storage bucket separates the growing pile of media from the server that runs the application, which keeps the instance manageable as its catalogue expands.

At playback time, the viewer’s HLS player fetches the video’s manifest and begins pulling segments, drawing them from the web server and, when enabled and when other viewers are present, from peers over WebRTC. The player itself has grown into a capable piece of software over successive versions, with chapters, hover previews from storyboards, subtitle support injected into the HLS playlists so external players can find captions, and a redesigned interface. Most breakage on PeerTube happens in the middle of this pipeline, between upload and finished playback, usually when a file is too large to transcode within limits, when file permissions are wrong, or when a job fails silently and leaves a video stuck. Understanding that the hard part is the transcoding-and-storage middle, not the federation, is the key to running an instance that actually works.

Server redundancy and how instances share the load

Peer-to-peer delivery from viewers’ browsers helps during traffic spikes, but it is not enough on its own to keep a popular video available, because it depends on enough people watching at the same moment. PeerTube’s second and more reliable answer to bandwidth pressure is server redundancy, sometimes called mirroring. This is the feature that turns federation from a discovery mechanism into a genuine resilience mechanism, and it is one of the more clever parts of the design.

Redundancy works like this. An instance administrator can choose to mirror videos from other instances they follow, caching copies on their own server. When PeerTube selects a video to duplicate, it imports all of that video’s resolution files to keep them consistent, stores them in a dedicated redundancy directory, and then sends a message across the federation announcing that it now holds a cached copy. That cached instance is injected as an additional source, a web seed, so that players can pull the video from the mirror as well as from the origin. The effect is that a video hosted on a small, low-bandwidth instance can be served in part by larger instances that have chosen to mirror it.

Administrators control how mirroring behaves through redundancy strategies. They can choose to cache trending videos, or recently uploaded videos, or the content of specific instances they want to support, and they set a maximum size for their redundancy cache and a minimum lifetime for cached copies so that files are not churned constantly. A well-resourced instance can act as a good neighbor, lending its uplink to smaller instances whose communities it wants to help. This creates a genuine incentive to build communities of shared bandwidth, where instances mirror each other’s popular content and no single small server has to absorb a viral moment alone.

The limitation is that redundancy is opt-in and depends on the goodwill and spare capacity of other operators. There is no guarantee that anyone will mirror a given instance’s videos. A small instance with no mirroring relationships is on its own when one of its videos gets attention, relying on its own bandwidth and whatever transient help peer-to-peer viewers provide. The redundancy system rewards instances that are well connected within active federations and offers little to isolated ones. It is a cooperative solution that works best when there is a healthy community of instances willing to cooperate, which is exactly the condition PeerTube cannot manufacture on demand.

Redundancy also has a preservation dimension that is easy to overlook. Because mirroring creates full copies of a video on multiple servers, a mirrored video survives the disappearance of its origin instance in a way an unmirrored one does not. In a network where instances are run by individuals and small groups, servers do shut down, and when they do their unmirrored videos vanish. Mirroring is therefore not only about bandwidth but about durability, offering a partial hedge against the fragility of a network built from many small, independently operated pieces. It does not solve the fragility entirely, since mirroring is selective and not automatic, but it means the most-watched content on an active federation is meaningfully more resilient than a naive view of decentralization would suggest.

Sepia Search and the discovery problem

The greatest weakness users report about PeerTube is not the technology or the philosophy but something much more mundane: finding things is hard. On YouTube, a single search box queries one enormous index and returns results ranked by an algorithm trained on billions of interactions. On a federated network, there is no single index by default. Each instance knows about its own videos and the videos of the instances it follows, which means the same search on two different instances can return completely different results, and neither one sees the whole network. For a newcomer expecting Google-like search, this is disorienting, and it is the most common reason people bounce off the platform.

Framasoft’s answer is Sepia Search, a meta-search engine launched at the end of 2020 that queries videos across participating instances at once. It works from an index that Framasoft maintains, covering the instances listed in the public instance directory, and it gives users a way to search a large slice of the network from one place. When it launched, the index already covered close to 800 instances, and it has grown alongside the network. Sepia Search is deliberately built as an open interface between instances and search indexes, so that other search engines can implement the same standard rather than depending on Framasoft’s index alone.

The design of Sepia Search reflects PeerTube’s values in a way that also constrains it. Framasoft’s public index is not moderated for content quality or ranking, and the project openly recommends that instance administrators run their own moderated index rather than relying on the central one. This is consistent with the anti-centralization philosophy: Framasoft does not want to become the arbiter of what is findable across the whole network, because that would recreate exactly the kind of central gatekeeper the project exists to avoid. The cost is that the search experience is thinner than users are used to, without the aggressive relevance tuning and personalization that a commercial engine provides.

Instances can also enable global search directly in their own interface, pointing at a remote search index so their users get results from instances that may not even be federated with them. And there is a mechanism for fetching a specific remote video or channel by its address, so if you know the handle of a channel on a distant instance, you can pull it into your own instance and follow it even without a prior federation relationship. These tools stitch the network together for people who know how to use them, but they require a level of understanding that a casual viewer does not have and should not need.

The community has tried to fill the gap with its own experiments. There are Mastodon accounts dedicated to surfacing PeerTube videos and creators, acting as human-curated discovery feeds. There is a browser add-on called PeerTube Picks that implements a basic personalized recommendation layer, which some users credit with helping them find channels they would otherwise have missed. Multi-platform clients such as Grayjay and privacy-focused front-ends such as NewPipe can pull PeerTube content alongside other sources, giving users another route in. These are useful, but they are also a sign of the underlying problem: discovery on PeerTube is a patchwork of partial solutions rather than a single reliable system.

The discovery problem is not a bug that a future release will simply fix, because it is entangled with the architecture. A truly comprehensive, well-ranked, personalized search across all instances would require either a central index with real ranking power, which cuts against decentralization, or a genuinely distributed search protocol that no one has yet built at the necessary quality. PeerTube has chosen to lean toward decentralization and accept weaker discovery as the price. For communities that arrive with an existing audience, through a Mastodon following or a link from elsewhere, this matters less, because they do not rely on organic search to reach viewers. For anyone hoping to be discovered by strangers the way YouTube’s algorithm surfaces new creators, the discovery gap remains the platform’s most serious practical shortfall.

The release history that turned a prototype into a platform

PeerTube’s development reads as a slow accumulation of capability, each version closing a gap between a promising prototype and software an organization can rely on. The 1.0 release in October 2018 established the core: federated instances, uploads, channels, and the early WebTorrent-based delivery. Over the following two years the project added the pieces a real platform needs. Through the second half of 2020, PeerTube shipped global search, improved playlists, and stronger moderation tools, and at the end of that year Framasoft launched Sepia Search. The 2020 roadmap was backed by a fundraising campaign seeking €60,000, which the project reached after a €10,000 donation from Debian, a notable vote of confidence from a major open-source institution.

Version 3.0, announced in January 2021, added the feature that pushed PeerTube toward live use cases: peer-to-peer live streaming. This let instances host live broadcasts using the same load-spreading approach as recorded video, opening the door to streamed conferences, community events, and real-time broadcasts without depending on a commercial streaming service. Live streaming has since been refined to support saving replays, live transcoding into multiple resolutions, and, in later versions, scheduling a broadcast in advance with a placeholder page. The trade-off is that live transcoding is even more CPU-hungry than recorded video, since it happens in real time, so the number of simultaneous streams an instance can handle is tightly bound to its hardware.

The years that followed brought a run of grant-funded improvements that are less glamorous than live streaming but arguably more important for serious adopters: two-factor authentication, remote transcoding, a user data export and import tool, comment moderation, better statistics and telemetry, accessibility work, and a plugin API rich enough to support an ecosystem of extensions. Much of this was financed through NGI0 grants managed by the NLnet foundation, part of a European Commission programme to support the open internet. That funding paid for exactly the kind of infrastructure work that is hard to sell through a crowdfunding campaign, because donors respond more readily to visible features than to security hardening and API design.

PeerTube release milestones

The table shows the shape of the project’s momentum: a foundational release, a live-streaming leap, a feature-rich version 6, a design-led version 7 line, the arrival of official mobile apps, and a version 8 that opened the software to teams rather than lone creators. The pace accelerated once Framasoft added design and mobile expertise from outside partners.

Two organizational shifts underlie the recent acceleration. First, Framasoft brought in the design cooperative La Coopérative des Internets to overhaul the interface, which is why the version 7 line focused so heavily on usability rather than raw features. Second, the hiring of a second developer for the mobile app meant that, for the first time, the desktop platform and the mobile client could advance in parallel instead of competing for one person’s time. The through-line across all of it is that PeerTube has matured without changing its fundamental character. It added the features a credible platform needs while refusing the features that would have compromised its independence, and it did so on a budget that would be a rounding error at any of its commercial competitors.

Version 6 and the features YouTube still does not offer

PeerTube 6, released in late 2023, is worth singling out because it did something a scrappy alternative rarely manages: it shipped features that the platform it competes with does not have, rather than merely catching up. Framasoft described it as the most ambitious release since peer-to-peer live streaming, and much of what it added came directly from user suggestions rather than a product roadmap dreamed up in isolation. The result was a version that gave creators specific, concrete reasons to prefer PeerTube for certain jobs, even while accepting that it would never match YouTube’s reach.

The headline feature was password-protected videos. A creator can lock a video behind a password, so only people who have it can watch. This sounds simple, but it fills a real gap. A creator who wants to share a video with paying supporters, a private group, or a limited audience has no clean way to do that on YouTube, where the choices are essentially public, unlisted, or private-to-specific-accounts. Password protection gives PeerTube a clear use case where it is genuinely better than the dominant platform, and it reframes the comparison usefully: for a video meant for fifty specific people, YouTube’s billion-strong audience is not a relevant advantage at all.

Version 6 also introduced the ability to upload a new version of an existing video. On YouTube, replacing a video means deleting the old one and uploading a new file, which resets the URL, the view count, the comments, and the video’s history. PeerTube 6 let creators swap the underlying file while keeping the same URL, title, comments, and statistics, so a creator who spots a mistake can fix it without losing everything attached to the original. Because this feature could be abused to bait-and-switch an audience, it requires trust between the creator and the instance administrator, it is not enabled by default, and updated videos display a re-upload tag so viewers know the file has changed.

Two more additions brought the viewing experience closer to what audiences expect from a modern platform. Storyboards generate a filmstrip of thumbnails so that hovering over the progress bar shows a preview of the frame at that point, letting viewers scrub through a video quickly to find a moment. Chapters let creators divide a video into titled segments, which is especially useful for long talks and tutorials, and PeerTube can even detect and import chapters automatically when a video is brought in from another platform. These are quality-of-life features rather than breakthroughs, but they close the gap between PeerTube’s player and the commercial standard, removing reasons a viewer might find the experience unfamiliar or frustrating.

Underneath the visible features, version 6 also carried technical work that mattered more than it looked: optimized database queries, the option to turn off HTTP logs, and preparation for larger-scale stress testing. The project had already run a stress test with over 400 simultaneous viewers and planned tests simulating up to a thousand, aiming to find performance bottlenecks and tune server configurations. This is the unglamorous engineering that determines whether an instance stays responsive under real load, and its inclusion alongside the crowd-pleasing features signaled a project thinking about reliability, not just capability. Version 6 was the release where PeerTube stopped feeling like a compromise you accept for the sake of principle and started feeling, in specific situations, like the better tool.

The 2025 redesign and the version 7 line

If version 6 was about features, the version 7 line in 2025 was about usability, and it addressed a criticism that had dogged PeerTube for years: that it was powerful but awkward, built by engineers for people comfortable with engineering. Framasoft brought in an outside design partner, La Coopérative des Internets, to rethink the interface, and the version 7 releases show the influence of that collaboration throughout. The stated goal was not just a prettier interface but one that is simpler, easier to understand, and more accessible, which for a platform hoping to reach beyond technically confident users is the difference between growth and stagnation.

PeerTube 7.2, released in mid-2025, delivered a complete overhaul of the video-management interface. The old infinite-scroll approach to browsing your own videos was replaced with a clearer pagination system, and creators gained the ability to customize which columns they see, such as channel, duration, views, publication date, and whether a video has comments. New filtering tools let creators and administrators narrow their videos by visibility, by whether they are live streams, whether they are password-protected, or whether they are on-demand content. The video publishing and editing pages were reorganized into navigable sections through a side sub-menu, replacing a single sprawling form with something a person can actually work through.

The same release tackled the genuinely hard problem of sensitive content with more care than most platforms manage. Rather than a blunt binary flag, PeerTube adopted a system closer to Mastodon’s content warnings, letting a creator give a reason why they judged a video to deserve a warning. The reasoning Framasoft offered is worth noting: the notion of sensitive content varies enormously between people and cultures, and an overly rigid system either over-warns and drives viewers away or under-warns and exposes them to things they did not want to see. Letting creators explain the warning, and letting viewers set their own preferences for how sensitive videos are displayed, treats both sides as capable of judgment rather than imposing one global standard.

PeerTube 7.3, released in October 2025, turned attention to administrators. The horizontal admin menu was replaced with a navigation sidebar, and a new personalization page let administrators change the main colors and shapes of the interface with a few clicks, so an instance could replace PeerTube’s signature orange with its own brand color without editing configuration files. A dedicated logo configuration page centralized management of the header icon, favicon, banner, and social-media preview image. A setup wizard now guides administrators through the first steps after installing an instance, letting them pick a preset based on whether they are running a private, community, or institutional platform. Version 7.3 also added scheduled live broadcasts with a placeholder page and notification, a redesigned playlist system, and a session dashboard where users can see and forcibly close their active login sessions.

The cumulative effect of the version 7 line is a platform that is noticeably less intimidating to run and to use than it was a few years earlier. None of these changes is dramatic in isolation, and none of them expands what PeerTube can technically do. What they do is lower the effort required at every step, from a first-time administrator setting up an instance to a creator managing a growing catalogue to a viewer deciding whether to watch a flagged video. For a project whose adoption ceiling has always been set more by friction than by capability, the design investment of 2025 may prove more consequential than any single feature.

Version 8 and the shift toward team-managed channels

PeerTube 8, released in December 2025, marked a shift in who the software is built for. The earlier versions assumed a model where one person owns a channel and does everything, which fits a solo creator but breaks down for organizations. A newsroom, a university department, a conference, or a media collective does not have a single person who uploads, edits, moderates, and manages a channel. Version 8 recognized that reality and began building for teams rather than individuals, which is a meaningful signal about the kind of adopter Framasoft now sees as central to the platform’s future.

The most consequential addition was collaborative channel management, the ability to share management of a channel with other accounts. Before this, a channel was bound to a single account, so an organization either shared login credentials, which is insecure and unaccountable, or funneled everything through one person, which is a bottleneck. Version 8 let multiple accounts manage a channel together, so a team can divide the work of uploading, editing metadata, and responding to comments while each member keeps their own identity. For any adopter larger than one person, this is the feature that makes PeerTube workable, and its absence had quietly excluded a whole category of potential users.

Version 8 also redesigned the video player, continuing the usability push of the version 7 line, and improved the import system for bringing in videos from elsewhere. Import matters because it is the practical mechanism by which a creator migrates to PeerTube. A smoother import path, combined with the existing ability to synchronize a channel automatically from YouTube or Vimeo, lowers the cost of moving. The player redesign brought features and a stats panel that surfaces technical details, including viewer telemetry, in a way that is available to the curious without cluttering the main interface. These are refinements rather than reinventions, but they reflect a project that has moved past proving the concept and into polishing the experience.

The version 8 series is also where PeerTube’s growing surface area started to show its costs. As the platform accumulated features, the plugin ecosystem faced compatibility strain. Extensions written against older APIs sometimes break on upgrades, and the transition through the version 7 and version 8 releases deprecated some paths that community plugins relied on, such as changes to how captions and storyboards are handled and to the plugin API itself. This is the ordinary tax of a maturing platform, but it lands hard on a project with a small core team and a volunteer-driven extension catalogue, because there is limited capacity to help plugin authors keep up. Administrators who depend on specific plugins learned to pin tested versions and stage upgrades rather than updating blindly.

Taken together, versions 6, 7, and 8 describe an arc. Version 6 proved PeerTube could offer things YouTube does not. Version 7 made the software approachable. Version 8 made it usable by teams and organizations. Each step widened the pool of realistic adopters: from principled early users, to creators willing to try something new, to institutions that need collaboration and reliability. That progression, more than any single feature, is what has kept PeerTube relevant while other decentralized video projects stalled or disappeared. The direction of travel is unmistakable, even if the destination, a video platform that meaningful numbers of organizations depend on, is still some distance away.

The mobile app and the push to put PeerTube in a pocket

For most of its life, PeerTube had a serious blind spot: video is consumed overwhelmingly on phones, and PeerTube had no official mobile app. There were third-party clients of varying quality, but nothing from Framasoft, which meant the default mobile experience was a website in a browser. For a platform trying to reach beyond a technical audience, this was a major gap, because a smooth app is what most people expect from a video service and its absence signaled, fairly or not, that PeerTube was not for them.

Framasoft moved to close that gap, and the effort became the focus of its 2025 crowdfunding campaign. The campaign was structured around funding goals, each unlocking concrete app improvements rather than vague promises. The first goal, at €15,000, covered background playback, TV casting, push notifications, and video-quality selection. The second, at €35,000, funded channel management, video editing tools, detailed content statistics, and mobile uploads. Higher goals extended toward more ambitious features and general support for Framasoft’s wider mission. The campaign reached €55,000, enough to fund the improvements the team wanted to make that year, and Framasoft was explicit that it would build the planned features regardless, treating the campaign partly as a gauge of public enthusiasm, especially in the English-speaking world it was trying to reach.

The app itself arrived in stages. Framasoft published the first version of the PeerTube mobile app for Android and iOS, and roughly four months later presented what it called version 1, the work of the newly hired developer Wicklow, shaped heavily by user feedback. The Android app is available on both F-Droid and Google Play, with the F-Droid build allowing access to any instance and the store build oriented toward a broader default experience. The iOS app is on the Apple App Store but, notably, offers content from a narrow, selected list of instances rather than the whole network. That difference is not a design preference but a consequence of platform politics, discussed below.

The app lets a user browse and watch videos from across the federated network in one interface, follow channels, build playlists, resume playback, and download videos for offline viewing. Later updates through the version 2 line added a creator mode for managing and uploading videos from a phone, tablet support, background playback, and improved playlist management. The design philosophy carried over from the web platform: the app is built to help people discover and watch video without the attention-engineering that mainstream apps use to maximize time on screen. It is a video app that is not trying to trap you, which is either its main appeal or a competitive handicap depending on your point of view.

Publishing the app was harder than building it, and the difficulty is revealing. Framasoft has described getting a Fediverse video app onto the major app stores as an obstacle course, because the stores enforce strict policies around video content, particularly content generated or broadcast by third parties that the app developer does not control. A federated app that can reach the whole network can, by definition, surface content the developer has never seen, which collides with app-store rules designed for centralized services that police their own content. This is why the iOS app ships with a curated instance list: it is a compromise that lets the app exist within Apple’s rules at the cost of the openness that is the whole point of federation.

The mobile push is the clearest evidence of Framasoft’s current strategy, which is to reduce friction rather than add capability. The platform is already technically capable; what has held it back is that using it required more effort and more understanding than most people will invest. A polished app that lives on a phone’s home screen removes one of the largest remaining barriers. Whether it is enough to move PeerTube from niche to merely small is unproven, but it is the right target. The app store constraints, meanwhile, are a reminder that even a decentralized platform must pass through centralized chokepoints to reach ordinary users, and those chokepoints do not bend for anyone’s principles.

The May 2026 security incident and what it revealed

Software that runs on thousands of independently administered servers is a large attack surface, and in 2026 PeerTube learned that lesson in public. The releases around version 8.1.6 through 8.1.8 were emergency security updates responding to a SQL-injection vulnerability that, according to Framasoft’s own investigation, had been exploited at scale since at least May 18, 2026, before the fixing release was available. The incident is worth examining not to alarm anyone but because it exposes real trade-offs in the decentralized model that boosters tend to gloss over.

The mechanics of the attack were specific and instructive. The attacker used the SQL-injection flaw to generate an authentication token for the root user on vulnerable instances, then used that access to install a malicious plugin disguised as a Google Analytics integration. The plugin loaded a script from a typosquatted domain, an address engineered to look like a legitimate analytics domain at a glance, which at the time of disclosure only logged a line in the browser but could have been changed to do far more once it had a foothold on many instances. The pattern, gaining root, installing a persistent plugin, and phoning home to attacker-controlled infrastructure, is a textbook supply-chain-style compromise adapted to PeerTube’s plugin system.

Framasoft’s response shows both the strengths and the limits of how a small team handles a crisis. The fixing releases automatically removed the malicious plugin, invalidated all OAuth tokens so every user had to log in again, added a configuration option to disable root-token usage entirely, and removed the plugin from the registry. Framasoft also reported the malicious domain to its registrar and sent messages to public instances warning administrators. The project published detailed manual remediation steps, including database queries to find and remove the injected artifacts, for administrators who needed to clean compromised instances by hand. This is a competent, transparent response, and the openness of it, publishing the full details rather than quietly patching, is itself a strength of the open-source model.

The uncomfortable truth the incident exposes is that decentralization distributes not just power but also responsibility, including the responsibility to patch quickly. On a centralized platform, when the operator fixes a vulnerability, every user is protected at once because there is one system. On PeerTube, a fix only protects the instances whose administrators actually apply it, and a network of servers run by volunteers, hobbyists, and small organizations will always contain many that are slow to update or effectively abandoned. The vulnerability was exploited before the fix existed, but even after the fix, unpatched instances remained exposed. The same property that makes the network resilient to a single point of failure makes it impossible to protect the whole network with a single action.

The broader releases around this period also reflected a project hardening against hostile use. PeerTube added configuration keys to throttle video downloads, both per second in total and per IP address, specifically to prevent instability when botnets attempt to download an instance’s entire catalogue. It deprecated public access to an accounts API endpoint for privacy reasons, planning to put it behind moderator authentication in a future version. It removed support for older runtime versions to stay on maintained, secure foundations. These are the ordinary defensive measures of software under real-world pressure, and their presence is a sign of maturity, not weakness. A project nobody attacks is a project nobody uses.

For anyone evaluating PeerTube, the security incident should be read as a realistic data point rather than a disqualifier. Every platform has vulnerabilities; what differs is how they are handled and who bears the consequences. PeerTube’s handling was fast and transparent, which is what you want. But the episode is a clear reminder that running your own instance means owning your own security, including timely patching, sensible configuration such as disabling unnecessary root access, caution about which plugins you install, and monitoring for compromise. Organizations that lack the capacity for that responsibility are better served by a managed hosting provider or a well-run public instance than by standing up a server they cannot maintain.

Funding a video platform on donations and EU grants

The most improbable thing about PeerTube is not its technology but its economics. Video hosting is one of the most expensive services on the internet to operate at scale, and PeerTube is built and maintained with no advertising, no venture capital, and no paid tiers on the core software, by a non-profit that gives the software away. Understanding how this is financed explains both why the project can make choices its competitors cannot and why it moves at the pace it does.

The foundation is grassroots donations. Framasoft reports that around 75 percent of its funding comes from small donations spread across its fifty-plus projects, not just PeerTube. This is the money that pays salaries, keeps the lights on, and funds the baseline maintenance work that no one gets excited about. It is also inherently uncertain, since it depends on continued public willingness to fund free software, and it is spread thin across a large portfolio. PeerTube competes for Framasoft’s attention and budget with everything else the association does, which is a real constraint on how fast it can grow.

The second major funding source has been grants, chiefly through the NGI0 programmes managed by the NLnet foundation, which channel European Commission funding into open-internet projects. PeerTube received an NGI0 grant in 2023, and Framasoft has been candid that this kind of support was transformative for a small actor. Grant money paid for the features that are hard to sell through crowdfunding: livestreaming improvements, the plugin API, performance work, telemetry, accessibility, moderation tools, two-factor authentication, remote transcoding, and the data export and import tool. Framasoft has praised the grant process specifically for its light paperwork and for putting the team in contact with people who understand free software, which brought advice and resources beyond the money itself.

Targeted crowdfunding campaigns fill the third role, tied to specific, visible goals that donors can rally behind. The original 2018 campaign funded version 1. A 2020 campaign funded the version 3 work including live streaming. The 2025 campaign funded the mobile app, structured around concrete feature tiers and reaching €55,000. This model works because donors respond to tangible outcomes, a live-streaming feature or a phone app, more readily than to abstract sustainability. It also gives Framasoft a periodic read on public enthusiasm, which it treats as a signal about where to invest, while being clear that it will pursue its roadmap regardless of whether a given campaign hits its target.

The funding structure is the direct cause of PeerTube’s independence and its resource constraints, and you cannot separate the two. Because there are no advertisers, PeerTube can refuse tracking and algorithmic engagement optimization without a business-model conflict. Because there are no investors demanding growth, it can define success as being a useful commons rather than capturing market share. But because the money is donations and grants rather than a scalable revenue stream, the paid team stays tiny, the roadmap is perpetually longer than the capacity to deliver it, and progress depends partly on volunteer contributions and outside partnerships. This is the bargain the project has struck: genuine independence in exchange for permanent under-resourcing. For its supporters, that bargain is the entire point, because it is the only structure under which a video platform could plausibly serve the public interest rather than a balance sheet.

Moderation on PeerTube compared with centralized platforms

Content moderation is where PeerTube differs most sharply from the platforms it competes with, and where the promise and the peril of decentralization are both most visible. On YouTube, moderation is a centralized function: one company writes one content policy, enforces it with a mix of automated systems and human reviewers, and applies it, in principle, to every video on the platform. The company relies heavily on machine learning, identifying the large majority of removed content through automated detection before a human ever sees it. This is only possible because a single operator controls the whole system and can afford to train and run models at enormous scale.

PeerTube’s model is the opposite. Each instance moderates itself. The administrator of an instance sets its content rules, reviews abuse reports, and decides what to remove, and the tools PeerTube provides, the ability to block or ban users, mute accounts, review reports, and mute entire remote instances, operate at the level of the individual instance. There is no central policy and no central enforcement. A community can build exactly the moderation regime it wants, strict or permissive, tightly curated or wide open, and it answers to no outside authority for those choices beyond the law of its jurisdiction.

The strengths of this arrangement are real. Communities get to govern their own spaces according to their own values rather than being subject to one company’s globally uniform and often opaque policy. A community for a marginalized group can set rules that a mass-market platform would never adopt. A professional or educational instance can be far stricter than YouTube. Moderation decisions are made by people close to the community, who understand its context, rather than by distant reviewers or algorithms applying rules written for a billion-user average. And because there is no engagement algorithm amplifying whatever provokes the strongest reaction, PeerTube lacks the built-in incentive toward outrage and extremity that shapes content on ad-funded platforms.

The weaknesses are equally real and follow directly from the same design. Federation means one instance’s failure to moderate becomes other instances’ problem. Because users on one instance can interact with content on another, harmful or illegal material that a poorly moderated instance fails to act on can become visible to users elsewhere across the federation. The defensive tool is defederation, blocking the offending instance so its content no longer flows in, but this is reactive: someone has to notice the problem and act, and until they do, the content spreads. Researchers studying the Fediverse have documented how material generated on one instance can rapidly reach others, and how the burden of blocking falls on administrators who must constantly maintain federation policies.

The deepest problem is capacity. Automated moderation at YouTube’s scale is infeasible for PeerTube instances, because Fediverse administrators are frequently volunteers with limited time, limited money, and limited technical resources, who control only the data on their own instance. They cannot train large detection models, and they cannot review a high volume of uploads by hand without burning out. This creates a structural mismatch: the platform distributes the responsibility for moderation to exactly the people least equipped to do it at scale. Small instances can moderate a small community well precisely because it is small; the model does not obviously extend to instances large enough to matter as YouTube alternatives.

The honest conclusion is that PeerTube’s moderation model is better on values and worse on scale than the centralized alternative. It gives communities genuine self-governance and avoids the algorithmic amplification of harm, which are meaningful advantages that the centralized platforms cannot offer at any price. But it provides no answer to the hardest cases, the illegal content, the coordinated abuse, the material that requires resources and expertise to detect and remove, other than to hope that each administrator handles their own instance responsibly and that the network defederates bad actors quickly. For low-volume, community-scale use, this works. For the mass-scale, adversarial environment that any large open platform eventually attracts, it is an unsolved problem, and it is the reason the legal questions examined next are so pressing.

The Digital Services Act and the legal grey zone of federation

Regulation was written for a web of large, centralized platforms, and federation does not fit the template cleanly. The European Union’s Digital Services Act, the most consequential recent framework for online content, is built around the assumption of identifiable intermediaries with clear responsibilities: hosting services, online platforms, and the largest “very large” platforms each carry escalating obligations. A federated network of thousands of small, independently operated instances sits awkwardly inside that structure, and the resulting uncertainty is a genuine risk for the people who run PeerTube servers, especially in Europe where much of the network is hosted.

Legal analysts who have examined the question generally conclude that individual Fediverse instances are best understood as hosting services, and specifically as online platforms under the DSA, which means an instance administrator would in principle inherit the content-moderation obligations the Act imposes on online platforms. Those obligations include maintaining notice-and-action mechanisms for illegal content, providing statements of reasons for moderation decisions, offering complaint and redress procedures, and reporting obligations. For a large company these are compliance line items; for a hobbyist running a small instance, they can be overwhelming, and the DSA’s framework offers little clear guidance on how a volunteer-run server is supposed to meet them.

The awkwardness runs deeper than paperwork. The DSA was designed around the idea that a platform controls its own content, but in a federated network content flows across instances that do not control each other. A “systemic risk” that the Act worries about at the level of a very large platform has no obvious owner when the content in question originated on one instance, was amplified by federation, and became visible on another. Who is responsible? The originating instance, the receiving instance, both, or neither? The overarching actors that a regulator would naturally hold accountable on a centralized service simply do not exist in the same form in the Fediverse, which leaves both administrators and regulators in an uncomfortable position.

Beyond the DSA, instance operators face the ordinary legal exposure of anyone hosting user-generated content, and it varies by jurisdiction in ways that matter. In the United States, the analysis is different from the EU, but hosting providers still carry obligations, most seriously around child sexual abuse material, where providers must report known material to the relevant authorities and can face criminal liability for knowingly facilitating its distribution, even though they are generally not required to affirmatively monitor everything on their servers. Data-protection law, defamation, copyright, and the specific rules of each country add further layers. An administrator is not shielded from the law simply because their server is small or non-commercial.

Organizations have stepped in to help administrators navigate this, which is itself a sign of how real the problem is. Bodies focused on the Fediverse and on digital rights have published compliance guides for decentralized server operators, and legal-aid organizations have written primers on the risks and how to mitigate them, generally advising operators to plan ahead: to have clear terms and a moderation policy from the start, to understand their reporting obligations, and to know where to turn if they receive a legal threat. The recurring practical advice is that ignorance is not a defense, that even small instances need a moderation policy in place from day one, and that operators should not assume that being a passion project exempts them from serious legal duties.

The unresolved state of this is one of PeerTube’s most significant strategic risks, and it is largely outside Framasoft’s control. If regulators interpret the rules in a way that imposes heavy obligations on every instance regardless of size, the cost of running a small server could rise beyond what volunteers will accept, thinning the network. If they carve out sensible exemptions for genuinely small, non-commercial operators, the model can flourish. The direction European regulation takes on federated services in the coming years will shape whether decentralized video remains a viable option for ordinary communities or becomes something only well-resourced organizations can legally afford to run.

Child-safety obligations and the limits of volunteer moderation

Some obligations do not bend to a platform’s philosophy, and the handling of child sexual abuse material is the clearest example. It is the point where the tension between decentralization’s ideals and the practical duties of hosting content is most acute, and it deserves direct treatment rather than the vague reassurances that decentralization advocates sometimes offer. Any system that lets people upload video will attract attempts to upload illegal material, and a federated network of small servers is not exempt; if anything, it is more exposed, because it lacks the centralized detection infrastructure that large platforms have built.

The legal baseline is strict. In the United States, service providers are required to report known child sexual abuse material to the CyberTipline operated by the National Center for Missing and Exploited Children, which forwards reports to law enforcement, and they can be criminally prosecuted for knowingly facilitating its distribution. Providers are generally not required to proactively monitor their servers for such material, but once they know of it, the obligation to act and report is clear and carries serious consequences. European and other jurisdictions impose their own, sometimes more demanding, requirements. These duties fall on whoever operates the server, which on PeerTube means the instance administrator, not Framasoft and not the network.

Here the structural problem examined earlier becomes gravely concrete. Large platforms detect this material at scale using automated systems, including hash-matching against known databases and machine-learning classifiers, run by dedicated trust-and-safety teams. A volunteer running a small PeerTube instance has none of that. They cannot realistically run industrial-grade detection, they may not know their legal obligations, and they may lack the resources to respond appropriately if illegal material appears. The decentralized model, which distributes hosting to many small operators, therefore also distributes to them a category of legal and moral responsibility that is genuinely hard to discharge without significant resources.

This is not a reason to dismiss PeerTube, but it is a reason to be sober about who should run an instance and how. The mitigations that exist are real but partial. Administrators can require registration and approval before allowing uploads, drastically reducing the risk from anonymous bad actors. They can federate only with instances they trust, limiting exposure to content from unknown sources. They can defederate quickly from instances that host illegal material. They can adopt clear policies, monitor abuse reports, and act promptly. Organizations such as those providing Fediverse trust-and-safety guidance have worked to share tooling and best practices among administrators, precisely because no single small operator can solve this alone.

The comparison with the growth of AI-generated abuse material sharpens the concern. Researchers studying the criminalization of AI-generated CSAM have noted how the absence of a consistent global legal framework, combined with the increasing realism of generated material and the communities that share it, makes detection and removal slower and harder everywhere. A federated network with weak central coordination is, in principle, a harder environment to keep clean than a single well-resourced platform, because there is no central point at which detection can be applied to everything. This is a structural disadvantage of decentralization that no amount of good intent erases.

The responsible framing is that child safety is a hard constraint that any PeerTube adopter must take seriously from the first day, not an afterthought. For most legitimate uses, running a small, registration-gated instance for a known community, the practical risk is manageable with sensible policies and prompt action. But the model does not offer the automated, scaled protection that centralized platforms provide, and anyone considering an open-registration instance that accepts uploads from strangers is taking on a serious responsibility that requires real capacity to meet. This is one area where the honest advice is that the barrier to running an instance responsibly is, and should be, higher than the technical barrier to installing the software.

Privacy, tracking, and the trade-offs of peer-to-peer

Privacy is one of PeerTube’s strongest selling points, and for once the claim largely survives scrutiny, though not without qualifications worth understanding. The core proposition is simple: the software collects no behavioral tracking data, serves no advertising, and builds no profile of viewers to sell. Because the code is open source, this is not a promise you have to take on trust. Anyone can inspect the source to verify that it contains no hidden tracking or surveillance, and the transparency of an auditable codebase is a materially different guarantee from a privacy policy you cannot check.

The absence of advertising changes the incentive structure entirely, and this is the deepest point about PeerTube’s privacy posture. Surveillance on commercial platforms is not incidental; it is the business model. Data about what you watch, for how long, and what you do next is the raw material for ad targeting and engagement optimization. PeerTube has no advertising business to feed, so the entire apparatus of watch-time optimization and behavioral profiling has no reason to exist, and it does not. This is why the platform can honestly say it treats viewers as people to inform rather than profiles to monetize. It is not that PeerTube is unusually virtuous; it is that it has removed the financial reason to surveil.

For organizations, this translates into a straightforward path to data-protection compliance. Because the software collects minimal data and does no profiling, and because many instances are hosted within the European Union, GDPR compliance becomes largely a matter of configuration rather than a matter of trusting a third party’s data handling. A self-hosted instance gives an organization complete control over what data is collected, how long it is retained, and how it is processed. For a school, a public body, or a company handling video internally, this control is often the decisive advantage over a commercial platform whose data practices they cannot see or govern.

The genuine privacy trade-off is peer-to-peer delivery, and it must be stated plainly rather than waved away. WebRTC peer connections can expose IP addresses between viewers watching the same video, because establishing a direct peer connection involves exchanging network information. For public content this is comparable in sensitivity to many ordinary web interactions, but for private or sensitive videos it is a real concern, since it could reveal who is watching to other viewers. The mitigations are that careful operators disable P2P on private and unlisted videos, and that individual viewers can opt out of peer sharing. This is a case where a feature that helps with bandwidth carries a privacy cost, and the platform’s answer is to give operators and viewers the controls to manage the trade-off rather than to pretend it does not exist.

There is also a subtler privacy dimension in the federated model itself. Because instances share metadata about videos, follows, and interactions, your activity on one instance can be visible to others in the federation to the extent the protocol propagates it. This is inherent to how federation works and is not hidden, but it means “decentralized” does not automatically mean “more private” in every respect; it means the data is distributed across many operators rather than held by one, which changes the shape of the privacy question rather than eliminating it. Recent releases have tightened some of this, for example deprecating public access to an accounts API endpoint for privacy reasons, a sign the project takes these concerns seriously.

The fair summary is that PeerTube offers a genuinely better privacy proposition than commercial platforms for most users, with specific technical caveats a careful operator can manage. The absence of tracking and advertising is real and verifiable. The data-protection benefits for organizations are substantial. The peer-to-peer IP exposure is a real but bounded concern with available mitigations, and the federated metadata sharing is a structural feature to understand rather than a flaw to fear. For anyone whose reason to look beyond YouTube is privacy, PeerTube is one of the few alternatives whose privacy claims hold up when you actually examine how it works.

The numbers behind the network and how to read them

Any honest account of PeerTube has to grapple with its scale, and the figures require care because they come from different sources, different dates, and different counting methods. Framasoft’s own materials in this period describe a network of well over half a million hosted videos, viewed tens of millions of times, with figures for total videos across the network cited as high as around one million videos across roughly 1,600 platforms in some places, and user counts in the range of 150,000. Earlier third-party reviews cite lower numbers, such as 400,000 videos and 60,000 users, reflecting snapshots from earlier points. The instance count has been reported at over 1,300 recently. The precise figures matter less than the order of magnitude and the direction, both of which are informative.

The first thing to read from these numbers is that PeerTube is real and durable but small. Hundreds of thousands to around a million videos and a network of well over a thousand instances is a substantial, functioning ecosystem that has existed and grown for years. It is not vaporware or a dead project. At the same time, these figures are microscopic next to YouTube, which handles hundreds of hours of uploads every minute and serves billions of users. Anyone comparing the two on raw scale is asking the wrong question, because PeerTube was never trying to win on scale, and it never will.

The second thing to read is that the numbers are inherently hard to measure, which is itself a consequence of decentralization. There is no central database of all PeerTube activity, because that would be a central point of control the project deliberately avoids. Counts come from the public instance directory and from indexes such as Sepia Search, which do not see instances that choose not to be listed, and which cannot easily distinguish active from dormant instances or filter out low-quality automated uploads. The true size of the network is probably somewhat larger than the public figures in one sense, because private and unlisted instances exist, and somewhat smaller in another, because some counted instances are inactive. Precision is not available, and that is by design.

The third thing to read is the shape of activity rather than the totals. A network of a thousand-plus instances is not one uniform community; it is many communities of very different sizes and purposes. A handful of large, well-run instances host a disproportionate share of the videos and views, while a long tail of small instances serve tiny, focused communities. Some instances are general-purpose; many are specialized, dedicated to a topic, a language, an organization, or a subculture. Reading PeerTube as a single audience misunderstands it. It is better understood as an archipelago of small publics, each with its own character, loosely connected by federation.

The growth trajectory is the most encouraging signal in the numbers. The comparison between earlier third-party figures and Framasoft’s more recent ones shows a network that has grown substantially over a few years rather than plateauing or declining, which is not something most decentralized-media projects can claim. Many launched with fanfare and faded; PeerTube has compounded slowly. The growth correlates with the broader expansion of the Fediverse and with the periodic waves of users leaving centralized platforms, which suggests PeerTube’s fortunes are tied to the health of the wider federated web rather than depending on it going viral on its own.

The right way to hold all of this is to resist both the dismissive and the triumphant reading. PeerTube is not a rounding error, and it is not a YouTube competitor in any market-share sense. It is a stable, growing, genuinely used piece of public-interest infrastructure that serves a real and expanding set of communities while remaining tiny relative to the commercial giants. The numbers support neither the claim that decentralized video has arrived nor the claim that it has failed. They support the more boring and more accurate claim that it works, at a modest scale, for the people who want it, and that it is slowly getting bigger.

PeerTube against Odysee, Rumble and the crypto-video crowd

PeerTube is not the only project trying to break YouTube’s grip, and understanding how it differs from the other contenders clarifies what it actually is. The alternative-video field splits into camps with very different philosophies, and PeerTube sits in a distinct one. The largest rivals in the decentralization-and-freedom space are Odysee, Rumble, and BitChute, and each takes an approach that PeerTube deliberately does not.

Odysee is built on the LBRY blockchain protocol and represents the crypto-native approach to decentralized video. It uses blockchain-based metadata and peer-to-peer distribution, and it historically emphasized cryptocurrency rewards through LBRY Credits, letting creators earn tokens and viewers tip in crypto. The company behind LBRY is no longer operating after regulatory trouble, though the network persists and the crypto incentives now play a limited role for most users. Odysee’s pitch is creator ownership and censorship resistance backed by a blockchain, and it is generally considered more immediately user-friendly than PeerTube. The fundamental difference is architectural: Odysee ties decentralization to a blockchain and a token economy, while PeerTube ties it to open protocols and independent servers with no cryptocurrency at all.

Rumble and BitChute occupy a different position, defined less by technical architecture than by a content-moderation stance. Both market themselves around minimal moderation and “free speech,” and both have become associated, particularly Rumble, with political commentary and independent media that felt constrained on mainstream platforms. Rumble has grown to tens of millions of monthly users and offers genuine monetization through ad revenue and licensing. These are, however, largely centralized companies despite decentralization branding; they are alternatives to YouTube’s policies more than to its structure. PeerTube’s decentralization is structural and real, and its moderation is not a permissive global policy but a per-instance choice, which means a PeerTube instance can be far stricter or far looser than Rumble depending entirely on who runs it.

Decentralized video platforms compared

The table makes the core distinction visible: PeerTube is the only one whose decentralization is a matter of independent operators running open-source software under a shared protocol, rather than a single company using blockchain or a permissive policy as a market position. That is why it appeals to a different audience than the others.

The audiences these platforms attract follow from their designs. Rumble and BitChute draw creators whose primary grievance is moderation, especially around political content. Odysee draws those interested in blockchain, crypto incentives, and immediate monetization regardless of audience size. PeerTube draws a distinct crowd: privacy advocates, open-source supporters, educators, public institutions, and communities that want to govern their own space on infrastructure they can inspect and control. It is the choice for people whose objection to YouTube is about ownership, surveillance, and corporate control of a commons, rather than about the specifics of moderation policy or the desire to earn tokens. Framasoft’s non-profit, values-driven stewardship reinforces this positioning; PeerTube is the option for those who see video hosting as public infrastructure rather than as a market to be captured or a policy to be liberalized. Understood this way, PeerTube is not really competing with Odysee or Rumble for the same users. It is offering a different thing to a different set of people who happen to share a dissatisfaction with the same incumbent.

Owncast, Nostr streaming and the rest of the decentralized field

Beyond the direct YouTube rivals sits a wider field of open and decentralized video projects, each solving a narrower slice of the problem, and placing PeerTube among them shows what it uniquely covers. These are not really competitors so much as neighbors, and several of them pair well with PeerTube rather than replacing it. Understanding the neighborhood helps clarify why PeerTube’s particular combination of properties is uncommon.

Owncast is the closest thing to a like-minded sibling. It is self-hosted live-streaming software, letting a creator run their own streaming server that they point their broadcasting software at, regaining ownership of their live content instead of depending on Twitch or YouTube Live. Owncast is open source and privacy-respecting in the same spirit as PeerTube, but it is architecturally different in a crucial way: it is single-server and not federated. An Owncast instance is your own stream on your own server, without the network effect of instances that discover and share each other’s content. Where PeerTube emphasizes a connected federation of video hosts, Owncast emphasizes individual sovereignty over a single live stream. The two address overlapping desires through opposite structures, and a creator might reasonably use Owncast for live and PeerTube for recorded video.

The Nostr ecosystem represents a newer decentralization philosophy built around cryptographic identity and relays rather than federated servers. Streaming projects such as zap.stream run on Nostr and lean into Bitcoin Lightning micropayments, letting viewers tip creators directly and instantly. This is a fundamentally different bet: where PeerTube decentralizes through independent servers speaking ActivityPub, Nostr decentralizes through portable cryptographic keys and a network of relays, and it ties monetization to instant crypto payments in a way PeerTube deliberately avoids. For creators who want built-in, frictionless tipping and are comfortable in the Bitcoin world, Nostr streaming offers something PeerTube does not. For those who want a mature video platform with a large existing catalogue and Fediverse interoperability, PeerTube is far more developed.

Then there are the clients and front-ends that are not platforms at all but ways of consuming decentralized video. Grayjay is a multi-platform client that pulls content from many sources at once, including YouTube, Twitch, Odysee, Rumble, and PeerTube, presenting them in a single app. NewPipe is a lightweight, privacy-respecting front-end that lets users access content from YouTube, PeerTube, SoundCloud, and other sources without the tracking of the official apps. These tools matter to PeerTube because they extend its reach: a viewer using Grayjay or NewPipe can encounter PeerTube content alongside everything else, without having to adopt PeerTube as their primary platform. They are distribution channels PeerTube gets for free by virtue of being open and standards-based.

Older and more marginal projects fill out the field. DTube was an early crypto-decentralized video platform built on blockchain and peer-to-peer storage, notable for being first in that direction but never reaching significant scale. Various downloaders and archiving tools address the adjacent problem of getting content out of centralized platforms rather than hosting it anew. None of these has the combination that defines PeerTube, and that combination is the point.

What this survey reveals is that PeerTube occupies a specific and somewhat lonely position: a mature, federated, open-protocol video platform that is neither crypto-based nor a single-server tool nor a permissive-moderation political project. Owncast shares its values but not its federation. Nostr streaming shares its decentralization but bets on crypto and micropayments. Odysee and DTube chose blockchain. Rumble and BitChute chose moderation stance over structure. The clients extend reach without being platforms. PeerTube’s particular blend, federation over ActivityPub, no cryptocurrency, per-community governance, and non-profit stewardship, is not replicated by any of them, which is both why it stands out and why it cannot simply be swapped for one of the others. For the specific thing PeerTube does, it has surprisingly little direct competition; the crowded field is crowded with projects doing adjacent things.

Educational, institutional and public-sector adoption

The most telling adoption of PeerTube has come not from individual creators chasing an audience but from institutions that need to host video on their own terms, and this is where the platform’s value proposition is clearest. Universities, schools, public bodies, cultural organizations, and open-source projects have specific requirements that commercial platforms serve poorly: control over data, freedom from advertising around their content, no algorithmic recommendations pulling viewers toward unrelated material, and the ability to comply with data-protection rules by design. PeerTube fits these needs almost exactly, which is why institutional use has been a quiet but significant strand of its history.

The highest-profile institutional experiment was EU Video, a pilot ActivityPub video platform launched by the European Data Protection Supervisor in April 2022 for European Union institutions, bodies, and agencies, built on PeerTube. That a data-protection authority chose PeerTube as the basis for a privacy-respecting video platform for EU bodies is a meaningful endorsement of the software’s suitability for public-sector use. The pilot ended in May 2024 without an official continuation, which is an honest data point in both directions: it demonstrated that a serious institution found PeerTube worth building on, and it also showed that pilots do not always become permanent programmes, for reasons that may have more to do with institutional priorities than with the software.

The pattern of educational use is more durable and less dependent on any single high-profile project. PeerTube is well suited to hosting lectures, course materials, conference recordings, and institutional video precisely because these use cases do not need YouTube’s reach or its algorithm; they need reliable, private, ad-free hosting for a known audience. A university can run an instance that keeps student and faculty video within its control, sets its own access rules, and integrates with the institution’s identity systems. The password-protection and instance-only visibility features make it practical to host material restricted to a specific class or department, and self-hosting keeps the data inside the institution’s own governance rather than on a commercial platform’s servers.

Conferences and technical communities have been consistent adopters. Large open-source events with many parallel tracks produce hundreds of talk recordings that need hosting, and PeerTube is a natural home for them, aligned with the free-software values of that community and free of the commercial constraints of the mainstream platforms. The Blender Foundation’s early experimentation set an example that other open-source and technical organizations followed, using PeerTube to distribute videos in a way consistent with their own commitments to openness. Specialized community instances such as MakerTube, dedicated to people who make things, show how topic-focused instances can serve a coherent community better than a general platform’s undifferentiated firehose.

The institutional case rests on a simple alignment of interests. An institution is usually not trying to monetize video through advertising, does not want its content surrounded by ads for other things, does not benefit from an algorithm steering its viewers elsewhere, and often has legal or ethical obligations to control the data it holds. Every one of those needs points toward a platform like PeerTube and away from a commercial one. The barrier has been the operational burden of running an instance, which is why managed PeerTube hosting providers have emerged to handle the server administration for organizations that want the benefits without the maintenance. As that managed-hosting option matures, the institutional case, already the strongest argument for PeerTube, becomes easier to act on, and it may well be where the platform’s most stable long-term adoption lies.

Independent creators and the case for leaving YouTube

For an individual creator, the decision to use PeerTube is more complicated than for an institution, because a creator’s livelihood often depends on reach and revenue that PeerTube does not provide. The honest starting point is that PeerTube will not replace YouTube for most creators who depend on YouTube’s audience and ad payments, and pretending otherwise does creators a disservice. The realistic case for PeerTube is narrower and more specific, and it is strongest when framed as a complement to a creator’s existing presence rather than a wholesale migration.

The clearest reason a creator uses PeerTube is ownership and insurance against deplatforming. A creator who has built an audience on YouTube lives with the permanent risk that a policy change, an algorithmic shift, a copyright dispute, or a moderation decision could reduce their reach, demonetize their channel, or remove it entirely, often with little recourse. The Blender Foundation’s early move to PeerTube was driven by exactly this: content disappearing amid YouTube’s monetization changes. Running a PeerTube channel, whether on your own instance or a trusted community one, gives a creator a home they control, a place their work exists regardless of any platform’s decisions. For creators who have watched peers lose everything overnight, that insurance has real value even if the PeerTube audience is smaller.

PeerTube also offers specific capabilities that suit particular kinds of creators. The password-protection feature is genuinely useful for anyone who wants to share videos with a limited audience, such as paying supporters or a private community, which YouTube handles poorly. The ability to upload a corrected version of a video while keeping its URL, comments, and stats is valuable for creators who publish reference material or tutorials that need updating. The absence of an engagement algorithm means a creator is not competing against an opaque system that decides who sees their work; on a PeerTube instance, subscribers reliably see new uploads. And Fediverse integration means a creator’s videos can reach their Mastodon following directly, turning an existing federated audience into video viewers without asking anyone to sign up for anything.

The costs and trade-offs are equally concrete and must be weighed honestly. There is no built-in monetization, so a creator cannot earn ad revenue on PeerTube the way they can on YouTube, and must rely on external models such as donations, memberships, or crowdfunding hosted elsewhere. Discovery is weak, so a creator will not stumble into new viewers through a recommendation algorithm; they must bring or build their audience through other channels. The audience is smaller, sometimes dramatically so, depending on the instance and the topic. And running or choosing an instance requires more thought than clicking upload on YouTube. For a creator whose entire business is YouTube ad revenue and algorithmic discovery, none of PeerTube’s advantages outweighs these costs.

The strategy that actually works for most creators is not migration but presence across platforms. Many creators keep their primary presence on YouTube for reach and revenue while maintaining a PeerTube channel as a controlled backup, a home for content that does not fit YouTube’s rules, or a way to reach a privacy-conscious segment of their audience. Tools that automate cross-posting make maintaining multiple platforms less burdensome, and the channel-synchronization feature lets a creator mirror their YouTube uploads to PeerTube automatically. This hedged approach captures PeerTube’s insurance value and its specific features without sacrificing the reach a creator needs, and it is the pragmatic recommendation for almost everyone.

The creators for whom PeerTube makes the most sense as a primary platform are those whose values or content align with it directly: free-software advocates, privacy-focused educators, communities that already live in the Fediverse, and creators whose content is meant for a specific known audience rather than mass discovery. For them, the smaller reach is not a cost because reach was never the goal, and the ownership, privacy, and community governance are exactly what they wanted. For everyone else, PeerTube is best understood as a valuable second home rather than a replacement, and that is a perfectly good reason to use it.

Business and organizational use for internal and branded video

Beyond public-facing creators and public institutions lies a large and underappreciated use case: businesses and organizations that need video infrastructure for internal or controlled purposes rather than for reaching a mass public audience. This is arguably where PeerTube’s practical value is highest and its disadvantages matter least, because the things PeerTube lacks, mass discovery, ad monetization, algorithmic reach, are irrelevant to an organization hosting training videos, internal communications, or branded content for a known audience.

Consider the concrete needs of an organization with a substantial internal video library: employee training, recorded all-hands meetings, product documentation, onboarding material. Putting this on YouTube is awkward and often unacceptable, because it means placing internal content on a third-party platform, potentially surrounded by ads or recommendations, with the organization’s data subject to that platform’s practices. A self-hosted PeerTube instance solves this cleanly. The organization controls the data entirely, sets instance-only visibility so videos require an authenticated account on the organization’s own instance to view, disables federation so nothing leaves the organization, and hosts everything on infrastructure it governs. This is a common configuration for corporate training portals, and it is exactly what PeerTube’s per-video visibility and federation controls are built to support.

The compliance angle is decisive for regulated organizations. A company handling video that contains personal data, customer information, or sensitive internal material has obligations under data-protection law that are far easier to meet when the data sits on its own instance under its own policy than when it sits on a commercial platform whose practices the company cannot control. PeerTube’s minimal data collection and self-hosting model turn compliance into a configuration exercise rather than a trust exercise. For organizations in the European Union or subject to GDPR, this control is often the single most important factor, and it is one that no amount of contractual assurance from a commercial provider fully replicates.

The federation controls give organizations precise governance over their boundary with the outside world. An organization can run a completely isolated instance with federation disabled, auto-follow-back set to false, empty follower and following lists, and exclusion from the public search index, so the instance is invisible to the wider network and its content never leaves. Or it can selectively federate with trusted partner instances, for example a group of related organizations sharing content among themselves but not publicly. This granular control over exactly who can see and discover content is more flexible than the blunt public-or-private choices most platforms offer, and it maps well onto the real needs of organizations that operate in networks of partners, suppliers, and members.

The operational reality is that running this infrastructure requires either internal capacity or a managed provider, and this is where the honest caveat sits. An organization that stands up a PeerTube instance takes on the responsibility for transcoding capacity, storage growth, security patching, and the legal duties of hosting content, as the 2026 security incident underlined. For organizations with capable IT teams, this is manageable and often preferable to platform dependence. For those without, a managed PeerTube hosting provider handles the server administration, backups, updates, and monitoring for a monthly fee, delivering the control and privacy benefits without the operational burden. The emergence of these providers, offering managed instances at modest monthly prices, is what makes organizational adoption practical for the many organizations that want PeerTube’s benefits but lack the appetite to run servers themselves. For internal and branded video specifically, PeerTube is not a compromise; it is frequently the better tool, and its main competitor is not YouTube but the enterprise video platforms that charge far more for similar control.

Monetization, or the deliberate absence of it

The absence of built-in monetization is one of PeerTube’s most consequential design decisions, and it is deliberate rather than an oversight, which changes how it should be judged. PeerTube has no advertising system, no revenue-sharing programme, no native tipping, and no subscription mechanism baked into the core software. A creator cannot flip a switch and start earning from views the way they can on YouTube. For a platform trying to attract creators, this looks like a glaring weakness, and in the competition for creators who need income, it is one. But it follows directly from the project’s foundations and its values.

The reasoning starts with the business model, or rather the deliberate lack of one. Advertising monetization requires exactly the apparatus PeerTube exists to avoid: tracking viewers, profiling them, optimizing for watch time, and inserting ads into the viewing experience. A platform cannot offer ad revenue to creators without building the surveillance and engagement machinery that funds it. Because Framasoft’s entire proposition is a video platform that does not surveil or manipulate, native ad monetization is incompatible with the project by design, not merely absent by neglect. The choice to forgo it is the same choice that delivers the privacy and the absence of an addictive algorithm.

This leaves creators who want to earn from PeerTube dependent on external models, and the platform’s approach is to support pointing viewers toward those rather than handling money itself. A creator can link to their own crowdfunding, membership, or donation pages hosted on other services, direct supporters to a Patreon-style platform, or use the password-protection feature to gate content behind access their supporters pay for elsewhere. The password-protected video is quietly one of the more interesting monetization-adjacent tools, because it lets a creator sell access to specific content through whatever payment system they choose, using PeerTube purely as the delivery mechanism. This keeps money out of PeerTube’s own systems while still enabling creators to earn.

The comparison with the crypto-video platforms is instructive here. Odysee and Nostr-based streaming built monetization directly into their designs through cryptocurrency tips and rewards, treating instant creator earnings as a core feature. PeerTube’s refusal to do the same is a philosophical divergence, not a technical limitation; Framasoft could have added a tipping system but chose an approach that does not tie the platform to any payment rail, crypto or otherwise. This keeps PeerTube neutral and avoids entangling it with the volatility and regulatory complications of cryptocurrency, at the cost of the frictionless earning that draws some creators to those alternatives.

Whether the absence of monetization is a fatal flaw or an acceptable trade-off depends entirely on who is asking. For a creator whose income depends on their video platform, it is close to disqualifying, and it is a major reason PeerTube has not attracted the large commercial creators who define YouTube. For an institution, a business hosting internal video, a hobbyist, an educator, or a values-aligned creator funded through external donations, it is a non-issue or even a feature, because monetization was never the point and its absence comes bundled with the privacy and independence they wanted. PeerTube made a clear choice to be infrastructure for people who are not trying to monetize attention, and it should be evaluated as that rather than faulted for failing to be something it deliberately declined to become.

Setting up your own instance, realistically

The promise that anyone can run their own video platform is real, but it comes with a workload that the marketing understates, and a realistic account of what setup involves is the most useful thing this analysis can offer a would-be operator. PeerTube is not difficult to install in the narrow sense; it is difficult to run well over time. The gap between getting an instance online and keeping a healthy, secure, well-moderated instance running is where most of the effort lives, and it is worth understanding before committing.

The baseline hardware is modest. PeerTube can run on a standard Linux server with a couple of CPU cores and around 2 GB of RAM, with the application itself typically using well under a gigabyte; the documentation notes that 1.5 GB is plenty for a basic instance. The software relies on PostgreSQL for its database, needs a recent Node.js runtime, and is available as Docker images or through detailed manual installation instructions. The version 7.3 setup wizard now walks a new administrator through the initial configuration, including basic branding and a preset for the type of platform being run, which has lowered the barrier to a working first instance considerably. Getting to a running site is genuinely achievable for anyone comfortable with a Linux server.

The real cost is storage and transcoding, and underestimating both is the most common early mistake. Video storage grows faster than operators expect, and running out of disk is a frequent early failure, which is why the standard advice is to plan for object storage before you need it rather than after the server fills up. Transcoding is CPU-intensive, and the guidance is emphatic: do not enable every resolution at launch. Start with two or three common resolutions, cap concurrent transcoding jobs to match actual hardware, and expand only as you understand your capacity. Enabling six resolution variants for every upload is a reliable way to make a server unresponsive. Offloading transcoding to remote runners on separate machines is the recommended path for anything beyond a light workload.

The federation setup requires deliberate choices rather than defaults. Federation does not configure itself, and an empty instance that follows no one looks abandoned. An operator has to decide which instances to follow, whether to allow Mastodon users to follow their channels, which parts of the network to connect with and which to avoid, and whether to run auto-follow policies. These are governance decisions as much as technical ones, and they shape what the instance’s community will experience. A related early mistake is launching with an empty catalogue; the advice is to seed the instance with quality content before promoting it, and to cross-promote through an existing Mastodon network, since federation’s benefits only materialize when people know the instance exists.

The obligations that come with running an instance are the part hobbyists most often overlook, and the 2026 security incident made them vivid. An operator is responsible for security patching, which must be timely, because unpatched instances remained exposed even after fixes shipped. They are responsible for moderation, which the guidance says must be in place from day one, because even small instances need content review and claiming ignorance is not a legal defense if someone uploads something illegal. They are responsible for the legal duties of hosting user content in their jurisdiction. And they should be cautious about which plugins they install, pinning tested versions and staging upgrades, since plugins are both a source of functionality and, as the incident showed, a potential attack vector.

The realistic recommendation is to match the deployment to the operator’s capacity. An individual or small community with the technical skills and the willingness to maintain a server can run a small, registration-gated instance for a known group with manageable effort and real reward. An organization that wants the benefits without the operational burden should use a managed hosting provider, which handles installation, updates, backups, security, and monitoring for a modest monthly fee, or join a well-run existing public instance rather than running its own. The worst outcome is a half-maintained instance that is insecure, unmoderated, and eventually abandoned, which harms both its users and the wider network. Running PeerTube is empowering for those equipped to do it responsibly and a liability for those who are not, and being honest about which category you fall into is the most important setup decision of all.

Publishing and importing an existing channel

For a creator or organization moving to PeerTube, the practical question is not the philosophy but the mechanics: how do you get your videos onto the platform, and how do you keep publishing without doubling your workload. PeerTube has invested in making this less painful than it once was, because import friction is one of the concrete barriers that stops people from trying, and the tooling here has improved markedly across recent versions.

The most useful feature for anyone with an existing presence elsewhere is channel synchronization. PeerTube can automatically synchronize a channel from a remote platform such as YouTube or Vimeo, pulling in new videos as they are published on the source. This is a deliberate accommodation to reality: rather than demanding that creators abandon their existing platform, it lets them maintain a PeerTube presence that stays current with minimal ongoing effort, which supports the multi-platform strategy that suits most creators. A stricter free-software organization might have refused to build a bridge to proprietary platforms; Framasoft built it because it lowers the barrier to adoption, and adoption is what the project needs.

Direct import complements synchronization for one-off migrations. PeerTube can import individual videos from a URL, and it uses established downloading tooling under the hood, with recent versions adding the ability to provide cookies to the downloader for cases that require authentication. When importing, PeerTube can also automatically recognize and import existing chapters, so a video that was already divided into titled segments arrives on PeerTube with that structure intact. Version 8 improved the import system further, reflecting its recognition that import is a migration path, not a peripheral feature. For a creator with a back catalogue to move, these tools turn what could be a tedious manual re-upload into a largely automated process.

Publishing natively on PeerTube has grown more capable with each version. A creator uploads a video, and the instance transcodes it into web-friendly formats and resolutions, generates storyboards for scrubbing previews, and can produce automatic transcriptions for subtitles using the runner system. The version 7 redesign reorganized the publishing and editing interface into navigable sections, and creators can set metadata, visibility, licensing, comment rules, and scheduling. The version 7.3 release let administrators define default values for fields like license, visibility, and comment rules, so creators do not have to set the same options every time. Live streaming, including scheduled broadcasts with a placeholder page and viewer notification, extends publishing to real-time content for those with the server capacity to transcode it.

The mobile app closed the last major gap in publishing. With the creator mode added in the version 2 line of the app, creators can upload videos directly from a phone, manage their channels, and view content statistics without needing a computer, which matters because a great deal of video is now shot and shared from mobile devices. Combined with the desktop tools and the import and synchronization features, PeerTube now offers a reasonably complete publishing workflow: import your back catalogue, synchronize new uploads from an existing platform, publish natively from desktop or phone, and manage a growing library through the redesigned management interface. The workflow is not as frictionless as the most polished commercial platforms, but it is no longer the obstacle course it once was, and for a creator committed to the platform’s values, it is entirely workable.

The real weaknesses that hold PeerTube back

A fair assessment has to be as clear about PeerTube’s failings as its virtues, and the platform has real weaknesses that no amount of philosophical alignment overcomes. Naming them plainly is more useful than either dismissing them or pretending they are minor, because they explain why PeerTube remains niche despite years of development and genuine merits. Most of these weaknesses are structural, rooted in the decentralized design and the small team, rather than bugs a future release will simply fix.

The discovery problem is the most damaging, and users say so repeatedly. There is no unified, well-ranked search across the whole network, subscribing to channels across different instances is awkward, and a newcomer searching for a topic can get results dominated by instances that have nothing to do with what they wanted. Sepia Search and global search help, but they do not deliver the effortless, personalized discovery that people expect from video platforms. For a viewer, this makes PeerTube feel empty or hard to navigate; for a creator, it means organic discovery barely exists, so reach depends entirely on bringing an audience from elsewhere. This single weakness probably does more to limit adoption than everything else combined, and it is entangled with the architecture rather than easily solved.

Client quality and fragmentation compound the discovery issue. User reviews of the mobile app and third-party clients have repeatedly cited bugs, missing features, and gaps between what different clients can do, and the historical situation before the official app, where the best experiences came from third-party clients of uneven quality, left a legacy of inconsistency. The official app has improved this, but reviews still mention rough edges, forced behaviors users cannot disable, and a general sense that the software, while functional, lacks the polish of well-funded commercial apps. For a platform trying to reach non-technical users, every rough edge is a reason to leave.

The small team is the constraint behind almost everything else. A platform maintained by two paid developers, however talented, cannot move at the pace of a company with hundreds of engineers, cannot support plugin authors through every breaking change, cannot build the industrial content-moderation tooling that scale requires, and cannot polish every corner of the experience simultaneously. The reliance on grants and donations means the roadmap is always longer than the capacity to deliver it. This is the honest cost of independence, but it is a cost, and it shows up as slower development, thinner support, and features that arrive years after users first asked for them.

The moderation and legal burden examined earlier is a structural weakness from the perspective of network health. Distributing moderation to volunteer administrators who lack the resources to do it at scale means the network’s content quality and safety depend on the weakest instances until they are defederated, and the unresolved regulatory questions under frameworks like the DSA create uncertainty that could raise the cost of running an instance. The 2026 security incident showed that the distributed model also distributes the responsibility to patch, leaving parts of the network exposed whenever administrators are slow to act. These are not reasons PeerTube fails, but they are real drags on its growth and reliability.

The absence of monetization and the smaller audience close the loop. Because there is no native way to earn and because audiences are smaller, PeerTube cannot attract the professional creators whose presence would, in turn, attract viewers and further creators, the network effect that built YouTube. This is a chicken-and-egg problem that a small non-profit cannot easily break, and it means PeerTube is likely to remain a platform of communities, institutions, and values-aligned creators rather than one that reaches mass scale. That may be perfectly acceptable given the project’s goals, but measured against the ambition of being a genuine alternative to centralized video for everyone, it is a real limitation. The weaknesses are not fatal, and several are being actively addressed, but they are the honest reason PeerTube is a valuable niche tool rather than a mainstream one, and they are unlikely to disappear soon.

Scaling limits and the ceiling of the current architecture

Beyond the adoption weaknesses lies a set of technical scaling limits that constrain how large any single PeerTube instance can grow, and understanding them clarifies what the architecture can and cannot do. These limits are not about the network as a whole, which scales by adding instances, but about individual instances, and they shape the kinds of deployments that are realistic. An operator planning for growth needs to know where the ceilings sit.

The most fundamental limit is that a single PeerTube instance cannot be deployed across multiple nodes behind a load balancer in the way a large web service would scale horizontally. You cannot simply add more application servers to handle more traffic on one instance. This means a single instance’s capacity is bounded by what its server and supporting infrastructure can handle, and there is no straightforward path to scaling one instance to serve a massive audience the way a centralized platform scales. The architecture assumes that scale comes from many instances, not from one enormous one, which is philosophically consistent but practically limiting for any operator who wants a single large instance.

Within those bounds, PeerTube offers several mechanisms to push the ceiling higher for the parts that can be scaled. Bandwidth pressure can be mitigated through the redundancy system, where other instances mirror popular content, and through cache servers or a content delivery network placed in front of the instance to serve static video files. Transcoding, the heaviest workload, can be scaled horizontally across remote runners on separate machines, which is genuinely effective and is the primary way a busy instance keeps up with upload volume. Storage can be offloaded to object storage, separating the growing media library from the application server. These mitigations address the specific bottlenecks that hit first, and a well-configured instance using all of them can serve a substantial community.

The transcoding ceiling deserves emphasis because it bites in real deployments. A conference or event that records many talks produces a burst of uploads that all need transcoding at once, and the transcoding queue becomes the operational bottleneck; per-resolution rate limits can start returning errors once a runner is processing several simultaneous live resolutions. Live streaming is even more demanding, because each simultaneous live stream requires its own real-time transcoding process, so the number of concurrent live broadcasts an instance can handle is tightly bound to its hardware. These are not flaws so much as the physics of video, but they mean that an instance’s capacity must be planned around peak transcoding load, not average traffic, and that bursty workloads need configuration relief arranged in advance.

The stress-testing history shows the project taking these limits seriously. PeerTube ran a stress test with over 400 simultaneous viewers and planned tests simulating up to a thousand, specifically to find performance bottlenecks and tune server configurations, and recent releases added download-throttling controls to prevent botnets from destabilizing instances by downloading entire catalogues. This is the ordinary engineering of a platform that has moved from proving a concept to running under real load, and it reflects an understanding that reliability at the instance level matters as much as features.

The strategic implication is that PeerTube’s scaling model is federation, not verticalization. The network grows by adding instances, each serving its own community within its own capacity, rather than by any single instance growing without limit. This is a deliberate architectural choice that fits the decentralized philosophy: no instance should need to become a giant, because giants are exactly what the project exists to avoid. It does mean that PeerTube cannot answer the question of how to serve a billion-user audience from one place, but that was never the question it set out to answer. The architecture is built for a web of many modest instances, and it scales well in that direction while deliberately declining to scale in the other.

The strategic outlook for federated video

Predicting where PeerTube goes requires separating the project’s own trajectory from the larger movement it belongs to, and both are worth reading carefully. The realistic outlook is neither the triumphalism of decentralization advocates nor the dismissiveness of those who measure everything against YouTube’s scale. It is a more measured picture of a durable niche that is slowly widening, tied to forces largely outside the project’s control.

The clearest near-term direction is Framasoft’s own strategy, which has shifted decisively from adding capability to reducing friction. The version 7 redesign, the official mobile app, the setup wizard, the team-management features of version 8, and the improved import tools all target the same goal: making PeerTube easier to run, easier to use, and easier to join. This is the right focus, because the platform’s adoption has long been limited more by effort than by capability. If the friction-reduction continues and the discovery problem sees meaningful progress, PeerTube could move from a tool for the technically committed to one that ordinary communities and organizations adopt without a second thought. That is a plausible path to modest but real growth.

The larger determinant is the health of the Fediverse as a whole. PeerTube’s fortunes are bound to ActivityPub and to the network of interoperable services that share it. Every wave of users leaving centralized platforms for Mastodon and the wider Fediverse expands PeerTube’s potential audience without PeerTube having to do anything, and every improvement to Fediverse tooling and norms benefits federated video. Conversely, if the Fediverse stalls, PeerTube stalls with it. The project is not fighting alone; it is one part of a broader bet that the future web will be more interoperable and less centralized, and its trajectory will rise or fall substantially with that bet.

The regulatory environment is the wildcard that could break either way. If European and other regulators interpret frameworks like the Digital Services Act in ways that impose heavy obligations on every instance regardless of size, the cost of running a small server could rise beyond what volunteers accept, thinning the network and pushing PeerTube toward being something only well-resourced organizations run. If regulators craft sensible exemptions for small, non-commercial operators, the grassroots model can keep flourishing. The direction of this is genuinely uncertain and largely outside Framasoft’s influence, which makes it the single most consequential external factor in PeerTube’s future.

The most likely outcome, weighing all of this, is continued slow growth as durable public-interest infrastructure rather than a breakthrough into the mainstream or a fade into irrelevance. PeerTube has already demonstrated the two things that matter most: it survives, and it grows. It has outlasted flashier competitors, compounded its user base over years, attracted institutional interest, and kept improving on a fraction of the resources its rivals command. That pattern is likely to continue. PeerTube will not replace YouTube, and it was never trying to. It will most likely keep being what it already is, only more so: a stable, values-driven, federated video platform that serves an expanding set of communities and organizations who want control over their video, quietly proving that a video web not owned by any single company is possible, even if it will never be the one most people use by default.

Open questions the evidence cannot yet settle

Several important questions about PeerTube’s future cannot be answered from what is currently known, and it is more honest to name them as open than to guess. These are the genuine uncertainties, the places where the evidence runs out and reasonable people can disagree, and they matter because the answers will determine whether federated video remains a permanent niche or becomes something larger.

The first open question is whether discovery can be solved without recreating centralization. A truly comprehensive, well-ranked search across all instances would require either a central index with real ranking power, which cuts against the whole point of decentralization, or a distributed search protocol of a quality no one has yet built. Framasoft has chosen decentralization and accepted weaker discovery, and community tools have partially filled the gap, but whether the network can ever offer discovery good enough for mainstream users without a central gatekeeper is genuinely unknown. It may be that some degree of centralized discovery, layered on top of decentralized hosting, is the only workable answer, which would be a philosophically uncomfortable compromise.

The second is whether the moderation model can survive scale. It works well for small communities and poorly for large open ones, and no one has demonstrated that federated, volunteer-driven moderation can handle a mass-scale adversarial environment. If PeerTube grows, its instances will attract more of the abuse and illegal content that scale brings, and whether distributed moderation plus defederation is enough, or whether the model breaks down, is untested at the sizes that would matter. The answer may be that the model simply caps how large any healthy instance can grow, which would be a real constraint rather than a temporary problem.

The third is the regulatory question, which no amount of technical progress resolves. How European and other regulators eventually treat small, non-commercial federated instances under frameworks designed for large centralized platforms will shape whether the grassroots model remains viable, and that determination has not been made. It could preserve the network or thin it dramatically, and the outcome depends on political and legal processes outside anyone’s ability to predict confidently.

The fourth is whether the Fediverse itself reaches durable scale. PeerTube’s future is tied to the broader federated web, and whether that web grows into a lasting alternative or remains a persistent but minor presence is unresolved. The waves of adoption during moments of dissatisfaction with centralized platforms have shown real appetite, but retention and long-term growth are different from spikes, and the evidence does not yet settle which pattern dominates.

The honest position on all of these is patience rather than prediction. PeerTube has proven it can survive and grow slowly, which already distinguishes it from most attempts to decentralize video. Whether it can do more than that depends on answers that do not yet exist, to questions about discovery, moderation, regulation, and the Fediverse’s trajectory that will only be settled by what happens over the coming years. What can be said with confidence is that PeerTube has established federated video as a real, working option rather than a theoretical one, and that the open questions are about how far it can go, not whether it exists. For a project built by a two-person team inside a small non-profit, proving that a video web owned by no single company is not just possible but durable is already a substantial thing to have shown, whatever the unresolved questions turn out to hold.

Common questions about PeerTube answered

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

PeerTube official website The project’s home page, maintained by Framasoft, explaining what PeerTube is, how federation works, and how to find instances and creators across the network.

PeerTube frequently asked questions The official FAQ covering federation, moderation, storage, peer-to-peer playback, and the differences between PeerTube and centralized platforms, written for both viewers and prospective administrators.

PeerTube news and release announcements Framasoft’s running log of major releases, funding campaigns, and roadmap updates, including detailed notes on the features shipped in each version.

PeerTube on Wikipedia A broad reference entry tracing PeerTube’s history from its 2017 origins and 2018 crowdfunding through its technical architecture, funding model, and version milestones.

PeerTube releases on GitHub The canonical changelog for every PeerTube version, with technical detail on new features, breaking changes, security fixes, and upgrade notes published directly by the developers.

PeerTube documentation The official technical documentation for administrators, contributors, and API users, covering installation, configuration, transcoding, remote runners, and the federation model.

PeerTube architecture overview A technical breakdown of PeerTube’s client and server components, its use of ActivityPub, HLS video delivery, and the peer-to-peer loading mechanism that powers in-browser playback.

Framasoft’s blog The non-profit’s official blog, where its philosophy of de-Googling the internet, its funding appeals, and its reflections on decentralized software are laid out in detail.

Framasoft organization page The home of the small French non-profit that develops PeerTube, describing its wider catalogue of free-software services and its donation-funded model.

Association for Progressive Communications on PeerTube An analysis framing PeerTube as a network of independent, self-managed, and interconnectable platforms, situating it within debates about digital sovereignty and community-run infrastructure.

Electronic Frontier Foundation on the Fediverse and the law A legal primer on how liability and moderation rules apply to federated, user-run services, useful for understanding the obligations facing PeerTube instance operators.

FediverseReport coverage of PeerTube and federated video Ongoing reporting on the Fediverse, including PeerTube’s growth, its place among ActivityPub services, and how federated platforms interoperate.

Linuxiac coverage of PeerTube releases Independent technology reporting that tracks PeerTube version launches and explains new features and administrative changes for a self-hosting audience.

It’s FOSS on decentralized YouTube alternatives A free-and-open-source technology publication that reviews PeerTube and compares it with other decentralized and self-hosted video options.

European Purpose profile of PeerTube A profile presenting PeerTube as a European, privacy-respecting video tool, with context on institutional interest and public-sector experiments.

PeerTube Android app on Google Play The official mobile application listing, describing cross-network browsing, channel following, playlists, offline downloads, and the creator mode for uploading from a phone.

Content moderation in the Fediverse research paper An academic study of how moderation works across federated networks, examining the limits of volunteer administration and the challenges of applying centralized regulatory frameworks.

Digital Services Act and the Fediverse analysis A scholarly paper analyzing how the EU’s Digital Services Act maps onto decentralized services, and why rules written for large centralized platforms fit federated instances awkwardly.

IFTAS guidance for Fediverse moderators Practical resources and legal guidance for administrators of federated services, including reporting obligations around illegal content and moderation best practices for small operators.

Framasoft’s PeerTube mobile app crowdfunding announcement The official announcement of the 2025 campaign to fund official mobile applications, laying out the funding tiers, goals, and the reasoning behind bringing PeerTube to phones.