Architecture
The three hosted surfaces and one local runtime that make up Speko, and which one your traffic touches.
The pieces
| Component | Where it runs | What it does |
|---|---|---|
Speko Relay (relay.speko.dev) | Speko's regional fleet, fronted by AWS Global Accelerator | Hosted HTTP/WebSocket API for STT, TTS, and LLM requests. Terminates your request, picks a provider, proxies media, meters usage. |
Speko control plane (gateway.speko.dev) | Speko's cloud | Authenticates API keys, admits requests, signs short-lived execution plans, meters and settles billing. Publishes signing keys at /.well-known/jwks.json and /.well-known/relay-jwks.json. |
| Speko Gateway | Your container, next to your agent | Open-source sidecar exposing a local streaming API on a Unix socket. Dials providers directly. Optional: consults the control plane for routing and managed credentials. |
Dashboard (platform.speko.ai/gateway) | Speko's cloud | Key management, activity, usage, BYOK configuration, and the live model catalog. |
Two traffic paths
Relay path — media flows through Speko
Your app ──HTTPS/WSS──▶ relay.speko.dev (nearest region) ──▶ provider
│
└── admission, metering ──▶ gateway.speko.devYou call relay.speko.dev with a Speko API key. A regional edge admits the request through the control plane (credit, concurrency, route health), a per-provider connector opens the provider connection with Speko's own provider credentials, and the result streams back to you. Every response tells you which provider, model, and region served it.
Gateway path — media flows direct to the provider
Your agent ──unix socket──▶ speko-gateway (same container) ──▶ provider
│
└── (managed requests) signed plans ──▶ gateway.speko.devThe gateway serves its API only on a local Unix socket — it opens no TCP port. BYOK requests are planned locally and make no Speko planning call (apart from optional anonymous telemetry). Managed requests use a signed session plan from the control plane: the plan carries the route, a short-lived provider credential, and metering ceilings, signed with a key you can verify against the public JWKS. Both types can coexist in one process, and audio and text still travel directly between your process and the provider.
Trust boundaries
- The relay's edge processes hold no provider secrets. Only the per-provider connector processes hold provider keys, and they accept work only via cryptographically signed, single-use relay plans.
- The control plane is the single monetary authority: admission, budgets, and settlement live there.
- The gateway verifies every plan's signature, issuer, audience, expiry, and single-use token before attaching any credential or media.
- Signed session plans (gateway) and signed relay plans (relay fleet) use separate signing keys published at separate JWKS URLs, so neither artifact can ever authorize the other's consumer.
For what data crosses each boundary, see Trust and signing.