// Managing Golem plugins — listing available plugins, installing and configuring plugins via golem.yaml or CLI, and understanding built-in plugins like the OTLP exporter.
Adding a new component or agent templates to an existing Golem application. Use when adding a second component, adding agent templates like human-in-the-loop or snapshotting to an existing component, or converting a single-component app to multi-component.
Defining environment variables for Golem agents in `golem.yaml` (`env`, `envDefaults`, `secretDefaults`) or via CLI. Use when adding, setting, or overriding env vars on a component, agent, template, preset, or environment, or when wiring template substitution and merge modes.
Adding initial files to Golem agent filesystems via the `files:` section in `golem.yaml`. Use when provisioning local or remote files into an agent's virtual filesystem, setting read-only / read-write permissions, or configuring file mounts at the component, agent, template, or preset level.
Building a Golem application. Use when asked to build a Golem project, compile components to WASM, or troubleshoot build errors.
Understanding Golem CLI profiles, application environments, and component presets. Use when configuring deployment targets, switching between local and cloud servers, managing CLI profiles, defining environment-specific presets, or understanding how environments, presets, and profiles interact.
Rolling back a Golem deployment to a previous revision or version. Use when reverting a deployment, restoring a prior environment state, or recovering from a bad deploy.
| name | golem-manage-plugins |
| description | Managing Golem plugins — listing available plugins, installing and configuring plugins via golem.yaml or CLI, and understanding built-in plugins like the OTLP exporter. |
Plugins extend component and agent behavior without modifying application code. Currently, the only plugin type is Oplog Processor — a WASM component that receives and processes the operation log entries produced by agents (e.g., exporting traces, logs, or metrics).
Golem ships with the following built-in plugins, automatically registered and available in every environment:
| Plugin Name | Type | Description |
|---|---|---|
golem-otlp-exporter | Oplog Processor | Exports agent telemetry (traces, logs, metrics) to any OTLP-compatible collector (Jaeger, Grafana, Datadog, etc.) |
| Parameter | Required | Description |
|---|---|---|
endpoint | Yes | OTLP collector endpoint URL (must start with http:// or https://) |
headers | No | Comma-separated key=value pairs sent as HTTP headers (e.g., x-api-key=secret,auth=token) |
signals | No | Comma-separated telemetry types to export: traces, logs, metrics. Default: traces |
service-name-mode | No | How to set the service.name attribute: agent-id (default) uses the worker ID, agent-type uses the component ID |
Add plugins to a component or agent in golem.yaml using the plugins field:
components:
my-app:service:
plugins:
- name: golem-otlp-exporter
version: "1.1.5"
parameters:
endpoint: "http://localhost:4318"
signals: "traces,logs,metrics"
agents:
MyAgent:
plugins:
- name: golem-otlp-exporter
version: "1.1.5"
parameters:
endpoint: "https://otel-collector.example.com:4318"
headers: "x-api-key=my-secret-key"
signals: "traces,logs"
service-name-mode: "agent-type"
| Field | Required | Description |
|---|---|---|
name | Yes | Plugin name (e.g., golem-otlp-exporter) |
version | Yes | Plugin version string |
account | No | Account that owns the plugin (omit for built-in plugins) |
parameters | No | Key-value map of plugin-specific configuration |
Plugin parameter values support Jinja-style template substitution using {{ VAR_NAME }}. At deploy time, these are resolved against the host machine's environment variables:
plugins:
- name: golem-otlp-exporter
version: "1.1.5"
parameters:
endpoint: "{{ OTLP_ENDPOINT }}"
headers: "x-api-key={{ OTLP_API_KEY }}"
If a referenced variable is missing, deployment fails with the list of unresolved variables. See the golem-add-env-vars skill for full details on the substitution syntax.
Plugins can be defined in componentTemplates and inherited via the cascade system:
componentTemplates:
observability:
plugins:
- name: golem-otlp-exporter
version: "1.1.5"
parameters:
endpoint: "http://localhost:4318"
signals: "traces,logs,metrics"
components:
my-app:service:
templates: [rust, observability]
When plugins are inherited from templates, the pluginsMergeMode field controls how they combine:
| Mode | Behavior |
|---|---|
append (default) | Add new plugins after inherited ones |
prepend | Add new plugins before inherited ones |
replace | Discard inherited plugins, use only the ones defined here |
components:
my-app:service:
templates: [observability]
pluginsMergeMode: replace
plugins: [] # Remove all inherited plugins
Use presets and environments to vary plugin parameters across deployment targets:
components:
my-app:service:
plugins:
- name: golem-otlp-exporter
version: "1.1.5"
parameters:
endpoint: "http://localhost:4318"
presets:
production:
pluginsMergeMode: replace
plugins:
- name: golem-otlp-exporter
version: "1.1.5"
parameters:
endpoint: "https://otel.prod.example.com:4318"
headers: "x-api-key={{ OTLP_API_KEY }}"
signals: "traces,logs,metrics"
environments:
local:
server: local
componentPresets: debug
production:
server: cloud
componentPresets: production
golem plugin list # List all registered plugins
golem component plugin install \
--component-name my-app:service \
--plugin-name golem-otlp-exporter \
--plugin-version "1.1.5" \
--priority 0 \
--param endpoint=http://localhost:4318 \
--param signals=traces,logs
golem component plugin get \
--component-name my-app:service
golem component plugin update \
--component-name my-app:service \
--plugin-to-update 0 \
--priority 1 \
--param endpoint=https://new-endpoint:4318
golem component plugin uninstall \
--component-name my-app:service \
--plugin-to-update 0
golem deploy. Configuration lives in version control.When using golem deploy, the manifest is the source of truth — any plugins defined in golem.yaml are reconciled with the deployed state.
When multiple plugins are installed, priority determines their execution order. Plugins with higher priority values are applied first. Priority is set explicitly via the CLI's --priority flag; in golem.yaml, the order in the plugins list determines priority (first entry = highest priority).
golem-otlp-exporter plugin and exporting telemetry from agents, load the language-specific skill: golem-enable-otlp-rust, golem-enable-otlp-ts, golem-enable-otlp-scala, or golem-enable-otlp-moonbit