Plugin Store
Everything you can plug into Busbar.
Busbar ships small and complete: a memory store, token auth, and env/file secrets in the box. Everything heavier is a plugin you add without recompiling the core: where state lives (stores), how requests are trusted (auth), where a config secret value resolves from (secrets), and your own code on the request path (hooks). As of busbar 1.5.0 that is a working system, not a roadmap: a plugin is one signed archive you download, drop in a directory, and the binary you already run verifies and loads it. How it works is below the grid. Browse the plugins, and vote for what you want built next.
Memory
RAM store, zero setup, ephemeral.
The default. Virtual keys, budgets, rate limits, and usage all live in memory, nothing to install, nothing to provision. Ideal for a single node, a dev box, or a stateless tier where durability lives elsewhere. A restart clears it; that’s the trade for zero moving parts.
Built into the core: the default when no store is configured.
SQLite
Durable local persistence, one file.
Keys, budgets, and usage survive restarts in a single SQLite file, no external service to run. Write-behind by design: enforcement stays in memory on the hot path, and SQLite is the durable mirror flushed behind it. The single-node durability answer.
A signed, drop-in store plugin as of busbar 1.5.0; the default binary stays lean without it.
Postgres 
Shared, durable, multi-node.
One Postgres behind a cluster of Busbar nodes: virtual keys, usage, and audit shared across the fleet. Every node enforces from memory on the hot path and reconciles its spend into the shared record behind it. A signed, drop-in store plugin as of busbar 1.5.0.
A signed, drop-in store plugin as of busbar 1.5.0; the default binary stays lean without it.
Valkey 
Shared state on the Valkey (Redis-protocol compatible) you already run.
Point Busbar’s governance at the Valkey (Redis-protocol compatible) you already operate: virtual keys, usage, and audit shared across nodes without standing up a database. Same discipline as the other stores: enforcement stays in memory on the hot path, Valkey is the shared record behind it. A signed, drop-in store plugin as of busbar 1.5.0.
A signed, drop-in store plugin as of busbar 1.5.0; the default binary stays lean without it. Formerly published as store-redis — same plugin, renamed to follow the project upstream.
MySQL
Shared state on the MySQL/MariaDB you already run.
A durable, cluster-shared store for the MySQL, MariaDB, or Aurora MySQL you already operate — the same shared-state story as Postgres and Valkey, on the MySQL-protocol database many fleets already run. A signed, drop-in store plugin as of busbar 1.5.0.
A signed, drop-in store plugin as of busbar 1.5.0; the default binary stays lean without it.
Your store
Have a backend Busbar should speak?
The store is a small, sync contract: keys, budgets, usage, metering. If you want Busbar’s state in DynamoDB, Mongo, or your own service, the contract is the whole job. Tell us what you need and we’ll help you build it.
Contact us, or open a PR against the repo.
Tokens
Static bearer tokens, constant-time.
The default client auth: a constant-time allowlist of bearer tokens, checked on every request across both header and bearer carriers. Zero dependencies, in the core. Pair it with the admin token that guards the management API.
Built into the core: the default request auth.
OIDC
Log in with your IdP.
Validate incoming requests against an OIDC provider (Okta, Auth0, Entra ID, Keycloak, or any standards-compliant issuer) so gateway access follows your existing identity instead of a static token list. A signed, drop-in auth plugin as of busbar 1.5.0.
A signed, drop-in auth plugin as of busbar 1.5.0; the default binary stays lean without it.
Your auth
Trust requests your own way?
HMAC-signed requests, a bespoke token service, a SASO scheme of your own: the auth contract is small and stackable. Tell us how you need requests trusted and we’ll help you wire it in.
Contact us, or open a PR against the repo.
Env / File
The zero-setup default.
The default secret resolution: read a value from an environment variable or a file on disk. Zero dependencies, in the core. Point any config field at { env: VAR_NAME } or { file: /path }.
Built into the core: the default secret resolution.
HashiCorp Vault
Resolve secrets from Vault KV v2.
Read config secret values (provider API keys, database passwords) straight out of a HashiCorp Vault KV v2 mount instead of environment variables or files on disk. A signed, drop-in secret plugin as of busbar 1.5.0.
A signed, drop-in secret plugin as of busbar 1.5.0; the default binary stays lean without it.
Your secret backend
Have a secrets manager Busbar should speak?
AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, 1Password: the secret contract is one method, resolve a reference to bytes. Tell us what you need and we’ll help you build it.
Contact us, or open a PR against the repo.
Headroom
Context compression, on the path.
A rewrite gate that trims and compacts a request’s context before it ships, so a long conversation stays under the window without your app rebuilding the prompt. Written once, it works against every protocol and provider Busbar speaks. Measured: about 50% fewer input tokens on noisy histories for sub-millisecond overhead; short chats pass through untouched.
Powered by the open-source Headroom project.
Webrequest
Run your hook logic out-of-process.
A transparent forwarder that POSTs each hook op envelope to an operator-configured HTTPS URL and returns the reply verbatim — a signed, trusted relay to your own out-of-process gate logic. SSRF-guarded, redirects disabled, tight timeouts.
A signed, drop-in hook plugin as of busbar 1.5.0; the default binary stays lean without it.
Smart Router
Route by cost, latency, and live load.
A worked example, not a finished product: a routing gate that picks the backend per request from real signals: each member’s cost, latency, live concurrency, and rate headroom. It’s a template to read, fork, and shape into the router you actually want.
Read the write-up: the smart router you want is a hook.
Your hook
Built something worth sharing?
A guardrail, a router, a cost meter, an audit sink: anything that runs on the path. Tell us what it does and where it lives, and we’ll list it here and link straight to your repo.
Contact us, or open a PR against the repo.
How a plugin loads
A plugin is a plugin. Stores, auth modules, and hooks share one format, one loader, and one
trust model; the kind field in the manifest is the only thing that tells them
apart. Distribution is one signed .tar.gz per plugin and architecture: download it,
drop it in plugins/, done. Busbar unpacks and verifies the archive entirely in
memory (on Linux the library loads from an anonymous memfd, so nothing ever touches disk), and
the bytes that were verified are exactly the bytes that load.
It is safe by default. The loader is off until you set plugins.enabled: true, so a
tarball dropped next to a gateway that hasn't opted in is inert. Busbar's own plugins verify
against a release key embedded in the binary: trusted with zero configuration. Unsigned or
third-party plugins are logged and skipped unless you explicitly allow them
(allow_unsigned, allow_third_party, and a per-publisher key
allowlist), and version floors stop an old plugin from being loaded beside a newer binary.
And it is inspectable before it carries traffic. busbar --list-plugins prints every
plugin in the directory with its signature state and exactly why it will or won't load, without
executing any of them. busbar --validate checks the config and every plugin
manifest through the same path a real boot uses: if it passes, boot succeeds; if anything is
wrong (a bad config, a malformed manifest, two plugins claiming one name), Busbar names it and
refuses to start rather than booting degraded.
The point of the whole design: the default binary stays lean (~11 MB, with the memory store and token auth built in), and durable governance (SQLite, Postgres, Valkey, and MySQL) is a download you drop in, not a recompile.
New to the request path? Start with the hooks docs for the config shape, the tap/gate lifecycle, and how a hook falls back safely without ever blocking a request. Stores and auth are set in configuration.