# Wizarr: an SSO asterisk with no footnote, and a manifest that still says add your description here

> An invitation and access manager sitting in front of seven media servers, with a Flask backend of thirteen extensions, one vendor client library, browser tests, two type checkers and a three stage container image that compiles translations with fuzzy entries allowed. Its README has no installation step at all, and the single sign-on line in its feature list ends in an asterisk that is never explained.

**wizarrrr/wizarr** — Wizarr is an advanced user invitation and management system for Jellyfin, Plex, Emby etc.

- Repository: https://github.com/wizarrrr/wizarr
- Website: https://docs.wizarr.dev
- Stars: 3,239 · Forks: 205
- Language: Python
- License: MIT
- Published: 2026-08-21 · Updated: 2026-08-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/wizarrrr-wizarr

## The single sign-on line ends in an asterisk nothing explains

The feature list is ten bullets long and one of them is different from the rest in a way that matters. Plug-and-play single sign-on support carries an asterisk, and the visible text has no footnote after it, no note further down, and nothing in the installation pointer that would resolve it. The other bullets are unqualified: automatic invitations for the seven named servers, a user-friendly invitation process, multi-tiered invitation access, time-limited membership, wizard steps before and after the invitation, a setup guide for media apps, integration with request systems, Discord invites, and custom HTML snippets. Whatever the asterisk was going to say, a reader of this file cannot find it, and single sign-on is exactly the capability an administrator would want to confirm before handing an invitation system a directory of accounts.

## The Python manifest still carries its scaffolding text

The two manifests agree on the version, both reading 2026.9.1 to match the newest release tag, and they disagree on everything else worth reading. The Python manifest's description field still contains the placeholder sentence a new project template ships with, so the package index description for the server application is an instruction to a human. The Node manifest next to it has a real description, and that one names four servers rather than the seven the README lists. It also declares itself private and requires a recent Node runtime, and its scripts object is empty, which is consistent with the container image, where the front end is built from a separate manifest inside the static assets directory. The version scheme is a calendar one, so a release named for a year and month tells you when it was cut rather than what broke.

## One vendor client library for seven servers

The dependency list is thirty-one packages and it explains the architecture better than the prose does. Thirteen of them are extensions for the same web framework, covering sessions, login, forms, database access and migrations, templating through one extension, message translation, scheduled jobs, request limiting, server-rendered interactivity, and a REST layer with automatic documentation. Of the seven supported media servers, exactly one has a client library present. The rest have no vendor package in the list at all, which means those integrations are built on direct HTTP calls rather than on an official client. Also present are a directory access library, a passkey library, a notification library, an HTML sanitiser, a cache library and a structured logging library, plus the build system itself sitting in the runtime requirements.

## Both documented API addresses are plain http

The API section is short and specific. There is a REST API, described as comprehensive and intended for automation and integration, with documentation generated automatically in the OpenAPI and Swagger formats. Two addresses are given, one for the interactive documentation and one for the specification as JSON, and both are plain http with the host written as a placeholder meaning your own instance. So the documentation tells you the paths and tells you the shape of the API, while leaving the scheme to you. That is a reasonable thing for a self-hosted project to do, and it is also worth noticing that the only two URLs in the README that name your own deployment are unencrypted, in a project whose whole job is handing out links that add people to a media library.

## The README has no install step, and ends on an empty heading

The getting started section is two lines long and neither is a command. It says to check the documentation for how to install and run the project, and gives the address of that documentation site along with the path of its installation page. Everything a newcomer needs is therefore one click away and nothing is in the repository itself, which is a defensible choice for a project with this many deployment shapes. The file then closes with a heading for screenshots and nothing under it, while a screenshots directory sits in the tree. The header is also worth a glance: three consecutive badges all point at the same repository address, which is what a set of badges degrades into when the image references are stripped in one rendering of the file.

## The container compiles translations with fuzzy matches allowed

The image is built in three stages and the middle one is where the interesting decisions are. Dependencies go in first, with the package manager's own interpreter image, a cache mount, and a frozen sync from the lock file, followed by the front end installed from a manifest inside the static assets directory. The builder stage then copies the source, syncs the project, compiles the translation catalogues with a flag that includes fuzzy entries so pending translations are bundled rather than left blank, and finally runs the front end build behind an environment variable that is only set during the image build. The runtime stage starts from a clean interpreter image and sets defaults for a user and group identifier, the listen address and a port, which is the usual pattern for mapping host users into a container without root.

## Eleven framework extensions and two type checkers

The development dependencies are as opinionated as the runtime ones. Tests run under one framework with a Flask-specific plugin, a mocking plugin and a browser automation plugin backed by a real browser driver, so the suite drives pages rather than only calling views. Type checking is done twice, by two different checkers, which is unusual and suggests a migration rather than a preference. A linter runs with a target version matching the required interpreter, an eighty-eight character line limit, and a rule set that includes a ban on print statements. There is a separate linter for HTML templates, one whose purpose the manifest does not explain, and a commit message tool. And the package manager is configured to disable development groups by default, with a comment saying it is so production containers do not install them.

## A root directory containing a file named plus

The top level is unusually wide for a Python application and several entries are unexplained by anything in the README. There is a file named plus with no extension. There are three small scripts with obvious names, one for development, one to run, and one described as a recovery tool. There is a server configuration file for the WSGI server, a translation template and its configuration, a migrations directory, and a directory whose name matches the wizard feature. There is an architecture document for the wizard, an Unraid template, a second compose file for testing, an entrypoint script, a message catalogue, and configuration directories for a translation service, a template linter and an editor. Two of those editor directories sit side by side, which is the clearest sign in the tree of a project being worked on by more than one kind of tool.

## Conclusion

This is a good fit if you run one of the seven supported servers for friends and family and the tedious part is the invitations rather than the media. Three things to check before you deploy it. The feature list's single sign-on line is marked with an asterisk and nothing in the visible documentation says what that qualifies, so treat that capability as unconfirmed. The Python manifest still carries the scaffolding text where a description belongs, which tells you the packaging metadata is not the place to read about. And the only vendor client library in the dependency list is for one of the seven servers, so read the documentation for the other six before assuming parity.

## FAQ

### What does Wizarr do?

It is an automatic user invitation and management system for seven media servers: Plex, Jellyfin, Emby, Audiobookshelf, Romm, Komga and Kavita. You create a unique invite link, and the person receiving it is added to your server automatically and guided through downloading apps and reaching request systems.

### How do I set up wizarr?

The README carries no installation steps of its own. It points at the project's documentation site and gives the path of its installation page, while the repository supplies a Dockerfile, a compose file, an entrypoint script and an Unraid template.

### Which media servers does Wizarr support?

Seven are named in the README: Plex, Jellyfin, Emby, Audiobookshelf, Romm, Komga and Kavita. The Node manifest's description names only four of them, and the Python manifest's description is still the placeholder text from a project template.

### Does Wizarr have an API?

Yes. It describes a REST API for automation and integration with documentation generated automatically in the OpenAPI and Swagger formats, served from a path under your own instance's address, with the specification also available as a JSON file at another path under the same address.

### What does the asterisk on Wizarr's single sign-on feature mean?

The feature list marks plug-and-play single sign-on support with an asterisk, and no footnote appears in the visible text. The rest of the bullet list is unqualified, so the qualifier is not recoverable from this file.

## Sources

- [Official documentation](https://docs.wizarr.dev)
- [Official README](https://github.com/wizarrrr/wizarr#readme)
- [Project repository](https://github.com/wizarrrr/wizarr)
- [Release notes](https://github.com/wizarrrr/wizarr/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wizarrrr-wizarr