Fladder: a Jellyfin frontend written in Flutter for every screen you own

One Flutter codebase, six shipping platforms

Fladder describes itself as a cross-platform Jellyfin frontend built on top of Flutter, and the repository is built to back that claim. It is Dart, GPL-3.0, around 2,600 stars, 177 forks and 174 open issues, with `develop` as the default branch and the last push on 2026-09-18.

The platform directories in the tree are the proof: `android/`, `ios/`, `linux/`, `macos/`, `windows/` and `web/` each carry their own runner, while the shared Dart code lives in `lib/`. A `.fvmrc` file records which Flutter version the maintainer develops against, which matters in practice because Flutter SDK upgrades routinely break build pipelines.

That shapes how you read the release list. There is a `nightly` tag built from `develop` with an explicit warning that it is a development build, and stable tags in the v0.11 range. A project shipping binaries for six platforms from one codebase produces a lot of packaging work, and the presence of `flatpak/`, `snap/`, `AppImageBuilder.yml`, `fastlane/` and `altstore.json` says most of that work is automated rather than done by hand each release.

Running the web build yourself behind nginx

The web build is the one you can inspect without installing anything. The repository ships a hosted demo at DonutWare.github.io/Fladder, and the README is upfront about its limitation: the GitHub-hosted build only allows `https` connections because GitHub Pages will not serve plain `http`, while a self-hosted copy works fine over either.

Self-hosting it is a static site behind nginx, and the `Dockerfile` in the tree is short enough to read in full.

FROM nginx:alpine

EXPOSE 80

ENV BASE_URL=""
ENV SEERR_BASE_URL=""
ENV SEERR_HEADER="null"
ENV FLADDER_WEBPATH="/"

COPY build/web /usr/share/nginx/html

Those four environment variables are the whole configuration surface. `BASE_URL` locks the frontend to one specific Jellyfin server, `SEERR_BASE_URL` presets a Seerr address, `SEERR_HEADER` takes a JSON object of headers for that integration, and `FLADDER_WEBPATH` serves the app from a subpath instead of the root. A `Dockerfile-rootless` and a matching `docker-compose.yml` are also in the tree for setups that cannot run a root container.

Music playback arrived in v0.11.0 and is still called beta

The release notes for v0.11.0, published 2026-08-30, are mostly about music, which the notes say arrived after a long time. The list is longer than a first attempt usually is: a music dashboard reachable by long pressing the home button, gapless playback, volume normalization, a fade in and out when pausing or switching between tracks from different albums, lyrics, and syncing of playlists, albums and tracks.

The maintainer is direct about the state of it. Music is described as probably best considered beta, with small bugs and annoyances acknowledged, and Android TV player control navigation called cumbersome with an intention to improve it alongside other dPad work. That candour is worth more than the feature list, because Android TV is exactly the case where a media client lives or dies.

Version 0.11.1, published 2026-09-08, was a hot fix for local network connections failing on Android, with the rest of the changelog unchanged. Picture-in-picture arrived alongside music in v0.11.0, and the filters in the library search view were reworked in the same release. Roughly one stable release a month on a project with this many platform targets suggests the packaging side is in decent shape even while a feature is still settling.

Sync, profiles and the Seerr integration

The feature list in the README is where you can tell what Fladder expects to be used for day to day. Playback covers direct play, transcode and offline playback, with media segment skipping for intros and credits and trickplay support for scrubbing a timeline. Multiple profiles let several users or several servers be added and switched between, and server management sits alongside that.

Cross-device behaviour gets three separate lines in that list: sync items for all platforms, download items with progress kept in sync, and next-up overview when working through a queue. Downloads with synced progress are the feature most likely to change how you use the client, since it means a film started on the television can be finished on a train without losing your place.

Two smaller entries are easy to miss. Comic book format reading covers `.cbz` and `.cbr` files, which is unusual in a Jellyfin client and useful if your library has scanned manga. The Seerr and Jellyseerr integration lets request management live next to playback rather than in a separate browser tab.

The `docker-compose.yml` in the tree is where those integrations get configured at runtime.

services:
  fladder:
    image: ghcr.io/donutware/fladder:latest
    ports:
      - 80:80
    environment:
      - BASE_URL=https://server-url #OPTIONAL: Locks the Fladder front-end to a certain jellyfin server
      - SEERR_BASE_URL=https://seerr-url #OPTIONAL: Presets Seerr base URL
      - FLADDER_WEBPATH=/ #OPTIONAL: Configures a subpath to run Fladder at

The image is published to GitHub Container Registry under the donutware namespace, and the compose file comments note that a `fladder-rootless` image exists for rootless setups.

What the repository tree says about the build process

A Flutter project of this size carries more infrastructure than most people expect, and the tree lists it plainly. `build.yaml` drives Flutter build commands, `analysis_options.yaml` sets lint rules, and `devtools_options.yaml` configures the debugger. `l10n.yaml` handles localization, which fits a client shipping to users across many languages.

Two directories suggest a specific approach to the platform boundary. `pigeons/` holds generated-interop definitions, the code-generation pattern Flutter uses to let Dart call into host platform code, which is how features like picture-in-picture and system media controls reach native APIs on Android and iOS. `swagger/` suggests the Jellyfin API surface is described locally rather than only on the documentation site, so regenerating a client against a server version is a deliberate step in the workflow.

`test/` holds the Dart tests and `.github/` holds the build workflow whose badge sits at the top of the README. `DEVELOPEMENT.md`, `INSTALL.md` and `CONTRIBUTING.md` are separate documents, and the release notes are generated from a `.github/release.yml` configuration, which is why every version has the same shape.

Where Fladder stops and Jellyfin's own docs begin

The README is a feature list, a wall of screenshots in mobile, tablet and television sizes, and a link to try the web build. It is an honest advertisement rather than a manual. Anything about how a specific Jellyfin API behaves is Jellyfin's business, and the Fladder docs cover Fladder.

The more useful comparison is against the official clients rather than against other third-party frontends. The official Jellyfin clients are native per platform, which usually means better integration with one specific platform and a smaller download. Fladder's answer is that one codebase means one feature set everywhere, so a phone and a television behave the same way and sync between them cleanly.

Known gaps are listed rather than hidden. Chromecast support is on the planned list, as is improved dPad navigation for non-TV devices. The last nightly build, published 2026-09-18, carried build number 834 from `develop`, so a reader who wants current behaviour rather than stable behaviour can take that artifact and accept the warning that comes with it. Everything else is in the release notes and the issue tracker, with 174 issues open at the time of writing.

Editorial conclusion

Fladder's argument is coverage. A single Flutter codebase produces a client for the television, a client for the phone and a self-hosted web build, which is a different trade from the official clients being native per platform and from Jellyfin Media Player being desktop-only. It has the feature set you would expect from a mature client now: music with gapless playback and lyrics, picture-in-picture, segment skipping, trickplay scrubbing, multiple profiles and sync across platforms. The README is a feature list plus a link to a hosted demo build, so version specifics live in the release notes, where v0.11.0 and v0.11.1 added music and picture-in-picture and called music beta. If you want one app that covers the TV and the phone, install the nightly build, point it at your server, and judge the Android TV dPad navigation yourself, since the maintainer already lists it as a known weak spot.

Frequently asked questions

Official sources

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