Rebuilding a community-critical workflow

Community Apps is one of Unraid’s most important surfaces. It is how users find containers and plugins, how maintainers reach the community, and how moderators keep a large catalog usable. The live catalog is at ca.unraid.net. I led the move of the entire appfeed into Cloudflare Workers — with a Nuxt + Nuxt UI frontend — and rebuilt the data and moderation pipeline behind it: repository ingestion, feed generation, admin search, validation, moderation, statistics, database synchronization, and publication safety. The Worker went to production in December 2025; I authored roughly half the commits in the Workers monorepo it lives in.

This was not only a performance project. A public app catalog is a trust surface. If search is bad, users cannot find the right app. If validation is weak, broken templates produce install failures. If publication workflows are risky, a bad build can take the catalog down for everyone. If operators cannot search the full dataset, moderation gets slower and less reliable. So I approached Community Apps as a data-integrity problem, not just a UI.

The product problem

The Community Apps backend handles third-party repositories, shifting metadata, external registry constraints, plugin templates, container images, maintainer identities, moderator decisions, and a public feed consumed by users running real servers. The system needs to stay permissive enough for community contribution while protecting users from broken or low-quality entries.

Cloudflare Workers gave the project a better place to run feed generation, admin APIs, validation jobs, and data-backed workflows. The fit was practical: fast request handling, clear API boundaries, and infrastructure that sits close to the public feed while still integrating with Postgres for deeper queries.

What I built and shipped

• A server-backed /api/admin/repositories search, filter, and sort endpoint so moderators query the full dataset instead of only the rows already loaded in the browser. I added admin list virtualization on top so large repository views stayed usable.
• Preview-to-production database sync workflows so feed validation runs against real data before changes go live, with preview-feed validation as part of the release cycle.
• Moderation override tools and the appfeed moderation table, with reliable delete behavior and clearer failure visibility for operators. The fix made moderation failures easier to diagnose instead of only patching the symptom.
• Appfeed publish safeguards so a bad or incomplete build cannot demote the active feed, and so feed generation falls back to conservative defaults instead of silently producing partial output.
• Repository profile and identity work that took account-linking, forum/IPS identity, and maintainer trust seriously. Older migrated accounts may have a forum IPS ID; newer Cognito-only accounts may not. Plugin submissions should likely require a valid forum identity, while Docker containers have more flexible support-URL requirements, and the submission flow needed to encode that difference.
• Repository claim flows and a “my submissions” view so legacy CA maintainers had a real account-linking path for historical repo ownership instead of filing support tickets.
• A planned report/feedback button on each app entry, framed as a catalog-issue report (broken template, unmaintained plugin, suspect metadata) rather than a generic “Unraid will fix this” promise. The important product choice was where those reports should land and what users should expect after submitting them.
• GitHub handoff behavior for repository fixes, issue context, and change review so a moderation action becomes a productive conversation with a maintainer.
• Postgres integration testing for database-backed workflows so catalog data does not silently drift between environments.
• Search relevance work: ranking, grouping, deduplication, conflict handling for duplicate or near-duplicate entries, and visibility into deprecated or pull-failing templates.
• Image pullability and external registry awareness so validation reflects real install conditions instead of passing on shape alone.
• R2-backed streaming for large feed assets, which eliminated a class of out-of-memory failures, plus geo-aware edge caching and a CDN asset proxy with obfuscated, server-keyed URLs.
• An MCP server with OAuth 2.1 and dynamic client registration, so admin and AI tooling talk to the catalog through a properly authenticated, auditable interface.
• A download-count statistics pipeline, SEO cards, and localized routes so the public catalog works as well for discovery as it does for operations.
• Security and unexpected-condition testing so moderation, feed publication, and validation paths failed visibly instead of silently.
• Translation updates and Crowdin coordination so non-English users get the same catalog experience.

AI and workflow support

AI was useful around the edges of this project because the work had a lot of structured but scattered context. It helped summarize implementation state, move task detail into newer planning systems, and draft follow-up work in a form that engineers and product owners could act on. The boundary I set: AI did not decide moderation policy and did not silently change the public feed. It reduced clerical load and preserved context.

Community Apps automation has to stay conservative because the catalog is maintained by people and trusted by users. Automation can flag problems, prepare handoffs, generate summaries, or propose low-risk fixes. Product judgment decides where automatic action is appropriate.

Outcome

The result is a stronger catalog pipeline for a community-critical product area. Users get better discovery, a more reliable feed, and a catalog that is less likely to ship them a broken template. Maintainers get clearer ownership and handoff paths. Moderators get full-dataset admin search, stronger validation, and tools that handle more than small lists. Engineering gets real tests, database sync workflows, and safer feed publication.

Community Apps combines community energy with product distribution. This work made that combination easier to operate: faster search, clearer moderation, better validation, safer releases, and fewer manual steps between a repository change and a dependable public feed.