← statichum.studio

Self-hosters repeatedly burn hours trying to get the standard media stack (qBittorrent/Gluetun + Prowlarr + Sonarr/Radarr/Lidarr + Jellyfin/Plex) actually talking to each other. Installing the containers is the easy part; the soul-crushing part is the interconnection — consistent volume/path mapping for hardlinks, download categories, indexer wiring, and remote-path mapping. People want an appliance that does the wiring for them and validates it end-to-end, aimed at intermediate users who are not Docker experts.

builder note

The differentiator is a configuration validator/wizard, not another installer. The hard, valuable part is encoding the tribal knowledge — shared hardlink-friendly volume layout, download-client categories, Prowlarr→arr sync, remote path maps — and then actively testing the full grab→import→rename→library chain and surfacing the exact broken link. Ship the diagnostics ('your /downloads path differs between qBit and Sonarr') and you've built what every 'please share a working compose' thread is really begging for.

landscape (3 existing solutions)

One-click install of *arr apps is a solved problem; what is not solved is automatically wiring them together correctly and proving the chain works. Existing tools either assume sysadmin skill (Saltbox) or stop at installation (CasaOS/DockSTARTer), leaving path mapping and indexer/category wiring as the recurring failure point that frustrates non-expert self-hosters.

Saltbox Battle-tested but Ansible-based and opinionated — recommended in the thread yet still demands real Linux/Ansible comfort and a clean VPS; it solves deployment for advanced users, not the wiring-comprehension problem for intermediates.
DockSTARTer / CasaOS / ZimaOS Make installing the individual apps easy (TUI/app-store one-clicks), but the user still has to manually configure the cross-service connections, path consistency, and indexers — which is exactly where people get stuck, including in 2026 guides where 'path mismatch' is still the #1 error.
Yams.media / Dockge / compose generators Guided installers and compose generators reduce friction and hand-hold setup, but none fully auto-detects and validates the interconnections (categories, remote/hardlink path mapping) and tells you what's actually misconfigured — there is no 'it works and here's proof' verification step.
sources (1)
other https://lemmy.world/post/48310412 "6 hours worth of what doesn't work" 2026-06-18
self-hostedarr-stackdockermedia-automationonboarding

People with terabytes of personal video (GoPro, phone clips, family archives) want to search the contents the way photo tools already let them search images: 'find the clip where the kid blows out the candles', by object, face, scene, or spoken word — running locally on their own machine, not a cloud service. Photo managers nailed image search but treat video as a single thumbnail frame, and the pro tools that can do it are editing suites, not household media libraries.

builder note

Don't compete with editors — the wanted product is a 'Photos app for video' that runs offline. The real moat is making indexing cheap and tolerable (smart frame sampling instead of every frame, and suppressing Whisper's non-speech hallucinations); whoever makes a non-technical person able to point it at one folder and get useful results overnight wins, because Immich users have been asking for exactly this for over a year and the project keeps deferring it.

landscape (3 existing solutions)

Image search is solved (Immich, Google/Apple Photos), but video content search is a stubborn gap: self-hosted photo tools index video as a thumbnail, and the tools that can search video content are pro editors. Open questions builders must beat are processing speed (commenters note it can't take longer to index than to watch) and Whisper hallucination on non-speech audio.

Immich (self-hosted photo/video) Excellent local CLIP smart-search and face detection for photos, but its smart search is image-based; video content (per-scene objects, speech-to-text) is a long-requested enhancement that is not shipped — video is effectively indexed by a thumbnail frame, so you can't search what happens inside a clip.
DaVinci Resolve (AI IntelliSearch) Has local AI scene/face search, but it is a professional non-linear editor aimed at editing a project timeline, not a household 'search my whole library' archive manager — wrong tool, steep learning curve, and not built around browsing a years-deep personal collection.
edit-mind / Jumper (commercial local video AI) Emerging commercial local-ML video tools exist and validate the demand, but they're editor-workflow oriented and priced/positioned for creators; commenters specifically ask for something an ordinary non-technical person can point at a folder and use, with reasonable processing time.
sources (1)
hn https://news.ycombinator.com/item?id=48528029 "find moments, people, colors, objects" 2026-06-14
videolocal-firstsemantic-searchself-hostedmachine-learning

Microsoft is moving Windows users onto 'new Outlook' (a WebView2 web-wrapper) as the default in the 2026 opt-out phase, and power users report it is dramatically slower and missing core features. The unmet need is not 'another pretty email app' (those exist) but a fast, truly native client that replicates the enterprise muscle Classic Outlook users depend on: server-side rule sweeps, public folders, COM add-in compatibility, and full Exchange calendar/contacts.

builder note

The email-client graveyard is real, so don't pitch 'a nicer inbox.' The only defensible wedge here is the boring enterprise plumbing every lightweight client skips — add-in compatibility, public folders, and server-side rules over Graph API — and the Oct 2026 EWS shutdown is the forcing function that makes 'we already support Exchange' clients have to re-earn their integration anyway.

landscape (3 existing solutions)

Fast native clients with basic Exchange support already exist (eM Client; Thunderbird's new EWS), and Classic Outlook survives to ~2029, so the mainstream is covered. The genuinely unmet sliver is enterprise power-user parity — COM add-ins, public folders, server-side rule execution, full Exchange calendar — in a client that isn't a slow web wrapper, made more urgent by the Oct 2026 EWS-to-Graph cutover that disrupts even the alternatives.

eM Client Verified native, fast, supports Microsoft 365/Exchange mail + calendar; free for home use (limited), ~$40/yr Pro. Covers the mainstream case, and advertises Exchange public-folder support. The remaining gap vs Classic Outlook power users is the COM add-in ecosystem, which eM Client does not support — add-ins are the hard blocker for enterprise workflows tied to specific add-in integrations.
Thunderbird 145 (native Exchange/EWS) Added native Exchange EWS email in Nov 2025, but calendar/contacts are still on the roadmap (not shipped), there is no Outlook add-in compatibility, and Microsoft sunsets EWS for hosted Microsoft 365 in Oct 2026, forcing a Graph API rewrite Thunderbird is still building.
Classic Outlook (staying put) Still the real fallback: support is extended to ~2029 for perpetual/Microsoft 365 desktop installs, so most affected users can simply keep Classic for now. This blunts urgency and is why this is a long-horizon bet, not a this-month panic.
sources (1)
hn https://news.ycombinator.com/item?id=48584207 "new Outlook takes 10 seconds to do what Classic does instantly" 2026-06-18
emailoutlookexchangewindowsenterprise