HTTP/1.1 and HTTP/2
Reverse proxying with connection pooling, configurable timeouts and WebSocket upgrades, plus gRPC and server-sent events.
A gateway in Rust that builds its own routing table. Services publish a FARP manifest carrying their OpenAPI, gRPC and GraphQL schemas; Octopus finds them over mDNS, Consul, Kubernetes or DNS and derives routes as instances appear and disappear. Static config works too, and the two modes run side by side.
An async core on Tokio and Hyper with a trie router, connection pooling and scripts that run in microseconds. The tail latency is the product.
Services publish OpenAPI, AsyncAPI, gRPC or GraphQL and the gateway turns them into routes as those services come and go.
The router is programmed from the Gateway API and Octopus CRDs, with probes, graceful drain, EndpointSlice discovery and cert-manager TLS.
The edge for services that describe themselves, holding no routing state of its own.
Reverse proxying with connection pooling, configurable timeouts and WebSocket upgrades, plus gRPC and server-sent events.
Wildcard path matching, method filtering, prefix rewriting and a per-route priority, resolved in the router instead of in a chain of guards.
FARP watches services and generates routes from what they publish, with backends for mDNS, Consul, DNS and Kubernetes EndpointSlices. A static file of upstreams and routes still works, and the two modes compose.
Round-robin and weighted balancing with active health checks and circuit breaking, so a failing upstream stops receiving traffic before a person notices.
JWT, OIDC, API key, forward-auth and mTLS, with role and scope authorisation or a Rhai or OPA policy, and TLS termination that hot-reloads certificates on the Kubernetes path.
An embedded scripting engine for the behaviour that is one gateway’s own, and octopus-plugin-api for the behaviour worth compiling in.
An operator programs the router from HTTPRoute, GRPCRoute and Octopus CRDs, with health probes, graceful drain and a Helm chart.
Prometheus metrics and structured logging with a built-in dashboard and REST API. Distributed tracing is planned and not yet here.
Watches FARP manifests as Kubernetes resources.
Routes derived from manifests, never from gateway-side config.
Rate limits, auth and transforms applied at the edge.
Per-route metrics and traces out of the box.
Octopus is an API gateway in Rust that can build its own routing table. Most gateways expect every route declared by hand, in a repository owned by a different team than the service it points at. Services that speak FARP publish their own schemas across OpenAPI, AsyncAPI, gRPC and GraphQL, and Octopus turns those into routes as instances come and go.
It also runs purely statically from a config file, and the two modes work together: static routes for the things that will never be discoverable, derived routes for everything else.
A gateway is a single well-defined program with a hot path, no user-authored handlers in its type signatures, and a need for predictable memory use under load. That is the shape of problem Rust is best at, and it avoids the thing that killed my two Rust frameworks, since nobody has to read a generic signature to use it.
Octopus when the gateway is genuinely a separate network element with its own scaling and blast radius, which usually means cluster ingress. Bastion when the gateway is a logical concern inside a Go process, such as an aggregation layer, a backend for frontend, or a service fronting three others. Same protocol, same derived routes.
Shipping something on Octopus? Nobody is listed here yet. Tell me what you built and you will be the first.
Get listed →