jellyfin-vue and the case for a second Jellyfin web client

An alternative client, with the alternative spelled out

Jellyfin Vue is described as an experimental, alternative browser-based web client for Jellyfin written using Vue.js. Two qualifications follow immediately, and they are the most important sentences in the project documentation: it is not planned or targeted to replace the main Jellyfin Web client, and it is not feature complete.

That framing tells you what this repository is for. It is a place where the interface to Jellyfin can be rewritten without touching the server, a proving ground for a different front end stack, and a contribution target for people who prefer Vue. The Jellyfin server API is the contract, so anything the client can do is limited by what the API exposes, and a rewritten client can lag behind the features of the client it is meant to complement.

The audience is therefore people who already run Jellyfin and want to see an alternative interface, plus developers who want to contribute to a Vue implementation of the client. It is not an audience that wants a working product on day one, and the documentation does not pretend otherwise.

The repository layout matches a monorepo for a large front end. There is a packages/ directory, a pnpm-workspace.yaml, a pnpm lockfile, a packaging/ directory for the container images, a .devcontainer directory, and a root package.json that orchestrates the workspace rather than containing the application itself.

The hosted instance and its HTTPS requirement

There is a hosted instance at jf-vue.pages.dev, built from the latest commit in the default branch and hosted on Cloudflare Pages. You open it, it asks for your server address, and it connects. If you have no Jellyfin server, the documentation points at the public demo instance at https://demo.jellyfin.org/stable.

The warning attached to that convenience is specific and worth repeating. This only works for Jellyfin servers that are behind a reverse proxy and have HTTPS set up correctly, and if your server runs over HTTP you must host the client yourself.

The reason is in how a browser works rather than in how the client is written. A page served from one origin cannot make credentialed requests to another origin unless the server allows it, so a cross-origin client needs the server to present a certificate the browser trusts and to send the right headers. A server on plain HTTP cannot do that, and the request fails before any application code runs.

So the hosted instance is for people whose server is already properly exposed, which is the situation most people running Jellyfin outside their own network are in. Everyone else ends up in the self hosting path, which is the second route in the documentation.

Self hosting through the container images

The self hosting instructions point at a wiki page for deployment, and the images are published in two registries. GitHub Packages, under the jellyfin-vue package, is the recommended one, and Docker Hub is the alternative, with the README noting that both carry the tagged images.

The presence of a container image for a front end is worth pausing on, because it changes what hosting the client means. A static bundle could be served by any web server, and a container image means the project ships a runtime configuration, an nginx or similar entry point, and a specific node or build environment baked in. For a self hoster, that is convenient, because the thing you run is the thing the project tested, and it is a fixed unit you can put behind your own reverse proxy alongside the Jellyfin server itself.

The README badges show the same two registries being tracked, with Docker Hub pull counts and a GitHub packages badge, so the distribution story is deliberately dual. The Wiki page is the current source of truth for the deployment instructions, which is the right place for something that changes as the image is restructured.

For anyone evaluating this, the practical sequence is short. Point the client at a server, see whether the feature set you use exists, and only then think about where it will run. The hosted instance makes the first step nearly free, and the container images make the second step a pull and a run.

The privacy argument, made carefully

The privacy disclaimer is the most substantial piece of writing in the README, and it addresses an obvious objection: if a third party serves the web client, they are in a position to see what you do with your media server.

The claim is that Jellyfin Vue is just a graphical user interface for a Jellyfin server, and that it only establishes a connection to the Jellyfin server you point it to, nothing else.

The explanation then splits by case. For local instances, such as the Windows, Mac or Linux application, a local web server, or a client bundled into a Tauri or Electron environment, all the assets the front end needs are available locally or bundled into the environment where it runs, and no assets need to be fetched remotely.

For remote instances, which the note says probably comprise most cases, the assets are not local but somewhere else, and when you access a remotely hosted front end in a browser, all the front end assets are loaded and cached into your device. Once that load has finished, the connection is exclusively between your device and the Jellyfin server, and whoever is serving the front end is never in the middle.

That is a real and correct piece of web architecture reasoning. A front end is static code, and once it is cached by the browser it cannot observe what happens between your device and your server, provided the connection to the server is direct and encrypted. The caveats in the footnotes concern the hosted version's cache headers and the connection being to the server you specify, and they are the details an audit would check.

What this does not cover is the case of an administrator hosting the client for others, and a team that wants to reason about it should read the full note rather than the summary.

A pnpm monorepo with a very tight engine pin

The root package manifest is a workspace coordinator rather than an application manifest, and it shows the project's engineering conventions.

Every script fans out across the workspace packages with pnpm -r and the if-present and no-bail flags, so a package that does not define a script does not fail the run:

pnpm -r --if-present --no-bail check:types
pnpm -r --if-present --no-bail lint
pnpm -r --if-present --no-bail test

There is also an analyze:cycles script in the same style, which is a dependency cycle checker, and that is the kind of check that matters in a monorepo of this size where an import cycle between packages is easy to introduce and hard to see.

The toolchain constraints are strict and explicit. The package manager is pinned to [email protected] in both the packageManager field and the engines block, and the Node requirement is a range, at least 24.11.0 and below 25.0.0. A range rather than a floor is a deliberate choice, because it prevents a build on a major version the project has not tested, and it means a contributor cannot accidentally produce a build on Node 26.

The other signals in the README are worth a glance. Conventional commits is a badge, the project uses a translation platform for its interface, code coverage and a set of SonarCloud quality badges are published, and there is a feature request tracker, a Matrix chat and a Reddit community.

The tags stopped in 2023, the branch did not

The release history is the most surprising fact in the repository, and it needs reading carefully.

There are three tags. Version 0.2.0 is described as the last release with Vue 2, published on 2023-04-03 at 10:50. Version 0.3.0, the first Vue 3 release, was published the same morning at 10:55. And 0.3.1, dependency updates for Vue 3, followed at 12:59. All three are from a single day in April 2023.

Since then, the branch has kept moving. The last push was on 2026-10-18, and the end user instructions talk about bleeding edge builds from the current master branch with no stable releases yet. The version in the root manifest is still 0.3.1, matching the newest tag.

So the numbering stopped while the work continued, which is a common pattern for a component that ships inside a larger platform rather than as a product of its own. The consequence for an adopter is concrete. There is no release to pin, so the hosted instance and any container tag you pull are moving targets, and the tag numbers tell you almost nothing about the age of the code you are running.

The practical response is to treat the container image tag as the version, record what you deployed, and read the changelog or commit history rather than the release list. The Conventional Commits badge suggests the history is structured enough to read.

GPL-3.0-only, and a community that funds the work

The licence is GPL-3.0-only, declared in the package manifest and matching the licence file at the root of the repository and the badge in the README. For a client that is distributed as a web application and as container images, the copyleft reaches anyone who distributes a modified version, and the container distribution makes that more likely to apply than a desktop application would.

The rest of the project infrastructure shows a mature, community run effort. There is a.devcontainer directory for a ready made development environment, a translations platform linked from the README for the interface, an Open Collective badge for donations, a feature request tracker where votes are collected, a Matrix room for chat, a Reddit community, and a published set of SonarCloud quality metrics covering coverage, maintainability, reliability, vulnerabilities, code smells, technical debt, duplicated lines, bugs and security rating.

Publishing that many metrics is unusual and slightly awkward, because a coverage badge is a number rather than a quality argument, but the maintainability, reliability and security ratings are the ones with any meaning for a team deciding whether to adopt a client. The rest of the documentation, the privacy note in particular, is written with more care than the badge wall suggests.

The judgement for an adopter is straightforward. This is an experimental client with a clear purpose, a well explained privacy model and an active branch, and it is not a replacement for the supported web client.

Editorial conclusion

Adopt jellyfin-vue if you want to try an alternative interface for your own Jellyfin server, are willing to run bleeding edge builds, and can serve the client over HTTPS behind a reverse proxy. Do not adopt it for a household that needs a supported client, since the project states it is not feature complete and is not planned to replace the main Jellyfin Web client. Verify three things first: that your server is reachable over HTTPS through a reverse proxy, since the hosted instance will not work otherwise, that the container image you pull matches the branch you expect, and that the Node and pnpm versions in the manifest are what your build environment provides. The last push was on 2026-10-18, the most recent tags are 0.3.0 and 0.3.1 from 2023-04-03, and the licence is GPL-3.0-only.

Frequently asked questions

Official sources

1. jellyfin/jellyfin-vue on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases