Skip to main content
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

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

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.
Last modified on May 31, 2026