Daniel sent us this one, and it's a topic that's been simmering for a while. He's asking about the world of self-hosted media managers, specifically Jellyfin, Plex, and Emby. Why do people bother running their own media server when streaming is everywhere? Why does Plex draw so much heat from its own users despite being the most popular option? And where do all three of these platforms fall short when it comes to actually talking to the Netflix and Prime Videos of the world? He wants us to map the landscape and figure out who each of these is really built for.
Twenty-five million registered Plex users. That's the number that always stops me when I think about this space. Twenty-five million people who decided that streaming wasn't enough, that they wanted to run their own server, manage their own library, and in many cases, do all of that on hardware sitting in a closet somewhere. That is not a niche. That is a substantial slice of the population that has opted out of pure streaming dependency.
That number is just Plex. It doesn't count the Jellyfin installs, which don't even require an account, so there's no registry to count from. The actual population of people running self-hosted media is almost certainly larger than any single metric captures.
Which is part of what makes this space interesting. It's genuinely hard to measure. Jellyfin's GitHub repository is sitting at over fifteen thousand stars, which in open-source terms signals a very active, very committed community. But GitHub stars are not users. The people actually running Jellyfin at home, on a Raspberry Pi or a repurposed desktop, they're not necessarily the ones starring repositories.
By the way, today's episode script is courtesy of Claude Sonnet four point six, doing its thing behind the scenes.
Good to know the friendly AI down the road is earning its keep. So Daniel's prompt here is asking us to get into the weeds on all three platforms, and I think the right way to frame this is that there are really two overlapping questions. One is the open-source versus commercial tension, which is where a lot of the community drama lives. And the other is the streaming integration question, which is almost a separate problem entirely and one that I think gets less attention than it deserves.
Right, because those two questions attract different kinds of frustration. The open-source crowd cares deeply about the first one. But plenty of ordinary users who just want one interface for everything are running headlong into the second one and finding it a lot harder than they expected.
The gap between what people think self-hosted media managers can do and what they actually can do is significant. That gap is where a lot of the interesting friction lives.
Let's start pulling on the Plex thread, because that's where most of the criticism is concentrated and also where most of the users are. Twenty-five million people have made a choice, and a meaningful number of them are apparently not entirely happy about it.
Plex is a fascinating case study in what happens when a product that started as a community project grows up and starts behaving like a business. The origins are actually rooted in XBMC, which later became Kodi. A group of developers forked that codebase around two thousand nine, built something more polished and server-client oriented, and Plex Media Server became the dominant self-hosted option for years essentially by default. It was slick, it was relatively easy to set up, and it just worked better than the alternatives for most people.
For a long time, the business model was generous enough that people didn't complain too loudly. You could run a full Plex server, share your library with friends and family, stream remotely, all of it, without paying anything.
And then April twenty twenty-five happened. Plex moved remote streaming and library sharing behind a paywall. If you want to watch your own library from outside your home network, you now need either a Plex Pass at six ninety-nine a month, or a Remote Watch Pass at one ninety-nine a month. And if you want to share your library with someone else, same deal on their end.
They effectively started charging people to access their own content from their own server. Through Plex's infrastructure, technically, but from a user perspective, that distinction feels a bit thin.
It feels very thin if you've been using the free tier for five years and then suddenly the thing you rely on has a new fee attached. The community reaction was... A lot of longtime Plex users started migrating to Jellyfin almost immediately after that announcement. You could see it in the forum activity, in the Reddit threads, in the Jellyfin GitHub traffic. It was a measurable spike.
This is the core of the criticism Plex gets from diehard users. It's not just that they charge money, because people generally accept that software costs money to develop. It's that Plex built a user base on a free-as-in-free model, accumulated network effects, got people invested in its ecosystem, and then changed the terms. That pattern tends to generate a specific kind of anger.
There's also a structural issue that predates the April twenty twenty-five change. Plex has never been open source. The server software is proprietary. You can run it on your hardware, but you cannot inspect the code, you cannot fork it, you cannot contribute to it in the way you can with Jellyfin. For a lot of people in the self-hosting community, that's a philosophical dealbreaker independent of any pricing decision. The pricing decision just made it a practical dealbreaker for a wider group.
How does Plex justify the proprietary model? What's the argument they'd make?
The argument is essentially polish and integration. Plex has invested heavily in client applications. The Plex app on your Roku, your Apple TV, your Android TV, your smart TV, those are well-maintained, they look good, they handle edge cases gracefully. That takes engineering resources that you can't sustain purely on donations. And Plex has also built out a whole layer of additional services on top of the core media server. There's Plex's free ad-supported streaming, which is basically a Netflix-lite with licensed content. There's Plex's music integration, their podcast features, their live TV and DVR tools. It's trying to be a unified media hub, not just a library server.
Which is an interesting strategic choice, because it means Plex is competing in two directions simultaneously. It's competing with Jellyfin and Emby for the self-hosted crowd, and it's also sort of competing with Pluto TV and Tubi in the free streaming space. That's a lot of surface area to defend.
The self-hosted crowd, which is Plex's core identity, tends to be skeptical of the free streaming layer precisely because of what it implies about data collection. When Plex is serving you ad-supported content, it has real incentive to understand your viewing habits. That data has value. And for people who chose self-hosting partly because they didn't want their viewing data living on someone else's servers, a media server that also runs an ad platform is a philosophically uncomfortable combination.
There's a version of this where Plex's growth strategy has pulled it in a direction that alienates the exact users who made it successful in the first place.
That's a reasonable read. The twenty-five million registered users number is impressive, but registered users include everyone who ever signed up for a Plex account, including people who tried it once and never came back. Active, committed self-hosters who are running Plex servers and using them regularly, that's a different and smaller population. And within that population, the disillusionment is real.
What does Plex's integration with streaming services actually look like? Because Daniel specifically flagged this as an area where these platforms fall short, and I want to understand the technical reality there.
This is where I have to be honest about something that I think a lot of people misunderstand going in. Self-hosted media managers, all of them, Plex, Jellyfin, Emby, they are fundamentally local library managers. They are built around the idea that you have files on a hard drive, and the software organizes and serves those files. The integration with Netflix or Prime Video that people imagine, where you have one interface that shows your local library alongside your streaming subscriptions, is extraordinarily difficult to achieve in any meaningful way.
Because Netflix is not going to give Plex an API that lets Plex stream Netflix content through Plex's interface.
The business logic runs entirely the other way. Netflix wants you in the Netflix app, watching Netflix content, generating Netflix engagement metrics, seeing Netflix's interface choices, potentially seeing Netflix's recommendations for other Netflix content. Every minute you spend in a third-party interface is a minute Netflix has lost visibility into. And Netflix's entire content licensing model depends on being able to demonstrate viewership numbers to studios. If viewing happens through a layer Netflix can't measure, that's a problem for them structurally.
The DRM situation is basically a business moat dressed up as a technical constraint.
It's both, honestly. The DRM is technically real and technically formidable. Widevine, which is Google's DRM system and the one most streaming services use, is deeply integrated into certified devices and browsers. Getting Widevine certification for a new platform requires a commercial relationship with Google and a security audit. Jellyfin is not getting that certification. Plex almost certainly could pursue it but has chosen not to, probably because the cost and complexity aren't worth it for a feature that the streaming services themselves would actively resist.
What does exist in this space? Because I know there are tools that at least partially address the redundancy problem, where you've already got something on Netflix and you don't want to also download it locally.
There are some clever workarounds, and this is actually an area where the Arr ecosystem, which is the broader community of tools around automated media management, has done interesting work. There are tools called Proxarr and Elsewherr that essentially let you tag content in your Radarr or Sonarr queue as already available on a streaming service you subscribe to. So if something is on Netflix and you have Netflix, those tools can flag it and prevent an automated download. It's not integration in the sense of unified playback. It's more like a deduplication layer for your download queue.
That's a workaround for a specific problem, not a solution to the general interface unification question.
And it requires running the full Arr stack, which is its own rabbit hole. Sonarr for TV, Radarr for movies, a download client, a VPN, indexer access. The people who have all of that running smoothly are a particular kind of enthusiast. It's not something you'd recommend to someone who just wants their movies organized nicely.
Which circles back to the user type question. There's a significant gap between the person who wants a polished media library with a good remote app and the person who wants full control over every layer of their media infrastructure. Plex is mostly targeting the first group, even if it started with the second.
That tension is visible in Plex's product decisions. The things Plex has invested in, the smart TV apps, the free streaming tier, the podcast integration, those are features that appeal to mainstream users who want convenience. The things the self-hosting community cares about, hardware transcoding without a subscription, granular server controls, full transparency about what the software is doing, those have increasingly ended up behind paywalls or deprioritized entirely.
Hardware transcoding specifically is interesting because that's not a luxury feature. If you're streaming a four K HDR file to a device that can't handle the raw codec, and you don't have hardware transcoding, you're either watching a degraded picture or you're waiting for a painfully slow software transcode. That's a core functionality item.
Plex puts hardware transcoding behind Plex Pass. Six ninety-nine a month or a one hundred and twenty dollar lifetime purchase. Jellyfin, by contrast, includes hardware transcoding for free. That's the comparison that comes up constantly in migration discussions, and it's not a trivial one if you're running a server with multiple simultaneous streams.
The Plex Pass value proposition is essentially paying for things that Jellyfin gives you for free, plus the polished clients and the streaming layer that Jellyfin doesn't have.
That's a fair summary. Whether the polished clients are worth the subscription depends entirely on your situation. If your household includes people who are not going to tolerate a slightly rougher interface, Plex's apps are better in that dimension. If you're the only user and you're comfortable in a more technical environment, the calculus shifts considerably.
Let's move to Jellyfin, because I think the community around it is interesting and the story of how it came to exist tells you a lot about what drives people to self-hosting in the first place.
Jellyfin's origin is a fork. It forked from Emby in twenty eighteen, which is itself a detail worth sitting with. Emby started as a fully open-source project, Media Browser, back around twenty thirteen. It was a community-built alternative to Plex, open, free. Then in twenty eighteen, Emby closed its source code and moved to a proprietary model with a premium tier. A group of contributors who disagreed with that decision took the last open-source version and continued it independently as Jellyfin.
Jellyfin exists specifically because the self-hosting community watched one project go proprietary and decided they weren't going to let it happen again without an alternative ready.
That's exactly the motivation. And it shapes Jellyfin's culture in ways that are still visible. There is a strong ideological commitment to keeping everything free and open. Hardware transcoding, free. Plugin system, free. No accounts required, free. The server never calls home to a central service, which means there's no registration, no telemetry, no ad layer. Your data stays on your hardware.
Which for a certain kind of user is not just a preference but a genuine requirement. People who have thought carefully about digital privacy, people in professions where data confidentiality matters, people who've been burned by services changing their terms, they are Jellyfin's natural constituency.
The GitHub star count, over fifteen thousand, reflects a community that is actively engaged. Jellyfin has a plugin ecosystem that covers a remarkable range of functionality. There are plugins for metadata providers, for subtitle handling, for music library management, for integration with external tools. The community has built things that the core team never planned for because the architecture allows it.
What are the genuine weaknesses? Because Jellyfin has a reputation for being the ideologically correct choice but not always the practically smooth one.
The client situation is the most honest answer. Jellyfin's official clients are functional and have improved significantly, but on some platforms they lag behind Plex's apps in polish. The Apple TV client in particular has historically been a point of complaint. Things like frame rate switching, HDR metadata handling, subtitle rendering, these are areas where Plex's commercial investment shows. Jellyfin is catching up, and the gap has narrowed, but it hasn't fully closed.
More involved than Plex, less chaotic than Kodi. If you're comfortable with a basic server setup and you can follow documentation, Jellyfin is accessible. The documentation has gotten much better. But if your mental model of software setup is "download, install, done," there will be moments of friction. Reverse proxy configuration, SSL certificates, port forwarding, these are not Jellyfin-specific problems but they're problems Jellyfin doesn't fully abstract away the way Plex does with its relay infrastructure.
Plex's relay is actually doing meaningful work for non-technical users, isn't it? Because Plex handles the networking complexity so you don't have to expose your home server directly to the internet.
Plex's relay infrastructure is a valuable feature that I think gets undersold in the comparison discussions. When you install Plex, remote access works almost immediately without any router configuration because Plex's servers act as an intermediary. For a household where the person running the server is not the household's network administrator, that is a significant quality of life difference. Jellyfin can achieve the same result, but you have to set up a reverse proxy, configure DNS, handle your own SSL, or use a tunneling service like Cloudflare Tunnel or Tailscale. That's doable, but it's a project.
There's a version of this where Plex's relay is the product for a large segment of its user base, and everything else is secondary.
I think that's more accurate than the self-hosting community usually admits. The community tends to evaluate these tools from an enthusiast perspective, where networking configuration is not a barrier. But the median Plex user is not an enthusiast. They're someone who wanted their ripped DVD collection accessible on the TV in the living room and on their phone when they travel. For that person, Plex's relay and its polished apps are the whole value proposition.
Where does Emby fit in this picture? Because it's the one that gets the least airtime in these comparisons, and I suspect that's partly because its story is the most complicated.
Emby occupies a awkward position. It's not open source, so it doesn't have Jellyfin's ideological appeal. It's not as polished or as widely supported as Plex, so it doesn't have Plex's mainstream appeal. What it has is a middle-ground product that some users find hits the right balance of features and cost.
What's the actual feature set relative to the other two?
Emby's client applications are generally considered more polished than Jellyfin's, at least on the mainstream platforms. The interface is clean, the mobile apps are solid, and the smart TV clients have historically been better maintained than Jellyfin's equivalents. Emby also has strong live TV and DVR support, which matters to a specific user segment. The premium tier, Emby Premiere, is four ninety-nine a month or a hundred and nineteen dollars for a lifetime license, and it unlocks hardware transcoding, sync features for offline playback, and some additional client capabilities.
Emby's pricing is actually more aggressive than Plex's on both the monthly and lifetime tiers.
Meaningfully so on the lifetime purchase. A hundred and nineteen dollars versus Plex's hundred and twenty dollars is essentially the same, but Emby's monthly at four ninety-nine is cheaper than Plex Pass at six ninety-nine. For users who want a subscription model with better clients than Jellyfin and a lower monthly cost than Plex, Emby is a rational choice.
The fact that it closed its source code is a real trust deficit with the community, because people watched it happen once and they know it can happen again.
The Emby to Jellyfin fork story is not ancient history. It happened in twenty eighteen, and the people who were involved in that community are still active. There is a lived institutional memory of what closed-source decisions look like from the inside. Emby's user base tends to be people who either didn't follow that history closely or who've evaluated the current product and decided the trust risk is acceptable given the features.
Or people who tried Jellyfin, hit a client issue on their specific device, and found that Emby's app just worked better for their setup.
That's a real migration path. Device-specific client quality is one of the main practical reasons people move between these platforms. If Jellyfin's Android TV client has a bug that affects your specific TV model and Emby's doesn't, that's a concrete reason to switch regardless of the open-source considerations.
Let's talk about the music side of this, because Daniel mentioned audio specifically and I think it's an area where all three of these platforms have real limitations.
Music is the Achilles heel of the video-focused media server ecosystem. Jellyfin has music support and it's functional for basic library management, but the experience is significantly weaker than the video side. Emby is similar. Plex has invested more in music, including integration with Tidal for lyrics and metadata, but it's still clearly a secondary feature compared to the video library.
There was a piece I came across, Joe Karlsson wrote it earlier this year, and the headline was essentially that self-hosted music still doesn't work properly in twenty twenty-six. And his argument was that the problem isn't just the software, it's that the music metadata ecosystem has evolved around streaming services in ways that make local library management harder than it was ten years ago.
That resonates with what I've seen. Album artwork, track metadata, playlist sync, scrobbling to Last.fm, integration with services like MusicBrainz for tagging, these all work, but they require configuration and maintenance that video libraries don't. And the dedicated music server options, things like Lyrion Music Server, formerly known as Logitech Media Server, are built around different paradigms and don't integrate naturally with the video-focused platforms.
The unified media hub that Plex is trying to be, where you manage your movies, your TV shows, and your music all in one place, that vision is more complete on the video side than the audio side.
Substantially more complete. If you take your music seriously, the honest recommendation is probably a separate dedicated solution alongside whichever video server you run. Navidrome is a popular option for self-hosted music streaming. It's lightweight, it supports the Subsonic API which means it works with a huge range of mobile apps, and it's focused entirely on music so it does that one thing well.
The fragmentation is real. The dream of one interface to rule all your local media is still mostly a dream.
It's worth being honest about why. Video files have relatively stable, well-defined metadata structures. A movie is a movie, it has a title, a year, a poster, a cast, a runtime. The metadata providers, TMDB, TVDB, are mature and comprehensive. Music is messier. Albums have multiple pressings, compilation rules are inconsistent, classical music has entirely different organizational logic than pop music, and the metadata sources are more fragmented. It's a harder problem.
Which is a useful thing to understand before you go in expecting your self-hosted setup to replace Spotify seamlessly.
The Spotify comparison is actually instructive. Spotify's recommendation engine and its curated playlists are valuable features that no self-hosted solution can replicate, because they depend on aggregate listening data from hundreds of millions of users. Self-hosting your music means you own your library and your listening data stays local, but you lose the discovery layer entirely. That's a real trade-off and not everyone has thought through what it means in practice.
The user type question that Daniel raised is actually quite nuanced when you get into it. It's not just technical sophistication versus non-technical. It's also about what you're trying to get out of the setup.
The population of self-hosted media users is diverse. There are the privacy-first users who want no data leaving their hardware under any circumstances. There are the collectors, people with large physical media libraries they've ripped over years who need serious organizational tools. There are the bandwidth-conscious users in places with data caps who prefer to download once and stream locally. There are the tinkerers who find the setup process itself enjoyable. And there are the practical household managers who want one good interface for a mixed library of local content and streaming services, and are consistently frustrated that the last part doesn't work as well as they'd like.
Each of those groups maps differently onto Plex, Jellyfin, and Emby.
Pretty cleanly, actually. Privacy-first users land on Jellyfin almost by definition, because it's the only one with no central account requirement and no telemetry. Collectors with large libraries often prefer Jellyfin or Emby because the metadata handling for large catalogs is strong and the lack of a paywall means they can run hardware transcoding for multiple simultaneous streams without a subscription. Tinkerers tend to be in the Jellyfin community because the open-source nature means there's more to tinker with. The polished-experience-at-reasonable-cost crowd ends up split between Plex and Emby depending on which client works better on their specific device ecosystem. And the people who want unified streaming integration are, honestly, still waiting for a solution that doesn't fully exist yet.
That last group—the ones waiting for unified streaming integration—really highlights the fundamental tension in this space. Because at their core, these platforms are local library managers. That's the design premise: you own files on a hard drive, and the software organizes and serves them. Everything else is an extension of that.
Right, and it's worth being precise about what self-hosting actually means in this context, because the term gets used loosely. A self-hosted media manager is software you run on your own hardware, whether that's a dedicated NAS, a repurposed desktop, a Raspberry Pi, or a full server rack if you're that person. Your media files live on storage you control. The software handles transcoding, metadata, user management, and client delivery. Nothing about your library has to touch a third-party server unless you explicitly choose that.
Which is a fundamentally different model from Netflix or Plex's own ad-supported content layer, where the content itself is someone else's and the platform controls what stays and what disappears.
The ownership dimension is real and I think it's underweighted in mainstream coverage. When Netflix removes a title, it's gone from your library. When you own the file, it stays until you delete it. For serious collectors, that permanence is not a minor consideration. It's the whole point.
We're talking about three main options in this space. Plex, which is the largest with twenty-five million registered users and a commercial model that's gotten more aggressive over the past year. Jellyfin, which forked from Emby back in twenty eighteen and has stayed fully open-source. And Emby, which sits between them, closed-source but not as commercially oriented as Plex.
Those are the three that dominate the conversation. There are others, Kodi being the most notable, but Kodi is a different paradigm entirely. It's a local media player first, not a client-server architecture. Jellyfin, Plex, and Emby are all built around the idea that you have a server running somewhere and clients connecting to it from other devices. That distinction matters for how you think about them.
That server-client architecture is what makes the streaming integration question so thorny—especially when you consider how it plays out in practice.
Right, and that’s where the streaming integration problem gets complicated in ways that most coverage glosses over. When you're running Jellyfin or Plex on your home server, the software is serving files that you own. The transcoding happens on your hardware, the delivery goes to your client app, and the whole chain is under your control. The moment you try to bring Netflix into that, you're asking a DRM-locked content system to play nicely with software that was designed around the opposite premise.
Netflix has no incentive to cooperate with that.
Netflix's entire business model depends on content being tied to their platform. They're not going to expose an API that lets Jellyfin pull their content into a unified interface, because the moment you can browse Netflix from inside your local media server, you've reduced their surface area for upselling, for recommendation manipulation, for keeping you inside their ecosystem. The walled garden is not an accident.
Plex has tried harder than anyone to bridge that gap, which is part of why it draws criticism. Because in trying to be a unified hub, it's made compromises that pure self-hosters find uncomfortable.
The Plex approach is interesting from a product strategy perspective. They built out their own free ad-supported streaming layer, Plex TV, which includes live television channels and a library of free content. They've added integrations with services like Tidal for music. They partnered with various providers to show what's available on streaming services alongside your local library. But the key word is alongside. They can tell you that a film is available on Netflix. They can't play it from within Plex. The DRM wall is still there.
The integration is more like a search index than actual playback.
It's metadata integration, not content integration. Plex can surface the information that a given title exists on a given platform and redirect you there. But you're leaving Plex to watch it. Which is useful, honestly, as a discovery tool, but it's not the unified playback experience people imagine when they hear "Plex integrates with streaming services.
The criticism Plex gets from the open-source community isn't really about that limitation, because that's a DRM problem, not a Plex problem. The criticism is about the commercial model itself.
Right, and it's worth being specific about what changed. For most of Plex's history, remote streaming and library sharing were free features. You could set up your server, share your library with family members across the country, and they could stream from your collection without either of you paying anything. That changed in April of last year. Remote streaming now requires either a Plex Pass at six ninety-nine a month, or a Remote Watch Pass at one ninety-nine a month per user. Hardware transcoding, which matters enormously for performance on lower-powered servers, also moved behind the paywall.
The people who were most affected by that change were the ones who had built their whole setup around the assumption that those features were permanently free.
Which is the core trust problem with commercial open-source-adjacent products. Plex was never actually open source, that's an important clarification. Its server code has always been proprietary. But it had a generous free tier for long enough that users built workflows and family sharing arrangements around it. When the free tier contracted, those users felt a legitimate grievance, not just because of the cost, but because the platform had effectively changed the terms after they'd already invested time and hardware into building their setup around it.
The RapidSeedbox piece on Plex alternatives from earlier this year documents exactly that migration pattern. People who had been Plex users for five or six years, with large libraries and established sharing setups, who moved to Jellyfin specifically because of the April twenty twenty-five paywall changes.
The thing that makes Jellyfin a viable migration destination for those users is that hardware transcoding is completely free. No subscription, no paywall, no tiered feature access. If your server has a GPU or a CPU with integrated graphics that supports hardware acceleration, Jellyfin will use it. That's a meaningful technical difference for anyone running a server that's handling simultaneous streams for multiple household members.
How significant is hardware transcoding in practice? Because I think the gap between software transcoding and hardware transcoding is something people underestimate.
It's substantial. Software transcoding on a mid-range processor can handle maybe two or three simultaneous one-thousand-and-eighty-p streams before you start seeing buffering and quality degradation. Hardware transcoding on even a modest integrated graphics chip, something like Intel Quick Sync, can handle eight to ten simultaneous streams with significantly lower CPU load and better power efficiency. For a household with multiple users, or anyone who shares their library with extended family, that difference is not theoretical.
When Plex moved hardware transcoding behind Plex Pass, they essentially told anyone running a shared library that the feature they needed most was now a subscription item.
Six ninety-nine a month is not an outrageous price in isolation, but it changes the value proposition. You've already bought the hardware, you've already ripped or organized your library, you've already invested the setup time. Adding a recurring subscription fee to access your own files on your own hardware rubs against the whole ethos of self-hosting.
Which is where the Jellyfin community argument lands cleanest. If the point is that you control your media, a subscription to a proprietary server undermines that control in a specific way.
Jellyfin's position in the market has strengthened because of it. The GitHub repository crossed fifteen thousand stars, which as a rough proxy for developer and enthusiast interest puts it in a completely different category than it was three or four years ago. The community plugin ecosystem has grown. The client apps have improved on Android TV and Roku in particular, which had historically been weak points. The migration from Plex wasn't just a protest, it accelerated Jellyfin's development because it brought in contributors and users who had specific complaints about what they'd left behind and wanted to fix them.
There's something almost self-defeating about Plex's move when you look at it that way. They tightened the commercial model to capture more revenue, and in doing so accelerated the development of their most capable open-source competitor.
It's a classic platform tension. The features that are most valuable to power users are often the same features that are most expensive to provide and most tempting to monetize. But power users are also the most likely to have the technical capability to move to an alternative, and the most likely to bring others with them when they do. That’s why finding the right balance is so tricky.
Which is exactly what makes Emby such an interesting case study. They’ve tried to position themselves as the middle option in this market, but it’s not even clear whether a sustainable middle option actually exists.
Emby's history is inseparable from Jellyfin's. They were the same project until 2018, when the Emby developers decided to close the source and move toward a commercial model. A group of contributors disagreed with that direction, forked the codebase, and Jellyfin was born. So when you're comparing the two today, you're essentially comparing what happened when the same starting point went in two different directions for eight years.
The divergence is visible in the product, not just the philosophy.
Very much so. Emby landed on a model that's closer to Plex than to Jellyfin. The base software is free, but hardware transcoding, sync for offline viewing, and some of the more polished client features are locked behind Emby Premiere, which runs four ninety-nine a month or a hundred and nineteen dollars as a lifetime purchase. So you're looking at a lower price point than Plex Pass, and a one-time option that Plex has never offered, but you're still looking at a paywall for the features that matter most to serious users.
The lifetime option is interesting. That's a different psychological contract than a monthly subscription.
It is, and I think it attracts a specific kind of user. Someone who's committed enough to their setup to pay a meaningful upfront amount, but resistant to the idea of ongoing subscription fees for software running on their own hardware. The hundred and nineteen dollar lifetime purchase is essentially a bet that you'll use the platform for more than two years, at which point you've come out ahead of the monthly rate. For users who are building a long-term home server setup, that calculation is attractive.
Whereas Jellyfin is asking you to make no bet at all. Everything is free, the hardware transcoding works out of the box, and the only cost is the hardware you're already running.
Which sounds like an obvious win until you look at the trade-offs. Jellyfin's client quality has historically been inconsistent. The web interface is solid. The Android app is functional. But the smart TV clients, the Roku app in particular, have had rougher edges than what Plex or Emby ship. The WunderTech comparison from earlier this year makes this point explicitly. Jellyfin's feature parity with Emby is high, but the polish on certain clients still lags.
Polish matters more than people admit. If the person using your server is not you, if it's your partner or your parents or your kids, the interface has to work without configuration or troubleshooting.
That's exactly the user segmentation line. Jellyfin's core audience is the person who set up the server and who has the technical comfort to work around rough edges, install community plugins, troubleshoot a client that's misbehaving. Emby and Plex are competing for the user who wants a more finished product, either for themselves or because they're sharing the library with people who won't tolerate a clunky interface.
It's less about which platform is objectively better and more about what role you're filling. Are you the server admin, or are you trying to build something that works for people who aren't server admins?
And Jellyfin's community-driven development model is impressive when you look at it from the outside. There's no company with a product roadmap. Features get built because contributors want them or because users file issues that attract developer attention. The fifteen thousand GitHub stars are a signal of how much enthusiasm exists in that community. But community-driven also means that the features that get prioritized are the ones that the contributors themselves care about, which skews toward technical depth over consumer polish.
Which is not a criticism, it's just an honest description of how open-source development works.
It produces real results in certain areas. Jellyfin's plugin ecosystem covers things that Plex and Emby haven't prioritized. There are plugins for lyric display, for advanced subtitle management, for integration with tools like Sonarr and Radarr on the download automation side. The Awesome-ARR project on GitHub catalogs a lot of this ecosystem, and it's extensive. There are even tools like Proxarr and Elsewherr that help users tag content already available on Netflix or Prime Video so they're not downloading things they can already stream legally, which is a clever way to handle the integration problem without pretending DRM doesn't exist.
That's a smarter approach than trying to unify playback, honestly. Work around the wall rather than pretend you can knock it down.
The self-hosted community has always been good at finding the seam between what's technically possible and what the streaming platforms are actually watching for. The integration tools aren't trying to play Netflix content through Jellyfin. They're just helping you manage your download queue intelligently so you don't duplicate content you have legal access to elsewhere.
The music side of this is worth mentioning, because it's a different problem entirely.
Significantly worse, actually. There was a piece from Joe Karlsson earlier this year with the fairly blunt title that self-hosted music still, in his words, kind of doesn't work well in practice. The video-focused solutions have benefited from years of development and a clear use case. Music is messier because the metadata is more complex, the library management expectations are higher, and the streaming services have locked down their catalogs even more aggressively than video. Lyrion Music Server is the main option in that space and it's functional, but the gap between what Spotify or Apple Music offer and what a self-hosted music server can match is wider than the equivalent gap on the video side.
Which tells you something about where the energy in this community has gone. Video is a solved problem in a way that music isn't yet.
It reflects the user base. The self-hosted media community skews toward people who have large local video libraries. Ripped Blu-rays, downloaded films, television series they've collected over years. The music equivalent, people with large local audio libraries in lossless formats, exists but it's a smaller group, and the tooling hasn't caught up to the same degree.
When Daniel frames this as a jungle, he's being accurate, but it's a jungle with a fairly clear map if you know what you're optimizing for. And for someone new to home servers, that map starts with Plex.
If you're someone who has never run a home server before, who wants a polished interface, and who doesn't mind a subscription, Plex is the easiest on-ramp. Twenty-five million registered users didn't accumulate by accident. The client quality is consistent, the metadata matching is reliable, and the streaming integration, even if it can't touch Netflix playback directly, gives you a unified browsing experience that the others don't match.
If that description fits you, the Plex Pass at six ninety-nine a month is probably worth it. The hardware transcoding alone justifies it if you're sharing the library with more than one or two people.
The inflection point is when you start asking why you're paying a subscription to access your own hardware. That's when Jellyfin becomes the honest answer. If you're technically comfortable, if you're willing to spend an afternoon on setup and occasional troubleshooting, and if the people using your server are mostly you, Jellyfin gives you everything Plex charges for, at no cost. Hardware transcoding, plugin ecosystem, active development. The trade-off is that the rough edges are real, and you own them.
The Emby case is narrower but useful. If you want more polish than Jellyfin currently ships on smart TV clients, but the idea of a perpetual monthly fee bothers you, that hundred and nineteen dollar lifetime Premiere purchase is a reasonable middle position. You pay once, you get hardware transcoding and the better clients, and you're done.
The honest advice I'd give anyone starting from scratch is to decide first who else is going to use this thing. If the answer is just you, Jellyfin. If the answer includes people who will call you when something doesn't work, Plex or Emby. That single question filters most of the decision.
Figure out whether you're building a video library or a music library, because if it's primarily music, the calculus shifts and none of these three is a fully satisfying answer yet.
That's the one area where I'd temper expectations before someone invests significant time. The video side of self-hosting is mature. The music side is still catching up, and you should go in knowing that.
That raises the question: does any of this change if streaming platforms decide to meet these users halfway instead of fighting them?
That's the tension I keep coming back to. The DRM wall isn't going anywhere, but the business logic behind it could shift. If a platform decided that integrating with Plex or Jellyfin as a playback source actually increased their subscriber retention rather than threatening it, the whole conversation looks different. You'd have people browsing their local library and their Netflix queue in the same interface, and nobody's losing revenue from that arrangement.
It would require the platforms to trust that the integration doesn't become a piracy vector, which is a significant ask.
Significant but not impossible. The tools like Proxarr already demonstrate that the self-hosted community is mostly interested in managing legitimate access, not circumventing it. Whether the legal and licensing teams at those companies ever reach the same conclusion is a different question.
My guess is the pressure comes from the other direction. If enough users migrate to self-hosted setups and start canceling streaming subscriptions, the platforms notice. Twenty-five million Plex users is not a number that stays invisible to a Netflix quarterly report.
Jellyfin's growth since the April 2025 paywall changes suggests the appetite for self-sovereign media management is expanding, not contracting. Where it goes from here, especially on the music side, is the thread I'm most curious to pull.
A good place to leave it. Thanks to Hilbert Flumingtop for producing the episode, and to Modal for keeping the infrastructure running. Find all twenty-two hundred and twenty episodes at myweirdprompts.This has been My Weird Prompts. Leave us a review if you've got a minute, it helps. We'll see you next time.
