Skip to main contentPlugins dequeue committed events, transform the payload slices they care about, and push them to external systems. Definitions are stored at the system data root (for example ~/.eventdbx/plugins.json); configure with dbx plugin config <type> instead of editing TOML. Start here to pick a transport, then follow the linked sections for configuration and operational details.
Overview
- Learn how payload modes and the queue work together (
emit_events, retries, payload trimming).
- Decide whether to run lightweight emitters (TCP/HTTP/Log) or supervised binaries (process plugins).
- Track plugin logs/queue state so you can remediate failures quickly (
dbx queue, dbx plugin test).
Deep dive → Plugin overview
HTTP
- POST plugin envelopes to HTTP(S) endpoints with configurable headers.
- Pair with payload modes (
event-only, state-only, etc.) to avoid over-sharing data.
- Retries are handled by the EventDBX plugin queue (
plugin_max_attempts).
Deep dive → HTTP plugin
TCP
- Write JSON envelopes over TCP (one connection per delivery) for simple, low-latency consumers.
- Keep consumers fast; the plugin queue retries on failure.
Deep dive → TCP plugin
Process
- Run supervised binaries; EventDBX installs, starts/stops, and retries when they fail.
- Choose minimal payload modes to reduce queue pressure; use
dbx plugin start|stop|status.
Deep dive → Process plugin
Log
- Emit envelopes to the EventDBX log target for quick debugging or lightweight audit trails.
- Forward logs with your existing log pipeline (Splunk, Datadog, etc.).
Deep dive → Log plugin 
