VantageEdge

Route, rate-limit and cache your APIs from one console.

VantageEdge sits in front of your services and sends each incoming path to the backend you chose. Along the way it checks auth, holds a rate limit, serves from cache when it can, and writes down what happened. You wire it from one console.

Sign in Read the docs
5 routes, 6 origins
Carrying a requestRoute on, idleRoute offA check: auth, rate limit or cache

Click a path on the left to send it a request. Click an origin on the right to take it down and watch its pool re-split. Send /api/search four times quickly to hit its rate limit, or untick the JWT box to see auth stop a request.

An example setup, simulated in your browser. Left: paths you expose. Right: the backends behind them. Hover a path to see its auth, rate limit and cache settings.

What one request goes through

The gateway runs these in order, each configured per route. The board above runs the same steps: a cache hit never reaches the origin, and an empty bucket stops a request at the limiter.

  1. 1IngressA request arrives on your subdomain.
  2. 2MatchThe path is matched against your routes, highest priority first.
  3. 3AuthOpen, JWT, API key, or both, chosen per route.
  4. 4ThrottleA token bucket decides whether it passes now or waits.
  5. 5CacheA prior response may answer it without touching an origin.
  6. 6ForwardOtherwise it goes to a healthy origin, weighted.
  7. 7LogStatus, latency, cache and limit outcome land in the request log.

What it does

Weighted origin pools
Many backends per route, each with a weight. A failed health check pulls an origin and traffic re-splits across the rest.
weight · health_check_path · interval · timeout · retries
Per-route rate limiting
A token bucket per route: sustained rate plus burst, counted per caller by default (API key or signed-in user, else client IP), so one noisy caller can’t spend everyone’s budget.
requests_per_second · burst · key strategy
Response cache
Cache a route and successful GETs are held in Redis for your TTL. The hit rate shows on the board.
cache_enabled · cache_ttl_seconds
Config that applies live
The console writes to the control plane; the gateway picks it up in seconds. No deploy, no restart.
control plane to gateway, in seconds
Request-log analytics
Every request is logged with status, latency, and cache or limit outcome. Traffic rolls it up: throughput, p95, status mix, busiest paths.
GET /api/v1/analytics?window=1h|24h|7d|30d
Auth without building it
Clerk JWT for people, scoped API keys for machines. Each route picks which it accepts.
public · jwt_required · apikey_required · both

Setting one up

  1. 1

    Add an origin

    Name it, give it a URL and a health check path. This is a backend you already run.

  2. 2

    Add a route

    A path pattern like /api/orders/*, the methods it covers, and the origin it points at.

  3. 3

    Set its policy

    Optionally: an auth mode, a rate limit, a cache TTL. Defaults are sane; change them inline later.

  4. 4

    Send traffic

    Point a hostname at your subdomain, or call the subdomain directly while you test.

  5. 5

    Watch the board

    The overview shows which routes reach which origins; Traffic shows throughput, errors, p95 and cache hit rate.

  6. 6

    Adjust live

    Change a weight, flip a route off, revoke a key. The gateway applies it without a restart.

The API

Everything the console does is a REST call under /api/v1. Auth is a verified Clerk JWT; the tenant is read from the token, never passed in. Machine callers use an API key in X-API-Key instead.

Full reference
GET /api/v1/tenants/meYour tenant
GET /api/v1/originsList origins
POST /api/v1/originsAdd an origin
GET /api/v1/routesList routes
POST /api/v1/routesAdd a route
GET /api/v1/routes/{id}/originsA route’s pool
GET /api/v1/api-keysList keys
POST /api/v1/api-keysGenerate a key
GET /api/v1/analyticsTraffic rollup

Good to know

Multi-tenant by design
Each account is its own tenant with its own subdomain, origins, routes and keys. Nothing is shared across tenants.
The stack
Go gateway and control plane, Postgres for config, Redis for the response cache and rate-limit buckets. The console is Next.js.
Open source
The gateway and control plane are on GitHub. Run the hosted version or your own.
Not there yet
No cache-entry browser, and analytics is polled rather than streamed. Both are on the list; neither blocks running real traffic.

Put something behind it.

Add one origin, add one route, and the first request shows up in Traffic.

Sign in