Service Discovery & FARP
Most gateways expect you to declare every route by hand. FARP — the Forge API Gateway
Registration Protocol — flips that around: services publish their own schemas, and Octopus turns
those schemas into routes as services come and go. In the live discovery path, services publish an
OpenAPI document; the federated API surface additionally merges AsyncAPI and GraphQL schemas
(see Schema federation). Static upstreams/routes and FARP-driven
discovery work together — you can use either or both.
How it works01
Discover — a discovery backend reports the set of live service instances and their addresses.
Fetch schemas — Octopus retrieves each service's published schema (its FARP manifest).
Generate routes — paths and methods from the schema become gateway routes pointing at the discovered upstream.
Watch & reconcile — Octopus watches for changes and updates routes when services scale, appear, or disappear.
Discovery backends02
FARP can source instances from several backends, each configured under farp.discovery.backends:
mDNS / Bonjour — zero-config discovery for local development.
Consul — service catalog with health filtering.
DNS — resolve instances from SRV/A records.
Kubernetes — discover Pod endpoints via the
discovery.k8s.io/v1EndpointSlice API.
An etcd discovery backend exists in the source tree but is not wired into the gateway's discovery configuration — only the four backends above can be selected. See Discovery backends for the honest breakdown.
Kubernetes discovery uses EndpointSlice, which reflects Pod scale up/down that the legacy Endpoints watch can miss. See the Kubernetes section for cluster setup.