Extensibility and plugins

Dwara is extensible at four layers: plugin filters that intercept traffic at four defined phases (proxy-wasm modules and native Rust filters, dispatched by one chain), WASM route handlers that generate a response inside a module, extension traits that replace entire subsystems, and a verified plugin registry that supplies remote artifacts. A route can run a native filter and a proxy-wasm filter in sequence; both are plugin entries in the same list, referenced by name.

All four layers are live in every build — there are no cargo features to enable and no license involved. An Extism PDK runtime was previously scaffolded as a third plugin path but was removed before it was ever wired into the dispatch chain, config schema, or runtime — proxy-wasm and native filters are the supported plugin paths, and Extism may be re-introduced in a future milestone if there is demand.

In this section

• Use cases and recipes - seven complete recipes mapping real problems to the right surface, each with a runnable demo.
• Proxy-Wasm plugins - the proxy-wasm host: community Kong and Envoy filters run unmodified inside Dwara. Its group also carries the Plugin SDK building guide and the Hostcall API reference.
• Native plugin filters - a Rust filter trait compiled into the binary, running alongside proxy-wasm in the same dispatch chain. Its group also carries Building a native filter and the Native filter API.
• Nano-services (WASM handlers) - a route action that runs a WASM module to generate the response directly, no upstream needed. Its group also carries Building a nano-service and the Nano-service ABI.
• Plugin lifecycle - how plugins are loaded, configured, hot-swapped, and health-tracked across config generations.
• Plugin registry - load plugins from a remote registry with digest and signature verification, for fleet-consistent pinning.
• Plugin compatibility - the compatibility contract between gateway and plugin builds: ABI level, wasm targets, breaking-change policy.
• Plugin testing - unit, integration, and replay regression testing for plugins.
• Extension traits - the five swappable seams (RateLimiter, ConfigSource, CacheStore, AnalyticsSink, SecretSource) that let you replace entire subsystems with a custom or enterprise backend. Its group also carries Building an extension and the Extension trait API.

Related, outside this section: Filter-chain ordering documents the eight pipeline stages that the plugin phases hook around — the filter_chain config block validates a custom order but the dataplane runs the fixed order today.

Runnable demo

The demos/08-extensibility/ directory in the repository runs a live stack for the features in this section; its README covers prerequisites, test scripts, and teardown.

Where to go next

• Architecture: plugins and extensibility
  • where each extensibility seam sits in the architecture, and what is still scaffolded.
• Enterprise and fleet - the enterprise backends (Redis, Vault) are additional implementations of the same extension traits.