Custom Extensions
Build, archive, and deliver custom vendor extensions using the Scrydon Extensions SDK
The Scrydon Extensions SDK lets you build custom vendor extensions as self-contained archives. Each archive is a .tar.gz archive containing compiled code and a manifest — deliver it through a extension source, install it from your org's extension catalog, and it becomes available in the workflow editor immediately.
No monorepo access or platform redeployment required. Install the SDK from NPM, write your extension in TypeScript, build, and publish it in an extension.
Where this lands in the product. Everything installed into an organization — vendor extensions, MCP servers, and the solution and content extensions that deliver them — is managed in one place: Settings → Platform → Extensions. An extension is the delivery format, shown there as provenance ("from Acme Field Ops v1.3.0"), not a separate destination.
You can ship a connector on its own, or ship it alongside domain content (an ontology, workflows, a process flow, notebooks) in the same extension — see Extensions & Authoring SDK. Both arrive as one extension.
How It Works
Every extension follows the same lifecycle:
Use the SDK's defineExtension(), defineToolkit(), defineTool(), and defineBlock() helpers to declare your extension in TypeScript. Zod schemas validate inputs and outputs at both build time and runtime.
Run sdk-authoring extension build to compile your TypeScript into a single ESM archive, extract a manifest with JSON Schema representations of your Zod schemas, and package everything into a .archive.tar.gz.
Publish the archive in an extension to a Git/OCI source, then register that source under Settings > Platform > Extensions > Sources and install it from Add extension. The platform validates the manifest, stores the artifact, and registers it in the catalog.
The platform selects an execution backend from the archive's verified provenance. Exact reviewed Scrydon tools may use the approved Worker Thread backend. Shipped non-Scrydon and organization-installed tools run as a hash-pinned, single-use vendor_archive workload in a qualified Kata microVM. The trusted broker keeps reusable credentials outside vendor JavaScript and mediates outbound requests.
When an extension tool is added to a standard Agent, Scrydon checks the exact installed artifact, account binding, policy, DLP, and execution backend before the run is submitted. A tool that is not ready remains visible but disabled with remediation in the picker; a previously saved tool shows the same warning in the Agent block. Explicit selections are never silently omitted or converted into the built-in credential-free Search tool.
Architecture
┌─────────────────────────────────────────────────────────┐
│ Your Code (TypeScript) │
│ │
│ defineExtension({ auth, provides: { toolkits: [ │
│ defineToolkit({ block, tools: [ │
│ defineTool({ input, output, execute }) │
│ ]}) │
│ ]}}) │
└─────────────────┬───────────────────────────────────────┘
│ sdk-authoring extension build
▼
┌─────────────────────────────────────────────────────────┐
│ Archive (.tar.gz) │
│ ├── manifest.json (metadata, JSON Schemas, UI def) │
│ ├── dist/index.js (compiled ESM, all deps inlined) │
│ └── assets/ (icons, optional) │
└─────────────────┬───────────────────────────────────────┘
│ Deliver via an extension source (Git/OCI)
▼
┌─────────────────────────────────────────────────────────┐
│ Platform Runtime │
│ │
│ Manifest Catalog ── metadata (what blocks/tools exist) │
│ ActorBackend ─────── canonical security-floor selector │
│ Runtime Plane ────── one vendor microVM per invocation │
│ Egress Broker ────── auth, policy, DLP, and audit │
└─────────────────────────────────────────────────────────┘Key Concepts
| Concept | Purpose |
|---|---|
| Vendor | Top-level container — metadata, auth config, and one or more products |
| Product | A grouping unit that gets enabled/disabled per organization |
| Tool | Runtime logic — Zod-validated input/output with an execute() function |
| Block | Workflow editor UI — form fields (subBlocks), data flow (inputs/outputs) |
| Capability | Optional runtime interfaces — LLM, Embedding, STT, TTS, Image, Video, OCR, Moderation, Web Search, Webhooks, Discovery |
| Manifest | Auto-generated JSON metadata — the platform reads this without loading your code |
| Actor backend | Platform-selected execution backend. A manifest or organization may require stronger isolation, but cannot weaken the platform floor |
| Vendor microVM | Fresh OS-enforced boundary for non-Scrydon tool code, separate from any Agent microVM |
Security Model
Tool execution uses one governed path with a provenance-based security floor:
- No trust by name — only an exact, release-archived, reviewed Scrydon source may use the approved Worker Thread tool backend
- OS isolation for other tools — shipped non-Scrydon and organization-installed tool archives require the attested Runtime Plane
vendor_archivemicroVM backend - Source pinning — the active archive is revalidated against its verified SHA-256 identity before execution
- Credential confinement — vendor code sees invocation-scoped placeholders; the trusted egress broker materializes reusable credentials only into the actual allowed request
- Non-bypassable egress and DLP — direct sockets are blocked at the VM network boundary, while DNS, redirects, private ranges, destination policy, outbound DLP, and audit are enforced on emitted requests
- Fail closed — missing KVM capacity, image pinning, qualification evidence, DLP/audit readiness, or one-use grant storage makes the tool unavailable; there is no Worker Thread fallback
- Manifest validation — Zod schema validation at install time rejects malformed archives
Realtime and model capabilities use their own purpose-specific capability backend. Their behavior must not be used as evidence that a tool ran in a vendor microVM.
Getting Started
Build your first extension in 5 minutes with the hello-world example
SDK Reference
Complete API reference for defineExtension, defineTool, defineBlock, and more
Capabilities
Add selectable model/provider runtimes, webhooks, and discovery to your vendor
Delivering & Managing
Deliver archives via extension sources, and manage installed extensions