Skip to main content
A Livepeer gateway is the access point between your application and the Livepeer compute network. It receives jobs, selects an orchestrator (a GPU operator), handles payment, and returns results. The gateway holds no GPU - all compute happens on orchestrators. Running your own gateway is not a technical requirement for using Livepeer. You can point at a hosted gateway and start building in minutes. The question is whether the control, cost savings, and capabilities of owning that layer are worth it for your situation.

​
Hosted vs Self-Hosted

​
Business Model

Gateways are Product routers. They earn at the business layer, not at the protocol level. Orchestrators earn protocol fees. Gateways earn the margin between what they charge customers and what they pay for compute.
For AI gateways running in off-chain operational mode, your gateway node itself holds no ETH. A remote signer handles all on-chain payment operations. Your gateway operator costs are whatever you pay the signer - which can be zero if using a community-hosted signer.

​
Actor Earnings

​
Operator Models

You are building a product and currently using a hosted gateway such as Daydream, Livepeer Studio, or Livepeer Cloud. You pay their service rate on every request. Running your own gateway removes that cost entirely - you pay orchestrators directly at network rates.What you capture: The service margin you were previously paying to a third-party operator.What this requires:
  • A Linux server (for AI workloads; video also supports Windows)
  • No ETH for off-chain operational mode; ETH deposit for on-chain operational mode
  • The same application code - only the endpoint changes
Who is doing this: App developers who scaled past the point where hosted gateway costs exceeded the operational cost of self-hosting.

​
Mode Economics

The economic model differs between the two operational modes.

​
Profit Margins

Your pricing to customers is entirely at the application layer - the Livepeer protocol has no concept of “gateway fees”. You decide what to charge; the protocol only controls what you pay orchestrators. Your revenue is the difference between what customers pay you and what you pay orchestrators. Pricing discovery - understanding what orchestrators charge on the current network - is available through livepeer_cli and the Livepeer Explorer.

​
Core Reasons

​
Cost and margin

Hosted gateways charge a service margin on every request. As your volume grows, that margin compounds significantly. Running your own gateway eliminates that third-party cost - you pay orchestrators directly at network rates.For video transcoding, community estimates suggest Livepeer can be 10-50x cheaper than cloud providers like Mux or AWS MediaLive at comparable volumes. The exact saving depends on your transcoding profiles and orchestrator selection.
AI gateways in off-chain operational mode require no ETH deposit and no Arbitrum wallet. You point at a community-hosted remote signer (which handles the payment layer for you), connect to orchestrators, and start routing inference requests immediately with no upfront crypto cost.This is a clear contrast to on-chain operational mode, which requires bridging ETH to Arbitrum before you can process a single job.

​
Control and reliability

A hosted gateway selects orchestrators on your behalf, using its own policy. You have no visibility into that selection and no ability to change it.Running your own gateway means you control which orchestrators receive your jobs, at what price caps, with what retry behaviour, and with what failover logic. For production workloads where quality and latency matter, this control is material.
You can configure your gateway to prefer orchestrators in specific regions. This reduces latency for your users and can improve transcoding or inference quality by keeping traffic local.
If a hosted gateway goes down, changes pricing, or drops support for a capability you rely on, your production service goes with it. Your own gateway removes that dependency.

​
Product differentiation

The Livepeer protocol evolves. Orchestrators come and go. Flag names change (the gateway was previously called “the broadcaster”).Your gateway is the abstraction layer that shields your customers from all of that. You version your API independently, handle protocol changes internally, and expose a stable interface to your users.
The go-livepeer gateway binary does not include built-in auth, rate limiting, or billing. Running your own gateway means you can wrap it with middleware that handles API key management, per-user rate limits, cost allocation, and audit logging - standard requirements for any production service.The NaaP (Network as a Platform) project is developing a reference implementation for exactly this.
Some operators embed gateway logic directly in their application instead of running it as a separate service. This is the use case for the remote signer architecture: your application can route Livepeer jobs natively, delegating the payment complexity to a sidecar remote signer process.The Python gateway SDK (livepeer-python-gateway) is the primary reference for this pattern.

​
Gateway Primitives

Beyond routing your own workloads, the go-livepeer gateway is a platform primitive. It exposes everything needed to build:
Wrap the gateway HTTP interface with standard auth middleware. The gateway itself has no built-in auth - this is intentional; it lives in your application layer. The NaaP project provides a reference implementation using JWT tokens issued via SIWE (Sign-In with Ethereum), but any standard auth pattern works.
-orchAddr lets you specify exactly which orchestrators receive your jobs. Build orchestrator tiers, geographic routing, or capability-specific pools. -maxPricePerCapability accepts a JSON configuration with per-pipeline, per-model price caps - route different job types to different orchestrator tiers with different pricing policies.
The gateway exposes per-job result data. Build usage accounting outside the protocol and charge customers however your product requires - per generation, per minute of video, subscription, or credits.
The remote signer architecture means you are not required to use the Go binary. Python, browser, and mobile gateway clients are possible - the signer handles Ethereum complexity. The livepeer-python-gateway SDK (github.com/j0sh/livepeer-python-gateway) is the reference Python implementation.

​
Decision Tree

If most of your answers align with self-hosting, continue to requirements and setup.

Gateways in Practice

Production products and community projects built on Livepeer gateways.

Requirements

Hardware, OS, network, and operational mode requirements.

Deployment Options

Choose your setup type and node type.
Last modified on March 16, 2026