Future of assemblrr

[soulis-1256]

Hi everyone — this is the start of an open conversation about where assemblrr could go next, and what (if anything) should be built on top of it. Strong opinions are welcome; please keep it respectful and constructive.

Assemblrr itself stays what it is today: a way to bootstrap and wire a self-hosted media stack. This thread is about product vision, not a promise that every idea will ship.

What assemblrr is today

This project aims to be as close as practical to a one-click (or express) setup for most of the *arr stack.

With express install you mainly:

• optionally configure a VPN,
• pick a username/password,
• and go.

The same credentials are reused across services so you can open each UI quickly and get oriented. That’s weaker than per-service secrets or SSO — I know. For a home lab, many people still want “one password and I’m done.” Manual mode and later hardening can provide options for people who want stricter setups.

Under the hood, the “engine” is still the usual pieces: download client, Radarr/Sonarr, Prowlarr, quality tools, etc. The human-facing surface after a good setup is mostly:

• Seerr — browse / request
• Jellyfin (or similar) — watch

Assemblrr’s job today is to make that engine install and interconnect with as little pain as possible.

Vision: from “stack” to “experience”

If the stack is configured well, the day-to-day mental model shouldn’t be five bookmarks — it should feel closer to a single app:

Today (two apps)	Possible future (one experience)
Seerr to request	One place to discover & request
Separate UI for status	Progress for grabs/downloads in the same place
Jellyfin/Plex to play	Player (or deep embed) for your library

Mainstream streaming products (like Netflix) already merge catalog + request-ish UX + player. A self-hosted path could aim at the same shape of product, while remaining:

• self-hosted,
• modular (engine services still exist underneath),
• and honest about what the software does (orchestration and UX — not a content source).

I’m calling that idea a “super-app” for lack of a better name: request library + download/progress visibility + playback of your files. It might be a new UI, a tight integration layer, or evolution of existing projects — this discussion is partly to figure out what is worth building.

Trade-offs I’m already thinking about

1. Separation of concerns vs convenience

Keeping Seerr and Jellyfin separate is often lighter and more flexible:

• Jellyfin on the TV, Seerr on the phone
• Independent updates, permissions, and resource use

A combined experience adds some redundancy (storage, and maybe RAM/CPU if everything runs at once) in exchange for convenience:

• browse library and continue watching without jumping apps on the phone
• pick “what’s next” from the TV if the phone isn’t around

I’d rather treat that as an explicit product choice (optional unified UI vs classic split apps), not force one model on everyone.

2. Automation vs control

A polished front-end will lean on automation: indexers, quality profiles, “pick a release for me.” That’s great until the automatic choice is wrong — wrong release, bloated size, bad encode, failed grab, etc.

So any “super-app” should not trap people:

• advanced / “open in Radarr or Sonarr” for interactive search and manual grabs
• clear status when automation is stuck
• keep the full *arr UIs available for power users

In other words: convenience by default, escape hatches when the algorithm guesses poorly. That’s a UX problem for legitimate home libraries and automation generally — not a reason to hide the engine.

What Assemblrr is not

To keep expectations (and the project) clean:

• Assemblrr does not host, sell, or supply media.
• It does not decide what you’re allowed to put in your library.
• Indexers, download sources, and files are your configuration and your responsibility under your local laws.
• The project is dual-use infrastructure (like a download client or a media server). Please use it lawfully.

What I’d like feedback on

1. Does a unified request + progress + play experience excite you, or do you prefer hard separation forever?
2. If a super-app existed, what must stay one click away in Radarr/Sonarr/Prowlarr?
3. Should assemblrr stay “installer + CLI” only, or grow toward optional higher-level apps?
4. Security: is shared express credentials fine as a default if manual/hardened paths exist?
5. What would you not want Assemblrr to become?

Maintenance & funding

I don’t currently have the time to maintain this project at the level it deserves. My day-to-day work is building my proprietary applications and projects so I can earn a living — open source has to fit around that, not the other way around.

That means:

• Bugfixes and small improvements may still land when I can spare cycles, but I can’t promise a full-time maintainer cadence.
• Community contributions (issues, PRs, discussion feedback) are welcome and help a lot.
• I am open to actively maintaining and expanding assemblrr — including the “super-app” direction above — if there is enough funding to make that sustainable.

If this project is useful to you and you want that future to happen, sponsorships help more than stars alone. You can support via PayPal.

Thanks for reading.