The spec-first API gateway for platform teams
Your OpenAPI spec is your gateway configuration. Authentication, authorization, rate limits, validation, and transformations compile from the same file your API is documented in. No drift, no reconciliation work, no silent security gaps.
Two sources of truth, one problem
Most platform teams maintain an OpenAPI spec (what the API is supposed to do) and a gateway config (what the API actually does at the edge). The two drift apart the day they are both written, and stay drifted.
Every drift is either wasted time reconciling, a bug shipping to production, or a silent policy gap waiting to become a security incident. At a certain size, the reconciliation is the platform team's day job.
Barbacane has one source: the spec. Auth, rate limits, validation, transformations, and routing all compile from it. Drift is impossible because there is only one place to change anything.
One spec, one compile, zero drift
Three steps, fully reproducible, all in your version control.
Write your spec
OpenAPI or AsyncAPI, annotated with
x-barbacane-* extensions for auth, rate
limits, routing, and policy. One file per service.
Compile the artifact
barbacane compile validates, resolves
references, and packages your spec into one deployable binary. Invalid specs
never reach production.
Deploy and serve
Push the artifact to a data plane. Hot-reload, zero-downtime deploys, and drift detection. Data planes keep serving even if the control plane is offline.
Everything platform teams need
Compiled from the spec, enforced at the edge. No extra config files, no shadow policies.
Request validation
Automatic JSON Schema validation for bodies, parameters, and headers, with
full $ref resolution. Invalid requests
never reach your upstreams.
Authentication
Five built-in auth plugins: JWT, OIDC, OAuth2, API Key, Basic. Configured directly in your OpenAPI security schemes.
Authorization
Policy-driven access control with inline CEL expressions, Open Policy Agent integration, and consumer-based ACLs. Zero-trust at the gateway.
Rust performance
Sub-microsecond routing and validation. Built on Tokio and Hyper. Memory safety without a garbage collector.
Every plugin you need
Built-in WebAssembly plugins for auth, security, traffic control, transformations, and observability. Sandboxed execution means a faulty plugin cannot crash the gateway; write your own when the built-ins do not cover your case.
Observability
Prometheus metrics, OpenTelemetry traces, structured logging. Full visibility into every request with no extra instrumentation on your upstreams.
Control and data plane split
Autonomous data planes that keep serving traffic even if the control plane is offline. Push deployments, hot-reload, drift detection, provenance in every artifact.
Request transformation
Declarative transformations on headers, query params, paths, and JSON bodies before requests reach your upstreams. Variable interpolation with capture groups.
FIPS 140-3 ready
Built on rustls with AWS-LC, a NIST-certified FIPS 140-3 cryptographic module. Enable FIPS mode with a single feature flag. No OpenSSL dependency.
Built for these teams
Internal developer platforms
Product teams write OpenAPI specs. The platform does the rest: auth, rate limits, validation, observability. Self-service without the governance compromises.
- Spec-first publishing workflow
- Centralized policy, distributed ownership
- One audit trail across services
API governance at scale
Express and enforce consistent auth, rate limits, and security policies across hundreds of services. Changes ship by PR, not by ticket.
- Shift-left lint with vacuum rulesets
- Fail-closed defaults on misconfiguration
- Artifact provenance and drift detection
Legacy gateway modernization
Migrating from Kong, Apigee, or Tyk? The strangler fig pattern works naturally. Add Barbacane in front, migrate routes one by one, retire the legacy stack when you are ready.
- Incremental migration path
- No vendor lock-in, AGPLv3
- On-prem, cloud, edge, or air-gapped
Frequently asked
How is this different from Kong, Apigee, or Tyk?
Those gateways ship with their own config DSL. Your OpenAPI spec is a parallel document you have to keep in sync with the gateway. Barbacane inverts that: the spec is the config. There is no second source of truth to drift from.
Does it work with my existing OpenAPI specs?
Yes. Add x-barbacane-* extensions where you
need gateway behaviour. Existing fields (security schemes, parameters,
responses) are already interpreted. Specs stay portable to other tools.
Can I add custom logic?
Yes, via WebAssembly plugins. Barbacane ships a full suite of official plugins and lets you write your own in any WASM-compiling language. Plugins are sandboxed, so a faulty plugin cannot crash the gateway.
How does it deploy?
A compiled artifact is a single binary. Run it anywhere: Kubernetes, bare metal, on-prem VMs, edge locations, air-gapped environments. The control plane and data planes are independent, so data planes keep serving even if the control plane is offline.
AGPLv3. Can I use it commercially?
Yes. Small teams and non-profits get a free commercial license. Larger organisations can buy a paid commercial license. Either way, every feature is open source, no gated enterprise tier. See pricing for details.
Does it support event-driven systems?
Yes. Barbacane reads AsyncAPI specs and bridges HTTP to Kafka, NATS, or AWS Lambda. The same spec-first, compile-safe workflow applies.
Does this extend to AI traffic?
Yes. The same spec-first model covers outbound LLM routing (via the
ai-proxy dispatcher) and inbound MCP for
AI agents. Platform teams often use Barbacane for all three on the same
gateway. See the AI
gateway page for that side of the story.
Ready to cut your gateway drift to zero?
Read the docs, star the repo, or bring Barbacane into a platform pilot.