Plugins 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 exampleDocumentation Index
Fetch the complete documentation index at: https://docs.eventdbx.com/llms.txt
Use this file to discover all available pages before exploring further.
~/.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).
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).
TCP
- Write JSON envelopes over TCP (one connection per delivery) for simple, low-latency consumers.
- Keep consumers fast; the plugin queue retries on failure.
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.
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.).