Should Oscarr offer an "admin-only" mode (requests as a plugin)?

[arediss]

Open question, no decision yet — gathering feedback.

The idea

Today Oscarr is a media-request portal that also has a plugin host. The
plugin engine + dashboard widgets are mature enough that a non-trivial number
of self-hosters could legitimately use Oscarr as a pure admin portal for
their stack (Sonarr / Radarr / Plex / Jellyfin / custom plugins) without
ever caring about the request-media side.

Two shapes have been floated:

Option A — runtime toggle (mediaRequestsEnabled)

Big master switch in admin: ON = current Oscarr, OFF = login + admin + plugins
only. Hides nav (Home / Requests / Calendar / Support), and admin sections
that are only meaningful when requests exist (Quality, Paths, Rules, …).

Option B — extend the existing feature flags

Don't invent a new "mode". Push requestsEnabled (already in useFeatures)
further: hide the request-related admin tabs when off, redirect / to a
plugin-driven dashboard, and document an "admin portal" preset / Docker
variant for people who want a locked-down install.

Option C (long-term, philosophical)

"If I'd known, I'd have built the admin portal first and made media-request
itself a plugin." — original author

Spinning the request feature out into a first-party plugin would be the
cleanest separation, but it's a real refactor (the request flow is currently
deeply coupled to core: services, requests table, Radarr/Sonarr glue,
notifications, calendar, support tickets…). Probably not worth doing
retroactively unless the rest of the codebase pushes us there organically.

Tradeoffs to weigh

Pro (any option):

• Clearer positioning for non-request use cases.
• Lighter UI for admins who don't need the user-facing portal.
• Aligns with where the plugin engine is heading.

Con:

• Identity drift — Oscarr's strength right now is being a polished
  user-facing portal with a plugin host. Stripping that puts us in the
  Homarr / Homepage / Dashy territory, where the differentiator is less
  obvious.
• Scope tangle — deciding tab-by-tab in admin what's "request-related" vs
  "plugin-related" is grey. Services (Sonarr/Radarr/Plex) serve both sides.
• Two products, one repo — every PR has to consider both modes, plugin
  authors get an extra dimension to reason about.
• Marketing split — two value props ⇒ two docs, two onboarding flows, two
  screenshot sets. Real cost for a solo project.

Where I'm leaning (open to pushback)

Option B feels safest: lean harder on the existing feature flags + a
documented "admin portal" preset, without inventing a new binary mode. It
gives the same UX outcome to people who want it, doesn't fork the codebase,
and stays reversible.

But before deciding, curious what other self-hosters here actually want:

1. Would you run Oscarr without the request-media side? For what?
2. If yes, would a runtime toggle be enough, or would you want a separate
   build/image variant (locked admin-only, no toggle visible)?
3. Anyone here using the plugin host for things that aren't media-request
   adjacent? (curious which plugins.)

Drop a 👍 / 👎 / 👀 + a comment if you have an opinion.

[kedaewyn]

Hi !
I really like the idea of supporting “admin‑only” setups, but I’d be careful not to drift too far from what makes Oscarr strong today. For me, its core identity is a polished media‑request portal with a plugin host, not a generic Homarr/Homepage‑style dashboard.

That’s why option B looks like the sweet spot: lean harder on the existing feature flags, hide the request‑related UI when disabled, and document an “admin portal” preset or image. You still cover the admin‑only use case, but keep one product and avoid splitting the project into two half‑products that each compete with different tools