Plugin Development

Recommended path: the Plugin Author SDK

If you are building a new plugin from scratch, start with the Plugin Author SDK. It ships:

• Type-safe Protocols for every extension point (Plugin, Agent, Tool, Route, Config, plus KV, Leash, Auth, DB, Channels, Hooks, Logging)
• A scaffolding CLI (dryade plugin new) that produces a valid v2 manifest, Hatchling build config, and meaningful tests in one command
• A testing/ subpackage (FakeHost, MockKV, MockConfig, MockLLM) so your plugin’s pytest runs without installing Dryade core
• Author-side signing (dryade plugin keygen, dryade plugin package) producing signed .dryadepkg artifacts the marketplace can accept

uv tool install "dryade-plugins-sdk[cli]"
dryade plugin new my-plugin --tier starter
cd my-plugin && pytest

Full reference: SDK docs at /docs/sdk/. Source: github.com/DryadeAI/dryade-plugins-sdk.

Building Plugins

Dryade plugins are Python packages that extend the platform with domain-specific AI workflows, tools, and agent configurations.

Plugin Structure

my-plugin/
├── dryade.json          # Plugin manifest
├── __init__.py          # Plugin entry point
├── routes.py            # FastAPI route definitions
├── agents/              # Agent configurations
│   └── my_agent.py
├── tools/               # Custom MCP tools
│   └── my_tool.py
└── ui/                  # Optional frontend bundle
    ├── src/
    └── dist/

Manifest Schema (dryade.json)

The current contract is manifest v2. The CLI generates a valid v2 manifest for you; reference for what each field means below.

{
  "manifest_version": "2.0",
  "name": "my-plugin",
  "version": "0.1.0",
  "description": "What this plugin does, in one sentence.",
  "required_tier": "starter",
  "author": "Your Name",
  "core_version_constraint": ">=1.0.0,<2.0.0",
  "category": "general",
  "agents": [{ "name": "my_agent", "framework": "custom" }],
  "tools": [{ "name": "my_tool" }],
  "routes": [{ "path": "/api/my-plugin/hello", "method": "GET" }],
  "permissions": ["network"],
  "tags": ["example"],
  "has_ui": false
}

Full field reference: SDK API Reference → ManifestV2. Don’t hand-author the manifest — dryade plugin new writes it for you, dryade plugin validate checks it.

Plugin Tiers

Pick a tier when scaffolding (dryade plugin new my-plugin --tier <tier>). Your tier choice is about which end-user license your plugin requires to install, not about slot counts on your side.

required_tier	Installable by end users with…	Reach
starter	Starter / Team / Enterprise licenses	Broadest
team	Team / Enterprise licenses	Medium
enterprise	Enterprise licenses only	Narrow (highest ACV)

End-user plugin slot ceilings (how many plugins a customer can install) are part of the customer’s license tier — not the author’s concern. The current numbers are published on the pricing page and stay between Dryade and the end customer; design your plugin for high per-slot value regardless of which tier of customer installs it.

Valid required_tier values: starter, team, enterprise. The schema rejects anything else — the CLI exits with BadParameter on --tier community/dev/sovereign.

Signing and Publishing

The SDK CLI handles the full chain:

dryade plugin keygen           # one-time: generates an Ed25519 author keypair at ~/.dryade-author/
dryade plugin package ./my-plugin   # builds + signs a .dryadepkg

Then submit the .dryadepkg to the marketplace via the Authors dashboard. The marketplace runs a review (validates manifest, smoke-tests the plugin, scans for leaks), counter-signs approved plugins into the platform allowlist, and lists them in the catalog. See the Publishing & marketplace payback section in the SDK README for revenue split, payout cadence, and review SLA.

Plugin Security

• All plugin code runs in a sandboxed environment
• Plugins cannot access other plugins’ data
• Route mounting is controlled by the signed marketplace allowlist
• UI bundles run in sandboxed iframes with signature verification
• Author signing keys + marketplace allowlist signing are described in Author security disclosure