The Jellyfin server hosts the web client but does not ship it, and FreeBSD is still incompatible

The server hosts the web client, and the web client is not in the repository

This is the first thing that trips up anyone building from source. The server is configured to host the static files required for the web client in addition to serving the backend, by default, and those files are not included in this repository. So a fresh clone gives you an API and no interface.

There are exactly two ways to close that gap, and both are documented. Build the client from source following the instructions in the jellyfin-web repository, or take the pre-built files from an existing server installation, where on a Windows install they sit at C:\Program Files\Jellyfin\Server\jellyfin-web.

The second path is the pragmatic one and the file recommends the opposite for development: host the web client separately from the web server with some additional configuration, in which case you can skip getting the files at all. That inversion is worth understanding before you start. The default configuration exists so a packaged install works, and a contributor is expected to run the two halves apart, which means the build you test is not the build a user gets.

Clone, install the .NET 10 SDK and ffmpeg, then dotnet run

Cloning is a plain HTTPS clone of the repository:

git clone https://github.com/jellyfin/jellyfin.git

Two prerequisites come before the build will do anything. The .NET 10 SDK has to be installed on the system, and ffmpeg has to be installed as well, from the jellyfin-ffmpeg project. An IDE is only needed if you want to debug the server while it runs. If you intend to send code changes, the file asks you to set up your own fork instead of cloning the project directly.

Three ways to start it: open the solution file in Visual Studio, at least version 2022, and press F5; in Visual Studio Code open the repository directory with Open Folder, install the workspace-recommended extensions, of which only the Workspace Recommendations are required, and press F5; or run it from the command line with dotnet run.

One inconsistency to expect. The prerequisite is the .NET 10 SDK, while the same section says any IDE that supports .NET 6 development will work. Those are different version numbers, so the editor tooling you are told is sufficient is not the one that matches the SDK, and on a machine set up for .NET 6 the debugging story will not be the documented one.

FreeBSD is the one operating system the server does not support

The development section states that the project is supported on all major operating systems except FreeBSD, which is still incompatible. The word still is the informative part: this is a known gap that has not been closed, not an oversight in the sentence.

For a user deciding where to run the server, it removes one host from the list. For a contributor it decides where you can run the server from source at all, and the file offers no workaround, no container recipe and no tracking issue for it, so if FreeBSD is your platform you are left to find out whether the blocker is in the server or in one of the pieces around it.

Worth keeping the scope of the cross-platform claim in view. It comes from the port to the .NET platform, so cross-platform here means the platforms .NET runs on. That is a wide set, but it is not every platform, and the one exclusion the project names is FreeBSD.

MediaBrowser and Emby directory names are the fork's own paperwork

The README says Jellyfin is descended from Emby's 3.5.2 release and ported to the .NET platform for cross-platform support. That history is not just a sentence in the readme, it is the directory listing. Alongside the Jellyfin.Api, Jellyfin.Data, Jellyfin.Server and Jellyfin.Server.Implementations projects sit MediaBrowser.Common, MediaBrowser.Controller, MediaBrowser.LocalMetadata, MediaBrowser.MediaEncoding, MediaBrowser.Model, MediaBrowser.Providers and MediaBrowser.XbmcMetadata, plus Emby.Naming, Emby.Photos and Emby.Server.Implementations.

The practical consequence is that the namespace names do not match the product name, and neither do half the top-level folders. If you are debugging an exception, reading a stack trace or searching the code for a type, a search for Jellyfin will miss the metadata, provider and encoding layers entirely, and the obvious place to look, the folder named after the product, holds only part of the server.

For anyone evaluating the fork question, the in-tree evidence is better than a claim on a page: the lineage is visible in the source tree, and you can see exactly how much of the original is still there.

Central package versions, a BannedSymbols.txt and StyleCop meet you before the tests do

The build surface is unusually explicit for a server project. Directory.Packages.props and Directory.Build.props hold central package and build configuration, global.json pins the SDK, nuget.config points at the feeds, and stylecop.json turns on style analysis. Then there is BannedSymbols.txt, a list of identifiers the codebase does not want, next to an .editorconfig.

There is a whole support structure around the build too: a .devcontainer for a containerised development environment, .config and .vscode directories, jellyfin.code-workspace and Jellyfin.sln.DotSettings for Rider, a bump_version script, SharedVersion.cs, a deployment/ directory, a fuzz/ directory, src/ and tests/.

What that means for a contributor is that the first gate you meet is a naming one. A patch that is functionally correct can still fail on a banned symbol or a stylecop rule, before any test runs. It also means the version number lives in one file, SharedVersion.cs, with a script to move it, so version bumps are a deliberate act rather than something that happens when a tag is pushed.

Version 12 arrived in September 2026, one release after an RC

Three releases land within about two weeks: v12.0-rc7 on 2026-08-31, v12.0 on 2026-09-08 and v12.1 on 2026-09-15, with the last push to master on 2026-09-17. The cadence tells you the 12 series is where the work is.

It also tells you something less comfortable if you build on the API. A major version that moved within the last month, followed by a point release four days later, means the surface other projects integrate against is settling. The README does not document an API stability policy, so if you are writing a plugin or a client against this server, the compatibility target is a tag you choose rather than a promise the project has written down.

Where the project does point you is outward: the feature request hub at features.jellyfin.org, the documentation site, the issue tracker for something not working, and the contributing guide. What is not in this repository is any release checklist, upgrade note or deprecation timeline, so an operator planning a major version jump has to read the release notes on the releases page rather than expect a migration guide here.

GPL-2.0, no premium tier, and the difference from Emby and Plex is the licence

The pitch is one sentence: Jellyfin is an alternative to the proprietary Emby and Plex, providing media from a dedicated server to end-user devices via multiple apps. The difference in approach is not a feature list. Those two are proprietary, this one is GPL-2.0 with a LICENSE file at the root, and the project states that there are no strings attached, no premium licences and no features, and no hidden agendas.

The consequence for a user is simple and pleasant: there is no tier to unlock, no feature to pay for, and no purchase decision to make. The consequence for an operator is that a GPL-2.0 server you modify and deploy stays under those terms, and there is no support contract to buy, so the documentation, the issue tracker and the community channels are what you have when something breaks.

One more thing the file is careful about: this repository is the backend server and only one of many projects under the Jellyfin GitHub organization. The web client, the end-user apps and ffmpeg live elsewhere, so installing Jellyfin is an assembly job across several repositories rather than a single download, and the server alone will not give you a working end-to-end product.

Editorial conclusion

Adopt it if you want to run your own media server under GPL-2.0 with no paid tier to unlock, and you are prepared to assemble it from a server repository, a separate web client and a separate ffmpeg build. Do not pick it because a feature request reads well on features.jellyfin.org, since nothing in this repository tracks delivery dates. Before you clone, check three things: that your host is not FreeBSD, that you have somewhere to put the web client files because a fresh clone has none, and that a client or plugin you rely on is compatible with v12, which shipped on 2026-09-08 and was followed by v12.1 four days later.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes