By the Cloud SPE Team — Livepeer.Cloud

Executive Summary

The Cloud SPE has completed delivery of the Network-as-a-Product (NaaP) MVP — SLA Metrics, Analytics, and Public Infrastructure project, funded by the Livepeer Treasury. This post provides a detailed accounting of what was proposed, what was built, how the architecture works, and what impact this has on the Livepeer network going forward.

Work began in November 2025 with the original proposal and discovery process. The revised pre-proposal was submitted in January 2026, passed the treasury vote, and execution proceeded through three milestones culminating in April 2026.

What Was Promised vs. What Was Delivered

Milestone 1 — Metrics Collection & Aggregation (February 2026) ✅

Promised:

• Define and implement the minimal metrics set
• Aggregate existing telemetry into a unified analytics layer
• A basic dashboard showing sample data flowing end to end

Delivered:

• A comprehensive metrics catalog covering network state, stream activity, performance, payments, reliability, and orchestrator leaderboard scoring
• A Kafka-to-ClickHouse ingest pipeline using ClickHouse's Kafka Engine tables for durable, exactly-once event consumption
• Materialized views routing incoming events into tables with validation rules
• Normalized tables capturing event-family facts and rollups
• A working Grafana dashboard demonstrating end-to-end data flow from Kafka through to visual output
• Documented bootstrap schema for reproducible fresh deployments

Milestone 2 — Test Signals & Derived Analytics (March 2026) ✅

Promised:

• Deploy reference load-test gateways
• Launch a public dashboard with core views
• APIs for ecosystem consumption

Delivered:

• Reference load-test gateway operational, generating consistent AI pipeline performance signals
• Four production Grafana dashboards:
  • System health overview
  • Real-time stream activity
  • Payments and revenue metrics
  • FPS, latency, WebRTC performance
• Additional supply inventory dashboard tracking GPU capacity across the network
• A REST API with endpoints covering many requirement specs:
  • Network state and orchestrator profiles
  • Stream activity and job performance
  • Payment and economics data
  • Reliability and SLA scoring
  • Orchestrator leaderboard with composite scoring
  • GPU supply inventory and capacity
• OpenAPI specification embedded in the API service with Swagger UI
• Prometheus metrics endpoint for operational monitoring of the API itself

Milestone 3 — Stabilization & Review (April 2026) ✅

Promised:

• Harden infrastructure for reliability and cost efficiency
• Document metrics, assumptions, and known gaps
• Review outcomes with the community to determine next steps

Delivered:

• Full production deployment across multiple infrastructure nodes with separated concerns:
  • Kafka broker, MirrorMaker2 for replicating events from Confluent Cloud, and a full ClickHouse + API + Grafana stack
• Traefik reverse proxy with automated TLS via Cloudflare
• Prometheus monitoring with 180-day retention policy
• Resolver service — a custom service that publishes corrected current and serving state into canonical stores
• dbt semantic layer publishing canonical and API views over normalized tables, with automated tests
• 31 data-quality validation tests in a scenario-based test harness
• Comprehensive documentation suite (see below)

Architecture Deep Dive

The NaaP Analytics platform follows a layered architecture designed for clarity, auditability, and extensibility:

Kafka Topics
    ↓
ClickHouse Kafka Engine Tables
    ↓
Ingest Materialized Views → accepted_raw_events / ignored_raw_events
    ↓
Normalized Tables (event-family facts + rollups)
    ↓
Resolver Service → canonical_*_store / api_*_store
    ↓
dbt Semantic Layer → canonical_* / api_* views
    ↓
Go REST API + Grafana Dashboards

Key Architectural Decisions

ClickHouse + Kafka Engine — We chose ClickHouse as the analytics store for its columnar storage efficiency and native Kafka engine support. This eliminates the need for a separate ETL service — ClickHouse consumes directly from Kafka topics, and materialized views handle routing and validation in a single step.

REST/JSON API Design — The API follows a straightforward REST design with no authentication required for public read endpoints. This maximizes accessibility for ecosystem teams while keeping the door open for org-scoped access in the future.

Tiered Serving Contract — Data flows through defined tiers: raw → normalized → canonical (resolver) → semantic (dbt) → API. Each tier has explicit contracts about freshness, correctness, and derivation rules. The resolver publishes "corrected" state — reconciling event ordering, handling late-arriving data, and producing a consistent current-state view.

The Resolver

The resolver deserves specific mention. It's a separate service that:

• Reads from normalized tables
• Computes corrected current state (handling out-of-order events, deduplication, state transitions)
• Publishes to canonical store tables
• Supports three run modes: bootstrap (full historical rebuild), tail (real-time processing), and auto (bootstrap then tail)
• Includes repair capabilities for specific time windows

This is the component that transforms raw event noise into trustworthy, queryable state. Without it, dashboards would show inconsistencies from event ordering, network partitions, or delayed telemetry.

Enrichment Layer

The API includes a polling worker that enriches raw orchestrator data with:

• ENS name resolution
• Staking information from the Livepeer protocol
• Gateway metadata
• GPU inventory details

This ensures the API and dashboards present human-readable, contextually rich data rather than raw addresses and IDs.

Documentation Delivered

One of the project goals was to leave the community with not just working software, but a documented system that others can operate, extend, and contribute to:

Every product spec is individually documented with requirement traceability.

Impact on the Livepeer Network

Immediate Impact

1. Visibility: For the first time, anyone can see how the Livepeer AI network is performing — not from marketing materials, but from live data sourced from real workloads and standardized test signals.

2. Comparability: Orchestrators can be compared on a level playing field — same metrics, same methodology, same data pipeline. The leaderboard scoring model uses composite metrics that reward both performance and reliability.

3. Ecosystem Integration: The public APIs and data model are designed for consumption. The NaaP platform itself (livepeer/naap) is an architecture where new views, tools, and integrations can be built independently by any team.

4. Operational Maturity: The Livepeer network now has documented SLA metrics, a metrics glossary, formulas for reliability and performance scoring, and a reference implementation of how to collect, validate, and serve this data. This is the kind of infrastructure that enterprise evaluators look for.

Foundation for Future Work

This project intentionally did not attempt to:

• Enforce SLAs or modify protocol incentives
• Introduce new routing logic
• Make protocol changes

These are all logical next steps, and they all depend on the measurement layer we've now established. Specifically, this enables:

• SLA-aware job routing — gateways can use performance data to route jobs to orchestrators that meet specific reliability or latency thresholds
• Network quality scores — aggregate metrics that can be published to the Livepeer Explorer or consumed by third-party evaluation tools
• Treasury accountability — future funded projects can point to observable metrics as evidence of impact
• GPU market intelligence — the supply inventory data provides a real-time view of network capacity, useful for both gateway operators planning workloads and orchestrators positioning their hardware

Lessons & Insights from the Build

Community Feedback Made This Better

The original pre-proposal (October 2025) was more ambitious — it included decentralized data transport via Streamr.Network, a larger budget, and broader scope. The community's feedback was pointed and constructive: too much scope, too much cost, unnecessary architectural risk. That feedback led to a complete reset. The revised proposal dropped Streamr, cut the budget, simplified the architecture, and focused on a thin but complete MVP. The result is better software shipped faster.

Existing Infrastructure Is an Asset

A key design principle was reusing existing Livepeer infrastructure wherever possible. Telemetry data from gateways and orchestrators already existed — it just wasn't aggregated or publicly accessible. By building on top of what was already there (gateway events, orchestrator telemetry, Kafka streams from Confluent Cloud), we avoided building a new event pipeline from scratch.

The Resolver Pattern Pays Off

Early in development, we faced the classic analytics challenge: raw events are noisy, out of order, and inconsistent. Rather than trying to fix this at the ingest layer (which would add latency and complexity), we built a separate resolver service that computes correct state from normalized events. This separation of concerns kept the ingest pipeline fast and simple while giving the API layer clean, trustworthy data. The resolver's repair mode — the ability to reprocess a specific time window — has already proven invaluable during development and will continue to be useful operationally.

Documentation Is a Deliverable

We treated documentation as a first-class deliverable, not an afterthought. Every architectural decision is recorded in an ADR. Every operational procedure has a runbook. Every validation rule has a behavioral contract. This matters because this is community infrastructure — it needs to be operable by people who didn't build it.

Right-Sizing Is an Art

The leaner budget forced discipline. We couldn't build everything, so we built the right things. The metrics catalog is minimal but sufficient. The API covers well-defined requirement specs. The dashboards address four key operational domains. Every component earned its place. This is a pattern we'd recommend to any SPE: start with the smallest thing that proves value, then let the data make the case for further investment.

Open Source

All code is available at github.com/Cloud-SPE/livepeer-naap-analytics under an open source license. The repository includes:

• Complete Go API source OpenAPI specs
• Resolver service source
• dbt warehouse models with tests
• ClickHouse schema and migrations
• Grafana dashboards (JSON)
• Prometheus configuration
• Docker Compose stacks for local development
• Production deployment configurations for Docker / Portainer
• Full documentation suite
• Data validation test harness

Acknowledgments

This project exists because of the Livepeer community. The feedback on the original pre-proposal — from DeFine, Karolak, vires-in-numeris, j0sh, Authority_Null, rickstaa, dob, and others — was direct, constructive, and ultimately made the project significantly better. Mehrdad from the Livepeer Foundation provided ongoing guidance and confirmed alignment with the network observability roadmap. Qiang Han from Livepeer Inc endorsed the proposal and committed to collaboration throughout execution. honestly_rich championed transparency and accountability throughout the process.

This is what community-driven governance looks like when it works.

The NaaP Analytics platform is live and open source. Review the code at github.com/Cloud-SPE/livepeer-naap-analytics, explore the proposal thread, and reach out in Livepeer Discord with questions or ideas for what to build next.

A guide for Livepeer Orchestrators ready to serve AI inference and unlock a new revenue stream.

If you're running a Livepeer orchestrator, you already have the infrastructure most AI companies would kill for: GPUs connected to a decentralized network, Docker expertise, and skin in the game. What if those same GPUs could serve LLM chat completions, text embeddings, and image generation — with demand already waiting?

That's exactly what BlueClaw Network plans to make possible.

What Is BlueClaw?

BlueClaw is an OpenAI-compatible AI inference gateway built on top of the Livepeer GPU network. It provides:

• Chat completions (/v1/chat/completions)
• Text embeddings (/v1/embeddings)
• Image generation (/v1/images/generations)

All accessible at https://openai.blueclaw.network/v1 — the same API shape developers already use with OpenAI, so any application using the OpenAI SDK can switch to BlueClaw by changing a single line: the base_url.

BlueClaw doesn't run its own GPUs. Your GPUs power it. The gateway discovers orchestrators through the on-chain AI Service Registry, routes inference requests to them, and your infrastructure does the work. You set your own pricing. You keep your earnings.

Why Should Orchestrators Care?

New Workloads, Same Hardware

If you're running RTX 3090s, 4090s, or better — you already meet the requirements. BlueClaw's BYOC (Bring Your Own Compute) framework lets you deploy lightweight runner containers alongside your existing orchestrator setup. No new hardware needed.

Real Demand from Day One

BlueClaw isn't speculative. It's designed for autonomous AI agent builders who need unlimited, always-on inference without rate limits or per-token billing. These workloads are persistent and growing — agents don't sleep, and they don't stop sending requests at 5 PM.

The AI Inference Market Is Massive

Video transcoding put Livepeer on the map. AI inference is where it scales. LLM inference, embeddings for RAG pipelines, image generation — these are the workloads every company on the planet is trying to provision right now. BlueClaw gives you a seat at that table, powered by infrastructure you already run.

Expanding Capabilities on the Horizon

Beyond the three core capabilities live today, Cloud SPE is actively building reranking (Cohere-compatible /v1/rerank) and video generation runners. Orchestrators who onboard now will be first in line when these capabilities go live on BlueClaw.

What You'll Need

Here's the honest picture of what's required:

GPU requirements by capability:

A 3090 operator can serve chat completions and embeddings on day one. Image generation requires a 4090 or better, on a dedicated GPU.

How It Works — The Architecture

The flow is clean and modular:

BlueClaw Gateway (discovers you on-chain)
        │
        ▼
  Your AI Orchestrator (go-livepeer)
        │
        ▼  (via Cloudflare Tunnel)
  BYOC Runners (chat / embeddings / image gen)
        │
        ▼
  Inference Backend (Ollama or vLLM)
        │
        ▼
     Your GPU

You deploy:

1. Your AI Orchestrator — the go-livepeer node you likely already run
2. A Cloudflare Tunnel — provides valid HTTPS without managing certificates
3. An inference backend — Ollama (simpler) or vLLM (higher throughput, larger models)
4. BYOC runner containers — lightweight proxies that register capabilities with your orchestrator and route requests to your backend

Each component is a Docker container. The runners are open source under Cloud-SPE on GitHub. If you want to build a custom runner for a new workload, the framework only requires an HTTP endpoint and a capability registration sidecar.

The Onboarding Guide

Cloud SPE has published a comprehensive BlueClaw GPU Provider Onboarding Guide (v1.3) that walks you through every step:

• Step 1: Create Docker networks and volumes
• Step 2: Deploy and configure your AI Orchestrator (including ticket redemption wallet setup and AI Service Registry registration)
• Step 3: Set up your Cloudflare Tunnel with published application routes for each capability
• Step 4: Deploy your inference backend — complete Docker Compose files for both Ollama and vLLM, with tested model configurations per GPU (3090, 4090, 5090)
• Step 5: Deploy BYOC runners for chat completions, text embeddings, and image generation — each with its own compose file and environment variable reference
• Step 6: Start everything in the correct order and verify runner registration
• Step 7: Verify end-to-end with BlueClaw's playground

The guide includes Docker Compose files you can use directly, tested vLLM configurations by GPU type, a full environment variable reference, troubleshooting for common issues (TLS errors, capability registration failures, VRAM management), and a quick-reference section for 3090 operators who want the shortest path to serving jobs.

Quick-Start: The 3090 Operator Path

If you have a 3090 and want the fastest route:

1. Run tztcloud/go-livepeer:latest registered on the AI Service Registry
2. Set up one Cloudflare Tunnel with one subdomain
3. Deploy Ollama, pull qwen3:8b and nomic-embed-text:latest
4. Deploy the chat completions runner and embeddings runner
5. Sign up at blueclaw.network, test via the playground

That's it. You're serving AI inference on a decentralized network.

What Models Are Supported?

BlueClaw currently supports a growing roster across all three capabilities:

Chat: qwen3:8b, gemma-3-4b-it, Qwen2.5-14B-Instruct-AWQ, Llama-3.3-70B-Instruct-FP8
Embeddings: nomic-embed-text, SFR-Embedding-2_R
Image Generation: RealVisXL V4.0 Lightning, FLUX.1-dev

The model list will expand as more orchestrators come online and new runners are developed.

Open Source, All the Way Down

Every BYOC runner is open source. The full suite lives under github.com/Cloud-SPE:

• Chat + Embeddings runners — Go
• Capability registration — Go
• Rerank runner — Python/FastAPI (experimental)
• Video generation runner — Python/FastAPI (experimental)
• Gateway proxy — Go

Want to build a runner for a workload that doesn't exist yet? The framework is designed for exactly that.

Get Started

The full onboarding guide is available now. To get your copy and start the process:

👉 Reach out to @mike_zoop on the Livepeer Discord

Mike will share the complete guide, answer your questions, and help you through any setup issues. You can also find him in the #orchestrating channel.

Whether you're running a single 3090 or a rack of 4090s, there's a path for you. The guide covers it all — from the minimal setup to multi-GPU, multi-backend deployments with vLLM and image generation.

The Bigger Picture

Livepeer started as a video transcoding network. With BlueClaw, it becomes something larger: a decentralized GPU compute layer for AI inference. The same orchestrators who built the network's video infrastructure are now positioned to power the next generation of AI applications.

The demand is here. The tooling is ready. The guide is written.

The only question is whether your GPUs are going to sit idle — or get to work.

BlueClaw Network — Decentralized AI inference on the Livepeer network.
Built by Cloud SPE for the Livepeer community.
Questions? Find @mike_zoop on Livepeer Discord.

By the Cloud SPE Team — Livepeer.Cloud

The Network Is Growing. Now It Needs to Be Measurable.

Livepeer has evolved from a decentralized video transcoding protocol into a full-fledged AI compute network — handling image generation, video synthesis, LLM inference, text-to-speech, and more. Orchestrators around the world power these workloads on GPUs ranging from GTX 1080s to RTX 5090s serving gateways and applications that depend on performance and reliability.

But here's the gap: until now, there hasn't been a shared, network-wide way to measure how well it's all working.

Gateway providers couldn't easily compare orchestrator performance across regions or workloads. Orchestrators had no standardized way to demonstrate reliability. Developers evaluating Livepeer for production use had to trust marketing materials instead of transparent data. And the broader ecosystem lacked the foundation needed to build SLA-aware routing, scaling, or any kind of production-grade service guarantees.

That's what this project changes.

What We Built

The Cloud SPE has joined forces with the Livepeer Foundation, Livepeer Inc, and the Livepeer Community to design, build, and deploy the NaaP (Network-as-a-Product) Analytics MVP — a complete metrics, analytics, and observability platform for the Livepeer AI network.

Funded through the Livepeer Treasury and aligned with the Livepeer Foundation's roadmap to make network data more observable, this project delivers:

Core SLA Metrics

A standardized set of performance, reliability, and demand metrics — covering everything from job success rates and GPU throughput to latency, FPS stability, and payment economics. These metrics are sourced from gateway telemetry, orchestrator signals, and reference load tests, unified into a single analytics layer.

Network Test & Verification Signals

We operate reference load-test gateways that generate consistent, reproducible performance signals across live AI pipelines. Public test scenarios are designed to reflect real workloads, are transparent and community-verifiable, and feed directly into the same analytics layer as organic network traffic.

Analytics & Aggregation Layer

A purpose-built data pipeline transforms raw events into network-level views. Events flow from Kafka through ClickHouse, normalized through a resolver service, shaped by dbt semantic models, and served through a Go REST API. The architecture prioritizes efficient querying — dashboards never need to scan raw job data.

Public Dashboard & APIs

A standalone Grafana-powered dashboard presents live and historical metrics across four key domains: system health, real-time operations, economics and payments, and performance drill-downs. Public, read-only APIs expose aggregate SLA scores, GPU supply inventory, and orchestrator leaderboard data. Gateways and ecosystem teams can consume this data directly or mirror it into their own systems.

Operations & Stewardship

The entire platform is deployed across a production-grade infrastructure with automated monitoring, Prometheus metrics, and documented runbooks. We're committed to maintaining and operating this infrastructure for the Livepeer community.

Why This Matters

This isn't a dashboard project. It's the measurement layer that the Livepeer network requires to evolve from "decentralized compute that works" into "production infrastructure you can bet your business on."

For Gateway Providers: You can now evaluate orchestrator performance with real data — compare reliability, latency, and throughput across regions and workloads before routing a single job.

For Orchestrators: Your performance is now visible and comparable. Good work gets recognized. The network rewards reliability, not just availability.

For Developers & Partners: Evaluating Livepeer for production use no longer requires a leap of faith. The data is public, the APIs are open, and the methodology is transparent.

For the Ecosystem: Future SLA-aware routing, automated scaling, and production service guarantees all depend on trusted measurement. This is that foundation.

The Road Here

This project didn't arrive overnight. It started with community conversations about what Livepeer needed to become a true production platform. An initial pre-proposal in October 2025 drew thoughtful feedback — the community pushed back on scope, cost, and architectural complexity. They were right.

We listened. We reset. We narrowed the scope, reduced the budget, simplified the architecture, and prioritized time-to-value. The revised proposal earned broad support — from the community, from Livepeer Inc, and from the Livepeer Foundation — and passed the treasury vote in January 2026.

Work had already begun in November 2025, and we've executed across three milestones: metrics collection and aggregation, test signals and derived analytics, and stabilization. The result is a production system that's live, documented, open source, and ready for the community to build on.

What Comes Next

This MVP establishes shared measurement. It does not enforce SLAs, modify protocol incentives, or introduce routing logic. Those are future decisions that the community can now make with data in hand.

What this enables:

• SLA-aware routing — gateways can route jobs based on demonstrated performance, not just price
• Network quality scoring — aggregate reliability metrics that make Livepeer legible to enterprise buyers
• Data-driven governance — treasury proposals and network decisions grounded in observable outcomes

We built this as neutral, public infrastructure. The data belongs to the network. The code is open source. The APIs are public. And we're here to maintain it, improve it, and support the teams that build on top of it.

About Cloud SPE

Cloud SPE is a Special Purpose Entity within the Livepeer ecosystem, founded by three Livepeer orchestrator node operators: Speedy Bird Technologies, Mike Zupper (Xode App), and Papabear (Solar Farm). We operate free-to-use Livepeer gateways, build open-source tooling for the network, and work to make decentralized video and AI infrastructure accessible to everyone.

This is our third treasury-funded project. Previous work includes the original SPE gateway and demand generation infrastructure and the AI Performance Leaderboard integrated into the Livepeer Explorer. Each project has built on the last, and NaaP Analytics represents the most ambitious — and most important — step yet.

Join the conversation in Livepeer Discord.

We are thrilled to announce that Livepeer.Cloud SPE has just created a new Livepeer Treasury Proposal for our second project: AI Performance Leaderboard to be integrated into the Livepeer Explorer. This initiative aims to significantly enhance the Livepeer AI Subnet by providing valuable metrics and performance insights.

Key Components of the Project

1. AI Job Tester
   1. This component will submit AI jobs to each Orchestrator and rigorously test their performance. By running these tests, we will gather critical data on how well each Orchestrator handles AI tasks.
2. AI Leaderboard API
   1. The API will be responsible for storing and managing data from the AI Job Tester. It will handle all API calls and ensure that the data is readily available for viewing and analysis.
3. Integration into Livepeer Explorer Orchestrator Performance Leaderboard
   1. The final component involves integrating the AI performance metrics into the existing Livepeer Explorer UI. This will allow Orchestrators and Delegators to easily compare performance and make informed decisions.

Project Timeline

We anticipate that this project will take approximately 3 months to complete. Once implemented, the AI Performance Leaderboard will have a substantial impact on the Livepeer AI subnet, providing clearer insights and fostering better performance across the network.

Call to Action

We encourage all Orchestrators and Delegators to support this initiative. Your involvement will help ensure the success of this project and its positive impact on the Livepeer ecosystem.

For more details, you can review the full proposal here and check out the pre-proposal discussion here.

Stay tuned for updates, and thank you for your continued support!

We are excited to announce the launch of Livepeer.Cloud Dream, the newest addition to Livepeer.Cloud that transforms the way you create images and videos. Access Dream now at https://dream.livepeer.cloud, and dive into the future of AI-driven media generation.

Alpha Release Available Now
Our user interface is still under development, but we couldn’t wait to give you a sneak peek with our alpha release. Dream is designed to empower creators with sophisticated AI tools that make image and video generation both simple and intuitive.

Open Source Innovation
In our commitment to community-driven development, we are thrilled to open source the StableStudio Livepeer AI Plugin. This initiative allows you to design your own interfaces and harness the power of Livepeer's AI Gateway Nodes for a tailored AI creation experience.

Exciting Features on the Horizon
Our team is working on expanding Dream's capabilities with the introduction of image to video transformation, the ability to upscale images to larger sizes, and support for a more diverse range of AI models.

Join the Creative Revolution
Dream is more than just a service; it's a playground for the imagination. This platform not only supports the imaging pipeline but also showcases the vast possibilities within the image-to-image and video AI ecosystem. We encourage developers, artists, and innovators to explore Dream, experiment with its capabilities, and push the boundaries of digital media creation.

Embark on your creative journey with Dream and start transforming your visions into stunning visual realities today!

Livepeer Cloud is proud to announce the alpha release of the integration between Livepeer and Owncast.

This integration enables the feature called "Stream Relay" which enables self-hosted Owncast instances to relay their stream to a remote transcoding service like the Livepeer Cloud gateway, powered by the Livepeer Protocol.

This project has been under construction since November of 2023 and is now ready for Owncast users to take advantage. You can download the release on Github or use the docker image from Docker Hub. For detailed instructions visit our Getting Started guide.

In the ever-evolving landscape of live streaming, content creators are constantly seeking more affordable, flexible, and decentralized solutions. Enter Livepeer, a protocol that empowers individuals to take control of their streaming infrastructure through its decentralized video transcoding capabilities. In this article, we'll explore how to run a Livepeer Gateway Node in Broadcaster Mode, and unlock a new era of streaming freedom.

Embracing Decentralization and Cost Efficiency

One of the primary advantages of running a Livepeer Gateway Node is the ability to self-host at a fraction of the cost compared to Software as a Service (SaaS) or cloud-based solutions. Traditional streaming services often come with hefty price tags, making it challenging for independent creators and smaller organizations to afford reliable streaming infrastructure. By leveraging Livepeer's decentralized protocol, individuals can tap into a cost-effective alternative that doesn't compromise on performance or reliability.

Decentralizing Centralized Services

Livepeer's decentralized approach revolutionizes the streaming industry by challenging the dominance of highly centralized cloud-based services, particularly Real-Time Messaging Protocol (RTMP) and HTTP Live Streaming (HLS). Traditionally, these services are controlled by a handful of major corporations, leading to vendor lock-in and limited options for content creators. However, with Livepeer, users can break free from centralized control and embrace a more diverse and inclusive streaming ecosystem.

Freedom from Vendor Lock-in

Running a Livepeer Gateway Node also offers the advantage of platform-neutral technology, eliminating the risk of vendor lock-in. Many streaming platforms require users to adhere to specific software or hardware requirements, locking them into proprietary systems and limiting their flexibility. In contrast, Livepeer's open and decentralized protocol ensures that users have the freedom to choose the tools and technologies that best suit their needs, without being tied to a single vendor.

Promoting Broadcaster Diversity

Another compelling reason to run a Livepeer Gateway Node is to contribute to the diversity of broadcasters within the Livepeer protocol. In a decentralized ecosystem, diversity is key to ensuring resilience, scalability, and inclusivity. By running a node, individuals can actively participate in expanding the network and empowering a broader range of content creators to share their stories and reach audiences worldwide.

Getting Started with Livepeer Gateway Node

So, how can you get started with running a Livepeer Gateway Node? The process is simpler than you might think. Whether you're a seasoned streaming veteran or a newcomer looking to dip your toes into the world of live streaming, Livepeer Cloud provides the tools and support you need to succeed. Check out the Getting Started guide for all the details needed to leverage the Free-To-Use Livepeer Cloud infrastructure.

So why wait? Leverage the Livepeer Cloud transcoding services today and revolutionize the way you stream live content.