Skip to main content
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

Community Gateway

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.
The community Gateway is shared infrastructure with no SLA. It is rate-limited for sustained high-volume traffic. Do not ship user-facing production applications on the community Gateway. When to use: prototyping, integration testing, first inference call, tutorials.

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.
The request shape is identical to the community Gateway. Switching from community to managed requires changing the base URL and adding the 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.
Self-hosted Gateways require:
Self-hosted AI Gateways require Linux. Windows and macOS binaries for go-livepeer with AI support are not currently available.
When to use: your monthly API spend is material, you need to specify which Orchestrators handle your jobs, you need the inference path to stay within your own infrastructure, or you need a custom auth/billing model.

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. There is no hard threshold at which you must switch. The signals are cost, control, and data residency.

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.
Last modified on May 31, 2026