Unraid Community Apps support via an all-in-one image - interest in this living in-tree?

[tomzorz]

I want to get this into Unraid Community Applications, and I'm willing to build and maintain what that takes. Before I start, I'd like to know how you'd prefer it to exist, because that changes what I build.

Some context on the constraint: Unraid's Docker UI and the CA ecosystem are built around single containers. One template, one appdata folder, and the standard backup plugin snapshots that folder. Compose stacks are second-class there (plugin-only, no CA listing, manual backups). This came up before in #37, and @croche2574's PR #48 made the generator URL configurable to allow split-per-service containers, but as far as I can tell those templates never shipped, and N separate containers lose the one-unit backup story that makes Unraid apps pleasant.

So my plan is an all-in-one image instead:

• s6-overlay supervising Postgres 17 + pgvector, the migration step, the Rails web app, the Solid Queue worker, and the Python generator in one container
• built by multi-stage COPY --from= your published ghcr images at pinned release tags, so it tracks your binaries exactly rather than forking anything
• Postgres and the generator bound to loopback inside the container, only the web port published, which also keeps your single-user/loopback support boundary intact at the container edge
• volumes split into small app state (snapshotted by Unraid's backup plugin, with a nightly pg_dump inside for restorability), the meme library on the array, and a throwaway model cache
• CI that watches your releases and rebuilds, versioned <upstream>-aio<rev>

The question: would you want this in-tree as an official variant (a Dockerfile.aio + workflow, I'd PR it and maintain it), or should it live as a separate community repo that clearly labels itself unofficial? I'm happy either way, in-tree just means Unraid users get it from the source instead of trusting a stranger's wrapper image.

[neonwatty]

I love this idea.

think we'll want a separate repo to make sure we can run solid testing and CI on this.

I'm in the middle of creating a new organization we can put this repo under - this will also be a place for our other spin-off projects, which include currently a browser extension, plug-in and skills for agents, and native apps under development.

Should be ready in a few days, and I'll circle back.

[neonwatty]

All right - I think we're all setup.

The all-in-one approach makes sense for Unraid, and I’d prefer it to live in the new integration repository:

https://github.com/meme-search/meme-search-unraid

This keeps the Unraid-specific release, backup, upgrade, and support lifecycle separate from the core application.

One important limitation: Meme Search currently supports loopback-only operation and its web interface has no user authentication. My understanding is that an Unraid mapped port is generally LAN-accessible, we’re initially treating this as an experimental community integration.

I opened an issue to define the networking, storage, upgrade, and backup contract before implementation:

meme-search/meme-search-unraid#2

If this direction works for you, I’d be happy for you to lead the integration.