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.