Gateway Business Case

Should you run a Livepeer gateway? The use case fit, business model, operator revenue patterns, and economics by operational mode.

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

Route your own workloads

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.

Build an inference API

You operate a Gateway and offer AI inference access to other developers. They send API requests; you route them to Livepeer AI workers and return results. You charge per request, per generation, or via subscription. You pay Orchestrators and keep the margin.

What you capture: Service margin on every job routed through your Gateway. Your differentiation is reliability, model availability, pricing, and support.

What this requires:

• A production Linux server with stable uptime
• An auth layer (API keys, rate limiting) built on top of the go-livepeer Gateway
• Billing integration outside the Livepeer Protocol - the protocol only controls what you pay Orchestrators, not what you charge customers

Who is doing this: Livepeer Cloud SPE (free public inference Gateway), Daydream, LLM SPE (LLM inference routing).

Embed in your platform

Your Gateway is internal infrastructure - not exposed to users directly, but routing every AI or video request your platform makes. You charge customers for your product; the Gateway is the cost layer underneath.

What you capture: Your product margin. The Gateway keeps compute costs below what you would pay a hosted inference provider (Replicate, Fal, Mux, AWS) while giving you full routing control.

What this requires:

• For AI: off-chain operational mode, Linux, no ETH
• The same infrastructure as an inference API minus the external-facing billing layer

Who is doing this: Daydream (real-time AI video for creators), Embody Avatars, AI Video Startup Programme participants.

Build a gateway platform (NaaP)

This is the Network as a Platform (NaaP) pattern. The NaaP dashboard (github.com/livepeer/naap) is the reference implementation: JWT-based auth, Developer API Keys, and usage metering built on top of go-livepeer.

From the Discord discussion that defined this model:

“The user never interacts with Livepeer contracts. The signer uses incoming USDC revenue to keep its hot wallet funded for PM ticket generation. The two payment layers are fully independent.”

What you capture: Full product margin plus ownership of the user relationship. Crypto is completely invisible to your users.

Status: NaaP is in active development. The demo is operational; production API is not yet stable.

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

Avoid hosted gateway fees at scale

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.

Free to start with off-chain operational mode

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

Own your routing and SLA policy

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.

Geographic request steering

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.

No dependency on a third party

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

Stable API surface above the protocol

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.

Auth, billing, and enterprise controls

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.

Embed gateway functionality in your product

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:

API key management and auth

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.

Custom orchestrator routing

-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.

Billing and usage metering

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.

Alternative gateway implementations

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.

Related Pages

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.