Applications on Livepeer

A decision guide for application developers choosing between hosted APIs, direct gateways, BYOC pipelines, and frontend SDKs.

Livepeer applications combine hosted access, direct Gateway access, BYOC pipelines, and frontend SDKs into one production path. This page gives application developers the decision frame for choosing the right access surface before committing to architecture. Use it to decide when a hosted API is enough, when a self-hosted Gateway is warranted, and which build page to open next.

Running Your Own Gateway

Need	Self-Hosted Gateway	Hosted API
Get Started Fast	No, setup adds overhead	Yes, API key and go
Cost Savings At Scale	Yes, direct Orchestrator settlement with no hosted-API markup	No, hosted provider margin sits on top of network price
Custom Orchestrator Selection	Yes, pass any -orchAddr list or custom discovery endpoint	No, provider controls routing
Data Stays Within Your Infrastructure	Yes, Gateway runs on your servers and requests stay in your stack	No, requests route through provider
Production Resilience And Redundancy	Yes, run multiple Gateways and control failover logic	Partial, provider SLAs set the ceiling
Custom Auth Or Billing Model	Yes, integrate your own user management, remote signer, or JWT layer	No, provider auth model only
Zero Infrastructure Overhead	No, you own the binary and the machine	Yes, nothing to run

The practical path is hosted access first, production validation second, and self-hosting once cost, routing, or data-control requirements justify owning the Gateway. The main signals are monthly API spend, required Orchestrator selection, and infrastructure-bound inference paths.

Self-Hosting Requirements

This checklist states the operational requirements before you commit to self-hosting. The setup workflow lives in the Gateways tab.

Windows and macOS binaries for the AI Gateway are not currently available. Running a self-hosted AI Gateway requires Linux or Docker.

Requirement	AI Gateway (Off-Chain)	Video Gateway (On-Chain)
Operating System	Linux or Docker on any host	Linux
ETH / On-Chain Account	Not required	Required: ETH account plus Arbitrum RPC URL
Staking / LPT	Not required	Not required for Gateway role
go-livepeer Binary	Required: Linux binary or livepeer/go-livepeer:master Docker image	Required: same binary
Orchestrator List	Required: at least one -orchAddr endpoint to route to	Required: network discovery via on-chain signalling
Open Port	Port 8937 (default) accessible from your app	Port 8937 (default)
Time To First Request	About 15 minutes with Docker; longer for binary and config	Longer: requires ETH account setup and on-chain registration

The AI Gateway path is designed for developers, not infrastructure operators. A single Docker command launches a functional Gateway. The on-chain video Gateway path is more involved and is primarily relevant to operators running the full Livepeer transcoding node.

The Two Gateway Types

Type	Use For	On-Chain	ETH Required	Entry Point
AI Gateway (Off-Chain)	AI inference: text-to-image, LLM, ComfyStream, BYOC	No	No	Set up an AI Gateway
Video Gateway (on-chain broadcaster)	Video transcoding, HLS delivery	Yes	Yes	Set up a Video Gateway

The public Gateway at dream-gateway.livepeer.cloud and the Livepeer Studio AI API are both off-chain AI Gateway implementations of the same go-livepeer binary. When you self-host, you run that same binary yourself.

If you are ready to self-host, start with the local Gateway setup. If you are not sure yet, the navigator helps you choose the right path for your use case.

Next steps

Set Up a Gateway

Full setup guide for self-hosted AI and video Gateways in the Gateways tab.

Back to the AI API

Not ready to self-host yet. Return to the hosted API quickstart.

What is a Gateway?

Understand how Gateways work before deciding whether to run one.