Build Plugins

View as Markdown

Use this section when you want to create and package reusable NeMo Relay behavior as a plugin.

Plugins are the configuration-driven packaging layer for shared runtime behavior. A plugin can validate component-local config, register middleware and subscribers through a component-scoped context, and rely on the plugin system to report diagnostics and roll back partial setup when activation fails.

Plugins prevent repeated registration code for policies, request transforms, exporters, and related runtime components. They give shared behavior a stable kind name, a structured config document, and a clear activation lifecycle.

When to Use This Guide

Use this guide when you need to package reusable NeMo Relay behavior.

  • Ship policy bundles across applications
  • Package framework-agnostic request transforms
  • Validate operator-supplied config before runtime behavior changes
  • Package a manifest-backed native library or worker for discovery by the CLI

Keep behavior scope-local when it applies to only one request or tenant. Use a process-level plugin only for reusable behavior.

Plugin Types

Choose the group that matches the process boundary and language of the plugin.

Language Binding Plugins (Rust, Python, Node.js)

Application code registers these in-process plugins directly. Start with Language Binding Plugins for the common contract and binding-specific registration examples.

Native Dynamic Plugins (Rust)

These plugins run in-process from a separately packaged Rust shared library. Start with Native Dynamic Plugins (Rust).

gRPC Worker Plugins (Rust)

These plugins run out of process as a Relay-managed Rust worker. Use gRPC Worker Plugins (Rust).

gRPC Worker Plugins (Python)

These plugins run out of process as a Relay-managed Python worker. Use gRPC Worker Plugins (Python).

Next Steps

Start by deciding which runtime surfaces the plugin owns: middleware, subscribers, or a combination of related runtime behavior. Define the smallest JSON-compatible config that can drive that behavior, validate it before registration, and keep external objects or callables out of the config document.

Use plugins for reusable process-level behavior. Keep request-specific behavior scope-local so Relay removes it when the owning scope closes.