Selfhosters

Production readiness

Tenant-owned edge clusters, enrollment tokens, and node mode ship across the dashboard, API, and CLI. As with any self-hosted infrastructure, plan production rollouts with the usual operator validation around DNS, certificates, firewall policy, capacity, and monitoring.

Edge Node Connectivity

Hybrid edge nodes communicate with the FrameWorks network via public APIs (HTTP/gRPC). They do not participate in the internal WireGuard mesh (Privateer), which is reserved for backend infrastructure nodes.

Run your own edge nodes for ingest and delivery while FrameWorks operates the media control plane, analytics, routing, and durable services.

How It Works

graph LR
    subgraph YN[Your Edge Node]
        MS[MistServer<br/>+ Helmsman]
    end

    subgraph FN[FrameWorks Network]
        COM[Commodore<br/>stream auth]
        FOG[Foghorn<br/>load balancer]
        DL[Decklog<br/>event ingress]
    end

    MS -->|gRPC| FOG
    FOG -->|gRPC| COM
    FOG -->|gRPC| DL

1. MistServer is the media engine: ingest, processing/transcoding (including Livepeer‑powered ABR when configured), broad playback/container outputs (HLS, LL-HLS, DASH, WebRTC, MP4, WebM, WebSocket), and direct protocols when exposed
2. Helmsman (our sidecar) handles tight integration with Foghorn and forwards triggers/metrics via gRPC
3. Foghorn enriches events (GeoIP, tenant context), validates stream keys via Commodore (gRPC), and forwards to Decklog
4. Decklog receives enriched events from Foghorn and produces them to Kafka for analytics

Prerequisites

Before you start:

• A Linux or macOS host (container mode runs the single edge image; native mode uses systemd/launchd)
• Docker with the Compose plugin when using container mode (Docker Desktop or OrbStack on macOS)
• Public IP or reachable public DNS name for viewer traffic
• A DNS record for the assigned edge domain, unless the Bridge bootstrap flow assigns and syncs it for you
• Ports available as needed (expose only what you use):
  • 80/443 (HTTP/HTTPS)
  • 1935 (RTMP/E-RTMP ingest)
  • 8080 (MistServer HTTP)
  • 5554 (RTSP)
  • 8889/udp (SRT)
  • 18203/udp (WebRTC)
  • 4200 (DTSC replication, Mist ↔ Mist)
  • 4242 (Mist controller; keep internal/local)
• A FrameWorks account for one-command Bridge setup, or a valid edge_node enrollment token for token-based setup

Hardware minimums:

• Starting point for light workloads (scale with streams/transcodes):
  • 4 CPU cores (or less for very low volume)
  • 8 GB RAM
  • 100 GB storage (more if you’re doing recordings)
  • 1 Gbps network

Supported Ownership Boundary

FrameWorks can be run three ways: hosted, as self-hosted edges attached to the FrameWorks platform (this section), or fully self-hosted as an independent platform. In the self-hosted edge mode, you operate MistServer, Helmsman, Caddy, and the host they run on. FrameWorks operates Foghorn and its federation identity, Commodore, Livepeer integration, Chandler, object storage, DNS/TLS automation, billing, analytics stores, and the rest of the control plane.

A virtual private cluster is a tenant-private placement and routing slice in the FrameWorks-operated Foghorn plane. It isolates authority and capacity for your tenant; it is not a customer-operated Foghorn.

Responsibility	Customer edge	FrameWorks
MistServer and Helmsman host	Operates	—
Ingest and viewer capacity on that host	Operates	Routes and authorizes
Foghorn and cross-cluster federation	—	Operates
Livepeer, Chandler, and durable object storage	—	Operates
DNS, certificates, billing, and analytics stores	—	Operates

Running Foghorn yourself is not an extension of edge self-hosting. Foghorn needs its own federation trust root and compatible Livepeer, Chandler, storage, DNS, and control-plane services, so running it means self-hosting the entire stack as an independent platform with the frameworks CLI; see the deployment guide. A self-hosted platform cannot join the FrameWorks network: attaching your own Foghorn to the FrameWorks platform or mixing trust roots is not supported.

Platform operators (FrameWorks, or you if you self-host the entire stack) should use the edge hardening rollout runbook when deploying the v0.3.0 authorization, enrollment, inventory, and DNS entitlement transitions.