Community Plugin Registry & Bundles

The registry is two pieces, both deliberately separate from any single DataCore deployment's own database, so they can be shared across independent installations:

• registry/ — the backend API, user accounts, and SQLite-backed store of listings.
• community-site/ — a standalone website (its own React app, own Docker service, port 5273) that lists and lets people post content without running the rest of DataCore at all. This is the primary way to reach the registry as its own destination — the main app's Resources/Plugins views also have panels for convenience, but everything talks to the same registry API and the same data.

It hosts two kinds of public listings:

• Plugins — name, description, author, version, a link to the plugin's repo, and (optionally) a Docker image reference and tags.
• DataCore Bundles — a shareable resource "recipe": a list of resource definitions (name, type, source URL) plus the pipeline that processed them (step order + which plugins, cross-referenced by name and repo link). See Sharing & Importing Bundles for the full flow.

What posting actually stores

Both listing types store metadata and links only — never executable code, and (for bundles) never the raw processed artifact content. This is a deliberate scope decision:

• Letting strangers submit code that other people's infrastructure automatically executes is a supply-chain/RCE risk, so a plugin listing is a pointer to a repo you still clone, review, and deploy yourself.
• A bundle is a pointer to original sources (URLs) plus a pipeline definition — importing it re-fetches those sources and reprocesses them through the importer's own pipeline. Nothing about the exporter's actual Summary/Vector/analysis output is ever transmitted.

Accounts

Posting either kind of listing requires a free account with a verified email address (browsing does not). See User Accounts for registration, email verification, password reset, and GitHub sign-in.

Using it

Visit the standalone site directly (http://localhost:5273), or use the panels in the main Web UI: Plugins → Browse Community, and Resources → Share as Bundle / Import from Community. All of these call the registry service directly (not the Core Warehouse API) — see the Registry API reference.

Running your own registry instance

The bundled registry service in docker-compose.yml is a single-node instance meant for a local demo or a trusted internal deployment. If you want a genuinely public, internet-facing registry that multiple unrelated teams post to, you'll need to add before going live:

• Moderation — accounts and email verification exist, but there's no admin review queue, and only a listing's own owner can delete it (no moderator override).
• Real email delivery — without SMTP_HOST configured, verification/reset emails are written to registry/data/outbox/ instead of sent. Set SMTP_HOST/SMTP_PORT/SMTP_USER/SMTP_PASS/MAIL_FROM.
• A fixed JWT_SECRET — without one, a random secret is generated at every container boot, logging every session out on restart.
• Stronger abuse protection — there's a basic per-IP rate limit (20 submissions/hour, 20 auth attempts per 15 minutes) but a real public deployment should add CAPTCHA or similar.
• TLS + a real domain — deploy behind a reverse proxy with a certificate, then point every DataCore deployment's frontend at that shared URL instead of a co-located registry container.

None of this is implemented today — it's flagged here so it's an informed decision, not a surprise, if you plan to expose this beyond a trusted network.