> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livepeer.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Gateway Business Case

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

export const CustomDivider = ({color = "var(--lp-color-border-default)", middleText = "", spacing = "default", style = {}, className = "", ...rest}) => {
  const spacingPresets = {
    default: {
      margin: "24px 0"
    },
    overlap: {
      margin: "-1rem 0 -1rem 0"
    },
    tight: {
      margin: "0 0 -1rem 0"
    },
    section: {
      margin: "0 0 -2rem 0"
    },
    sectionOverlap: {
      margin: "-1rem 0 -2rem 0"
    },
    deepOverlap: {
      margin: "-1rem 0 -1.5rem 0"
    }
  };
  const spacingStyle = spacingPresets[spacing] || spacingPresets.default;
  return <div role="separator" aria-orientation="horizontal" className={className} style={{
    display: "flex",
    alignItems: "center",
    ...spacingStyle,
    fontSize: style?.fontSize || "16px",
    height: "fit-content",
    ...style
  }} {...rest}>
      <span style={{
    marginRight: "var(--lp-spacing-px-8)",
    opacity: 0.2
  }}>
        <Icon icon="/snippets/assets/logos/Livepeer-Logo-Symbol-Theme.svg" />
      </span>
      <div style={{
    flex: 1,
    height: "1px",
    background: "var(--lp-color-border-default)",
    opacity: 0.4
  }}></div>
      {middleText && <>
          <Icon icon="circle" size={2} />
          <span style={{
    margin: "0 8px",
    fontWeight: "bold",
    color: color,
    opacity: 0.7
  }}>
            {middleText}
          </span>
          <Icon icon="circle" size={2} />
        </>}
      <div style={{
    flex: 1,
    height: "1px",
    background: "var(--lp-color-border-default)",
    opacity: 0.4
  }}></div>
      <span style={{
    marginLeft: "var(--lp-spacing-px-8)",
    opacity: 0.2
  }}>
        <span style={{
    display: "inline-block",
    transform: "scaleX(-1)"
  }}>
          <Icon icon="/snippets/assets/logos/Livepeer-Logo-Symbol-Theme.svg" />
        </span>
      </span>
    </div>;
};

export const CenteredContainer = ({children, maxWidth = "800px", padding = "0", preset = "default", width = "", minWidth = "", marginRight = "", marginBottom = "", textAlign = "", style = {}, className = "", ...rest}) => {
  const presets = {
    default: {},
    fitContent: {
      width: "fit-content",
      minWidth: "fit-content"
    },
    readable70: {
      width: "70%",
      minWidth: "fit-content"
    },
    readable80: {
      width: "80%",
      minWidth: "fit-content"
    },
    readable90: {
      width: "90%"
    },
    wide900: {
      maxWidth: "900px"
    }
  };
  const presetStyle = presets[preset] || presets.default;
  return <div className={className} style={{
    maxWidth: presetStyle.maxWidth || maxWidth,
    margin: "0 auto",
    padding: padding,
    ...presetStyle.width ? {
      width: presetStyle.width
    } : {},
    ...presetStyle.minWidth ? {
      minWidth: presetStyle.minWidth
    } : {},
    ...width ? {
      width
    } : {},
    ...minWidth ? {
      minWidth
    } : {},
    ...marginRight ? {
      marginRight
    } : {},
    ...marginBottom ? {
      marginBottom
    } : {},
    ...textAlign ? {
      textAlign
    } : {},
    ...style
  }} {...rest}>
      {children}
    </div>;
};

export const BorderedBox = ({children, variant = "default", padding = "var(--lp-spacing-4)", borderRadius = "var(--lp-spacing-px-8)", margin = "", accentBar = "", style = {}, className = "", ...rest}) => {
  const variants = {
    default: {
      border: "1px solid var(--lp-color-border-default)",
      backgroundColor: "var(--lp-color-bg-card)"
    },
    accent: {
      border: "1px solid var(--lp-color-accent)",
      backgroundColor: "var(--lp-color-bg-card)"
    },
    muted: {
      border: "1px solid var(--lp-color-border-default)",
      backgroundColor: "transparent"
    }
  };
  const accentBarColors = {
    accent: "var(--lp-color-accent)",
    positive: "var(--green-9)"
  };
  return <div data-docs-bordered-box="" data-accent-bar={accentBarColors[accentBar] ? "" : undefined} className={className} style={{
    ...variants[variant],
    padding: padding,
    borderRadius: borderRadius,
    ...margin ? {
      margin
    } : {},
    ...accentBarColors[accentBar] ? {
      position: "relative",
      '--accent-bar-color': accentBarColors[accentBar]
    } : {},
    ...style
  }} {...rest}>
      {children}
    </div>;
};

export const TableCell = ({children, align = "left", header = false, style = {}, className = "", ...rest}) => {
  const Component = header ? "th" : "td";
  return <Component className={className} style={{
    padding: "0.75rem 1rem",
    textAlign: align,
    border: header ? "none" : "1px solid var(--lp-color-border-default)",
    ...style
  }} {...rest}>
      {children}
    </Component>;
};

export const TableRow = ({children, header = false, hover = false, style = {}, className = "", ...rest}) => {
  const rowId = `table-row-${Math.random().toString(36).substr(2, 9)}`;
  return <>
      {hover && <style>{`
          #${rowId}:hover {
            background-color: var(--lp-color-bg-card);
          }
        `}</style>}
      <tr id={rowId} className={className} style={{
    ...header && ({
      backgroundColor: "var(--lp-color-accent-strong)",
      color: "var(--lp-color-on-accent)",
      fontWeight: "bold"
    }),
    ...style
  }} {...rest}>
        {children}
      </tr>
    </>;
};

export const StyledTable = ({children, variant = "default", style = {}, className = "", ...rest}) => {
  const wrapperVariants = {
    default: {
      border: "1px solid var(--lp-color-border-default)",
      backgroundColor: "var(--lp-color-bg-card)",
      overflow: "hidden"
    },
    bordered: {
      border: "2px solid var(--lp-color-accent)",
      backgroundColor: "var(--lp-color-bg-page)",
      overflow: "hidden"
    },
    minimal: {
      border: "none",
      backgroundColor: "transparent",
      overflow: "visible"
    }
  };
  return <div data-docs-styled-table-shell className={className} style={{
    width: "100%",
    padding: 0,
    margin: 0,
    ...wrapperVariants[variant],
    ...style
  }} {...rest}>
      <table data-docs-styled-table style={{
    width: "100%",
    borderCollapse: "collapse",
    borderSpacing: 0,
    margin: 0,
    backgroundColor: "transparent"
  }}>
        {children}
      </table>
    </div>;
};

<CenteredContainer preset="readable80">
  <Tip> Gateways are Application Layers built on the Livepeer Protocol. They provide access to services for downstream developers and users. </Tip>
</CenteredContainer>

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.

<CustomDivider spacing="overlap" />

## Hosted vs Self-Hosted

<BorderedBox>
  <Tabs>
    <Tab title="Use a hosted gateway" icon="clapperboard-play">
      <CenteredContainer preset="readable70">
        <Tip>
          **Best for**: developers looking to integrate services.

          <CenteredContainer preset="readable90" minWidth="fit-content" marginRight="2rem">
            <Card horizontal arrow title="Gateway Providers" icon="merge" href="/v2/gateways/guides/operator-considerations/production-gateways" />
          </CenteredContainer>
        </Tip>
      </CenteredContainer>

      A hosted Gateway like [Daydream API](/v2/solutions/Daydream/overview), [Livepeer Studio](/v2/solutions/livepeer-studio/overview), or [Livepeer Cloud](https://livepeer.cloud) handles all infrastructure for you and provides an application layer for service integrations.
      You send requests; they handle routing, payment, and uptime.

      **Best when:**

      * You are building and experimenting
      * Volume is low to moderate
      * You do not need custom Orchestrator routing or SLA policies
      * Crypto infrastructure is not something you want to manage

      **Limitations at scale:**

      * You pay a service margin on every request
      * You depend on the provider's uptime, pricing, and feature roadmap
      * You cannot customise routing, pricing caps, or access policies
      * You have no visibility into Orchestrator selection or failure patterns
    </Tab>

    <Tab title="Run your own gateway" icon="torii-gate">
      <CenteredContainer preset="readable70">
        <Tip>**Best for**: application developers or businesses providing their own services.</Tip>
      </CenteredContainer>

      Running your own Gateway gives you direct access to the Livepeer compute network. You set your own policies, connect directly to Orchestrators, and capture the margin between what you charge customers and what you pay for compute.

      **Best when:**

      * You are processing high volume and want to reduce per-request costs
      * You need custom routing, SLA policies, or geographic preferences
      * You want to build a product or service layer on top of Livepeer
      * You are embedding AI or video capabilities directly in your infrastructure

      **What it requires:**

      * A Linux server (for <Badge color="purple">AI</Badge> or <Badge color="green">Dual</Badge> node types; <Badge color="blue">Video</Badge> also supports Windows)
      * No ETH required in off-chain operational mode
      * On-chain operational mode requires an ETH deposit on Arbitrum
    </Tab>
  </Tabs>
</BorderedBox>

<CustomDivider spacing="tight" />

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

```mermaid theme={"theme":{"light":"github-light","dark":"dark-plus"}}
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#18794E', 'primaryTextColor': '#fff', 'primaryBorderColor': '#3CB540', 'lineColor': '#3CB540', 'mainBkg': '#18794E', 'nodeBorder': '#3CB540', 'clusterBkg': 'transparent', 'clusterBorder': '#3CB540', 'titleColor': '#3CB540', 'edgeLabelBackground': 'transparent', 'textColor': '#3CB540', 'nodeTextColor': '#fff'}}}%%
flowchart LR
    A["Your customers\nor your own app"] -->|"Pay your service rate\n(fiat, crypto, subscription)"| B["Your gateway"]
    B -->|"Pay network rate\n(ETH on Arbitrum)"| C["Livepeer network\n(orchestrators)"]
    B -->|"Keep margin"| D["Your revenue"]
```

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

<CustomDivider spacing="overlap" />

## Actor Earnings

<StyledTable variant="bordered">
  <thead>
    <TableRow header>
      <TableCell header>Role</TableCell>
      <TableCell header>Earns from</TableCell>
      <TableCell header>Currency</TableCell>
    </TableRow>
  </thead>

  <tbody>
    <TableRow>
      <TableCell>**Orchestrator**</TableCell>
      <TableCell>Receives payment from Gateways for routing and coordinating compute work</TableCell>
      <TableCell>ETH (Arbitrum)</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Transcoder / AI Worker**</TableCell>
      <TableCell>Receives payment from Orchestrators for performing actual work</TableCell>
      <TableCell>ETH (Arbitrum)</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Redeemer**</TableCell>
      <TableCell>Earns fees for redeeming winning payment tickets on-chain</TableCell>
      <TableCell>ETH (Arbitrum)</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Gateway**</TableCell>
      <TableCell>**Pays** for compute. Earns at the business layer from customers.</TableCell>
      <TableCell>Pays ETH out; charges customers in any currency</TableCell>
    </TableRow>
  </tbody>
</StyledTable>

<CustomDivider spacing="overlap" />

## Operator Models

<Tabs>
  <Tab title="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.
  </Tab>

  <Tab title="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).
  </Tab>

  <Tab title="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.
  </Tab>

  <Tab title="Build a gateway platform (NaaP)">
    <Warning> NaaP is in active design consideration and listed here as a possible future project only </Warning>
    You operate a Gateway platform that handles all crypto complexity on behalf of your users. Users sign up, receive API keys, and pay in fiat or standard crypto. Your platform converts that into ETH micropayments to Orchestrators.

    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.

    [//]: # "REVIEW: Confirm the NaaP dashboard URL and production timeline."
  </Tab>
</Tabs>

<CustomDivider spacing="overlap" />

## Mode Economics

The economic model differs between the two operational modes.

<StyledTable variant="bordered">
  <thead>
    <TableRow header>
      <TableCell header>Factor</TableCell>
      <TableCell header>Off-chain</TableCell>
      <TableCell header>On-chain</TableCell>
    </TableRow>
  </thead>

  <tbody>
    <TableRow>
      <TableCell>**Startup cost**</TableCell>
      <TableCell>Zero - community-hosted signer is free</TableCell>
      <TableCell>ETH deposit required (\~0.065 ETH + 0.03 reserve on Arbitrum)</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Ongoing ETH management**</TableCell>
      <TableCell>None - remote signer handles it</TableCell>
      <TableCell>Monitor deposit balance; top up as it depletes</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**ETH price exposure**</TableCell>
      <TableCell>None - abstracted by signer or clearinghouse</TableCell>
      <TableCell>Yes - volatile ETH price affects your effective compute cost</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Crypto knowledge required**</TableCell>
      <TableCell>No - none required at the Gateway layer</TableCell>
      <TableCell>Yes - wallet, keystore, Arbitrum RPC, bridging</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Time to first job**</TableCell>
      <TableCell>Minutes (Docker command, point at remote signer)</TableCell>
      <TableCell>Hours (wallet setup, bridging, funding deposit)</TableCell>
    </TableRow>
  </tbody>
</StyledTable>

[//]: # "REVIEW: Confirm the current ETH deposit and reserve amounts for on-chain Gateways."

<CustomDivider spacing="overlap" />

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

<StyledTable variant="bordered">
  <thead>
    <TableRow header>
      <TableCell header>Pricing model</TableCell>
      <TableCell header>Description</TableCell>
      <TableCell header>Used by</TableCell>
    </TableRow>
  </thead>

  <tbody>
    <TableRow>
      <TableCell>**Per-request**</TableCell>
      <TableCell>Charge per API call or per inference job</TableCell>
      <TableCell>API providers, Daydream</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Per-minute**</TableCell>
      <TableCell>Charge per minute of video transcoded or live AI processed</TableCell>
      <TableCell>Livepeer Studio</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Subscription**</TableCell>
      <TableCell>Monthly access fee regardless of usage</TableCell>
      <TableCell>SaaS Gateway products</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Usage-based**</TableCell>
      <TableCell>Charge per unit (per pixel, per generation, per token)</TableCell>
      <TableCell>Direct API products</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Free + SPE-funded**</TableCell>
      <TableCell>No charge to users; costs covered by treasury grant</TableCell>
      <TableCell>Livepeer Cloud SPE</TableCell>
    </TableRow>
  </tbody>
</StyledTable>

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](https://explorer.livepeer.org).

<CustomDivider spacing="overlap" />

## Core Reasons

### Cost and margin

<AccordionGroup>
  <Accordion title="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.

    [//]: # "REVIEW: Replace this cost comparison with a published benchmark or remove it."
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

### Control and reliability

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

### Product differentiation

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

<CustomDivider spacing="overlap" />

## Gateway Primitives

Beyond routing your own workloads, the go-livepeer Gateway is a platform primitive. It exposes everything needed to build:

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

<CustomDivider spacing="overlap" />

## Decision Tree

<StyledTable variant="bordered">
  <thead>
    <TableRow header>
      <TableCell header>Question</TableCell>
      <TableCell header>Lean towards self-hosting if...</TableCell>
    </TableRow>
  </thead>

  <tbody>
    <TableRow>
      <TableCell>How much volume are you processing?</TableCell>
      <TableCell>Monthly spend on hosted API exceeds the effort of setup</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>Do you need custom routing or SLA policies?</TableCell>
      <TableCell>Yes, especially regional preferences or quality thresholds</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>Are you building a product for other users?</TableCell>
      <TableCell>Yes - you need a service layer to charge customers</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>Do you have Linux server access?</TableCell>
      <TableCell>Yes (required for AI and dual node types)</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>Do you need AI inference specifically?</TableCell>
      <TableCell>Yes - off-chain operational mode makes this low-friction</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>Are you comfortable with Docker or Go binaries?</TableCell>
      <TableCell>Yes - installation is straightforward on Linux</TableCell>
    </TableRow>
  </tbody>
</StyledTable>

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

<CustomDivider spacing="overlap" />

## Related Pages

<CardGroup cols={3}>
  <Card title="Gateways in Practice" icon="building" href="/v2/gateways/guides/roadmap-and-funding/gateway-showcase">
    Production products and community projects built on Livepeer Gateways.
  </Card>

  <Card title="Requirements" icon="clipboard-check" href="/v2/gateways/guides/deployment-details/setup-requirements">
    Hardware, OS, network, and operational mode requirements.
  </Card>

  <Card title="Deployment Options" icon="arrow-right" href="/v2/gateways/guides/deployment-details/setup-options">
    Choose your setup type and node type.
  </Card>
</CardGroup>