Skip to content

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 live instance at community.datacore.wakewakanai.com, or use the panels in the main Web UI: PluginsBrowse Community, and ResourcesShare as Bundle / Import from Community. All of these call the registry service directly (not the Core Warehouse API) — see the Registry API reference.

To run it locally against your own DataCore checkout instead, registry + community-site live in a separate docker-compose.registry.yml (not this repo's main docker-compose.yml, and not started by docker compose up by default):

bash
docker compose -f docker-compose.registry.yml up -d --build

Running your own registry instance

A registry instance started this way 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 (the live community.datacore.wakewakanai.com instance already has all of these except moderation/CAPTCHA):

  • 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). Not yet added to any deployment.
  • 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, or point at a self-hosted relay with SPF/DKIM/DMARC configured for your sending domain (this is how the live instance sends mail).
  • 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. Not yet added to any deployment.
  • 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.

Moderation and CAPTCHA/stronger abuse protection aren't implemented anywhere yet — flagged here so it's an informed decision, not a surprise, if you plan to expose your own instance beyond a trusted network.