Gateway access for developers

Three ways to access the Livepeer network as a developer: the community gateway (free, no setup), a managed gateway provider (API key), and a self-hosted go-livepeer gateway (full control).

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.

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"}'

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.

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"}'

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.

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

Self-hosted Gateways require:

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.

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.

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

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.