gRPC Worker Plugin Concepts
Worker dynamic plugins run outside the Relay process and install subscribers,
guardrails, and intercepts through the stable grpc-v1 protocol. The host
starts the local worker, validates its component configuration, receives a
declarative registration plan, and installs proxy callbacks.
Choose a Worker Runtime
Choose the runtime that matches the artifact you distribute:
- Use
pythonfor amodule:functionentrypoint in a Relay-managed Python environment. Includesource.manifest_root, then runnemo-relay plugins addso Relay can create and retain the required environment. - Use
rustfor a manifest-relative or absolute Rust executable. - Use
commandfor another manifest-relative or absolute local executable that implementsgrpc-v1.
All worker runtimes receive the same local endpoint and activation credentials. The process boundary isolates crashes and dependencies, but it does not create a security sandbox.
Manifest
Use the following worker manifest:
Set compat.worker_protocol to grpc-v1 and include plugin_worker in the
capability list. Refer to Choose a Worker Runtime
for the runtime-specific load and source requirements.
The worker receives its activation ID, plugin ID, worker and host endpoints, and a local activation token through environment variables. Do not start the worker directly during normal operation. The host supplies these values.
Registration and Trust
Workers return declarative registrations. Relay owns registry mutation,
namespacing, rollback, and deregistration. Relay DTOs use JsonEnvelope
values, while protobuf handles control flow.
Run nemo-relay plugins add and nemo-relay plugins validate to evaluate the
configured host policy and artifact trust evidence. Refer to Configure
Discoverable Plugins for the
operator-side lifecycle and validation flow.
Next Steps
- Refer to gRPC Worker Plugins (Rust) or gRPC Worker Plugins (Python) for complete language-specific authoring workflows.
- Refer to gRPC Worker Protocol Overview
when you implement
grpc-v1without an SDK.