---
title: "Bastion"
tagline: "Gateway extension"
language: "Go"
license: "Apache-2.0"
since: "2026"
canonical: "https://xraph.com/work/bastion"
---

# Bastion

The same idea as Octopus, but as a Forge extension for teams who want the gateway inside their own Go process. HTTP, WebSocket, SSE and gRPC proxying, per-target circuit breakers, traffic splitting for canary and shadow releases, and an admin dashboard written in ForgeUI.

## Install

```bash
go get github.com/xraph/bastion
```

## What it is

Bastion turns a Forge application into a full reverse proxy. It is the in-process counterpart to Octopus: same FARP-derived routing, no additional deployment.

## What it does

- Multi-protocol proxying across HTTP, WebSocket, SSE and gRPC, including streaming.
- Automatic route generation from FARP manifests, alongside static routes from config or the admin API.
- Load balancing: round-robin, weighted, random, least-connections, consistent hash.
- Per-target three-state circuit breakers, active HTTP probes and passive failure tracking.
- Token-bucket rate limiting, global or per-route or per-client, and retries with exponential, linear or fixed backoff plus a retry budget.
- Traffic splitting for canary, blue-green, A/B and shadow releases.
- Response caching with per-route policies that respect Cache-Control.
- Upstream TLS and mTLS with automatic certificate reload.
- OpenAPI aggregation across all upstream services, with Swagger UI and per-service specs.
- An admin dashboard built in ForgeUI, plus a full REST admin API and hot config reload.

## The aggregation trick

Because every service's spec already arrives in its FARP manifest, the unified OpenAPI document is a by-product rather than something anyone maintains. That single fact has removed more documentation drift than any process I have tried.

---

*Unpublished draft. Not peer reviewed and not submitted to a venue.*


## Anatomy

- **Edge**: In-process gateway for Forge applications.
- **Aggregation**: Composes several internal calls into one response.
- **Manifests**: Consumes the same FARP declarations as Octopus.

## Constraints and trade-offs

- (trade-off) In-process means no extra hop and no separate deployment — and no isolation from the app it fronts.
- (decision) Same protocol as Octopus, so moving from one to the other is a deployment change, not a rewrite.