A Gateway is the node that routes your AI inference or video transcoding requests to Orchestrators on the Livepeer Network. Every request to the network goes through a Gateway. The question is whose Gateway you use.
Access levels
The community Gateway at dream-gateway.livepeer.cloud is operated by the Cloud SPE for development access. It accepts unauthenticated requests and routes to the active Orchestrator set.
curl -X POST https://dream-gateway.livepeer.cloud/text-to-image \
-H "Content-Type: application/json" \
-d '{"prompt": "a mountain at dawn", "model_id": "SG161222/RealVisXL_V4.0_Lightning"}'
Managed Gateway provider
A managed Gateway provider gives you an API key and a Gateway endpoint. Requests are authenticated, rate-limited per your tier, and the provider handles Orchestrator routing and payment settlement.
curl -X POST https://provider-gateway.example.com/text-to-image \
-H "Authorization: Bearer $LIVEPEER_API_KEY" \
-H "Content-Type: application/json" \
-d '{"prompt": "a mountain at dawn", "model_id": "SG161222/RealVisXL_V4.0_Lightning"}'
Authorization header.
When to use: production applications where you want no infrastructure overhead and accept the provider’s pricing and routing decisions.
Self-hosted Gateway
Running go-livepeer in broadcaster mode gives direct network access. You control which Orchestrators receive your jobs, what price you pay per unit, and how authentication works.
livepeer \
-broadcaster \
-network arbitrum-one-mainnet \
-ethUrl <ARBITRUM_RPC_URL> \
-ethKeystorePath ~/.lpData/arbitrum-one-mainnet/keystore \
-maxPricePerUnit 0 \
-rtmpAddr 127.0.0.1:1935 \
-httpAddr 127.0.0.1:8935
| Requirement | AI Gateway (off-chain) | Video Gateway (on-chain) |
|---|
| Operating system | Linux (or Docker) | Linux |
| ETH on Arbitrum One | Not required for off-chain mode | Required (TicketBroker deposit) |
| go-livepeer binary | Required | Required |
| Orchestrator list | At least one -orchAddr endpoint | Network discovery via on-chain registry |
| Open port | Port 8935 (default) | Port 8935 (default) |
| Time to first request | ~15 minutes with Docker | Longer (ETH account setup + deposit funding) |
Self-hosted AI Gateways require Linux. Windows and macOS binaries for go-livepeer with AI support are not currently available.
Self-hosting decision
The natural path for most developers: start with the community Gateway, build and validate your application, move to a managed provider for production, then self-host as usage grows and the cost or control trade-offs become worth the overhead.
| Signal | Action |
|---|
| First inference call, prototyping | Stay on community Gateway |
| Shipping to users, need reliability | Move to managed provider |
| Monthly spend is material | Evaluate self-hosting for direct settlement |
| Need custom Orchestrator routing | Self-host |
| Data must stay within your infrastructure | Self-host |
| Need custom auth or per-user billing | Self-host + pymthouse |
Orchestrator session lifecycle
When a Gateway receives a job, it selects an Orchestrator from its candidate list (explicit -orchAddr or network discovery), sends a GetOrchestratorInfo request, negotiates capabilities and pricing, and routes the job. For live AI (live-video-to-video), the session persists for the stream duration; the Gateway routes all frames to the same Orchestrator until the session ends or the Orchestrator fails.
For batch jobs, each request may go to a different Orchestrator. The Gateway applies stake-weighted selection with price filtering for each request independently.
Session management is automatic in go-livepeer. For custom Gateway implementations, the livepeer-python-gateway reference implementation exposes the session lifecycle through OrchestratorSession and SelectionCursor classes. See alt-Gateways for the Python Gateway architecture.
The local Gateway setup walks through running a self-hosted broadcaster node step by step. The production checklist covers what to verify before moving to real traffic. 
