Organizr

What is Organizr?

Organizr presents your services as tabs in a single page and can put its own login in front of them, so one sign-in unlocks everything behind it. Built with media-server setups in mind.

Best for

One login in front of many separate services

Why choose Organizr

Organizr is a dashboard with a job beyond being a dashboard: it puts its own login in front of your services and presents them as tabs in one page, so a single sign-in unlocks everything behind it. That makes it useful not just as a launcher but as a lightweight front door and access layer, which is why it became popular in media-server stacks where a dozen separate web interfaces each have their own credentials. It supports tab groups, per-user permissions, and authentication backends so it can defer to an existing directory rather than maintaining its own user list. If your real problem is not finding services but authenticating to them, it addresses that directly.

Replaces

• Homer
• Authelia
• Heimdall

Key features

• Tabbed interface over many services
• Its own user management and login gate
• Groups and per-user access to tabs
• Deep integration with common media apps

What to watch out for

The single-sign-on it provides is a convenience layer, not a security boundary. It can pass credentials to backend applications, but those applications still have their own authentication, and Organizr does not make them safe if they were not. The project has an unusual history and an interface that shows its age, and documentation is scattered across a wiki whose structure is not obvious. Its reverse-proxy integration options for each backend application are fiddly to configure, and getting them wrong produces redirect loops that are tedious to debug. It is also a PHP application with the update discipline that implies, and it must never be exposed without TLS and a proper proxy configuration.

How to deploy

• Docker with PHP and a database
• Configure services as tabs
• Use the built-in authentication to gate them

Getting started

Set it up behind a reverse proxy with TLS first, because its whole purpose is mediating access and that is meaningless over plain HTTP. Choose authentication deliberately — its own user store or an existing backend — rather than leaving default credentials, which is the mistake that has exposed many instances. Add one or two services as tabs and get the proxy integration working before adding the rest, since each backend may need its own header or path configuration. Understand clearly that backend applications retain their own logins, and either keep them in place or secure them properly. Keep it on an internal network and include its database in your backups.

Typical setup

It runs behind a reverse proxy with TLS, because its entire purpose is mediating access and that is meaningless over plain HTTP. Authentication is configured deliberately — its own user store or an existing backend — rather than left at defaults. One or two services are added as tabs with their proxy integration working before the rest are added, since each backend may need its own header or path configuration. Backend applications keep their own logins rather than being treated as secured by the layer in front. Its database is included in backups and the instance stays on the internal network.

Who should look elsewhere

Do not treat it as a security product — it is a convenience layer over services that still have their own authentication, and anyone expecting it to replace a proper identity-aware proxy will be disappointed. Avoid it if you want a modern, actively evolving interface, because it is neither. And if you only want a page of links, the authentication machinery is complexity you do not need.

Project health

• GitHub stars: 5,818
• Last code push: 2026-05-19
• Open issues: 33
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.