Plugins

Org-scoped catalog, uploads, system plugins, and settings schemas.

Intended audience: Stakeholders, Business analysts, Solution architects, Developers, Testers

Learning outcomes by role

Stakeholders

Differentiate catalog versus tenant-local plugins for procurement and trust.

Business analysts

Write stories for browsing, enabling, and versioning catalog entries.

Solution architects

Integrate object storage and CDN assumptions for catalog artifacts.

Developers

Use catalog APIs and caching semantics documented on this page.

Testers

Verify catalog sync, failures, and permission gates.

Plugins extend what orchestrators can do: a catalog lists system-wide and org-specific packages, and org admins can upload validated zip artifacts. Assert upload size limits and 403 on missing permissions. Plugin HTTP handlers use PluginStoreRepository (local paths and optional S3, wired during application lifespan).

Purpose

Discover system + org plugin metadata and versions.
Upload tenant plugin zips (validated size/type via read_validated_plugin_file).
Read per-tenant setting schemas for orchestrator wiring.

Access

roles_allowed(ORG_PLUGINS_READ) for list/get endpoints.
roles_allowed(ORG_PLUGINS_WRITE) for uploads and mutations.
org_context enforces org membership after permission checks.

Data flow

Catalog rows in PostgreSQL (SystemPluginRepository, OrganizationPluginRepository) point to artifacts in plugin store (local + optional S3).
Startup — ensure_all_catalog_plugins_local pulls missing artifacts so hot-tier orchestrators can load.

Limitations

Upload size — Capped (see MAX_PLUGIN_UPLOAD_BYTES in helpers); oversized returns 413.
S3 optional — If credentials missing, S3 is skipped and logs warn; catalog sync still works for local paths.

Orchestrator instances Load plugins onto instances and manage pool tiers.

Plugin system Upload-attach-load lifecycle for ZIP plugins.

Plugin SDK Authoring plugins with BasePlugin and tools.