> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/nemo/relay/llms.txt.
> For full documentation content, see https://docs.nvidia.com/nemo/relay/llms-full.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/nemo/relay/_mcp/server.

# About

Use this section when you want to package reusable NeMo Relay behavior as a plugin that can be activated from configuration.

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.

## Start Here When

Use these signals to decide whether this documentation path matches your current task.

* Ship policy bundles across applications
* Install observability exporters consistently
* Package framework-agnostic request transforms
* Validate operator-supplied config before runtime behavior changes

If the behavior applies to only one request or tenant, consider scope-local middleware before turning it into a process-level plugin.

## Guides

Use these guide links to move from the overview into task-specific instructions.

* [Define a Plugin](/build-plugins/basic-guide) explains plugin kinds, shape, runtime ownership, and the activation lifecycle.
* [Validate Plugin Configuration](/build-plugins/validate-configuration) covers JSON-compatible config, validation rules, and structured diagnostics.
* [Plugin Configuration Files](/build-plugins/plugin-configuration-files) documents `plugins.toml` file discovery, precedence, merge behavior, and editor controls for the CLI gateway.
* [Register Plugin Behavior](/build-plugins/register-behavior) shows how to initialize config and install subscribers or middleware through `PluginContext`.
* [Design Plugin Configuration](/build-plugins/advanced-configuration) covers validation rules, advanced configuration patterns, rollout controls, and `PluginContext` usage.
* [NeMo Guardrails Plugin](/nemo-guardrails-plugin/about) documents the built-in first-party `nemo_guardrails` component.
* [NeMo Guardrails Example Plugin](/build-plugins/nemoguardrails) shows the older external Python example plugin that applies NeMo Guardrails checks around NeMo Relay LLM and tool calls.
* [Code Examples](/build-plugins/code-examples) provides patterns for dynamic header injection, subscriber-oriented export, multi-surface bundles, and framework-facing plugins.

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 it is cleaned up with the owning scope.