Roadmap
The Platform capabilities page is the source of truth for what you can use today. This roadmap groups the work ahead by the same product areas, so each section here lines up with a section of the capability matrix.
Current focus
Section titled “Current focus”Current work centers on security and performance hardening, deployment flexibility, player QoE, and cross-region replication measurements. DRM and the media-engine ONNX runtime remain in active development. The badges show relative order, not release dates.
Streaming
Section titled “Streaming”What ships today in this area: Platform capabilities → Streaming.
Pull-Input Streams Now
Section titled “Pull-Input Streams ”Pull streams are available through the dashboard, API, and agents. The remaining work is deeper operational visibility for upstream connection attempts, retries, private-source edge cases, and self-hosted deployment diagnostics across RTSP cameras, SRT/RIST feeds, HLS origins, MPEG-TS sources, and Mist/DTSC sources.
Device Discovery and Contribution Inputs Next
Section titled “Device Discovery and Contribution Inputs ”The media engine already has experimental local discovery and local-source creation paths. The FrameWorks work is productizing that capability around an Edge node: packaging it into the edge runtime, exposing it through the API and dashboard, and making it usable from the Tray app and CLI. A discovered camera becomes a managed stream, and the same node can run live AI on that feed.
This depends on edge clusters and the Tray/CLI companion runtime. An on-prem FrameWorks Edge will discover cameras, PTZ devices, NDI sources, USB capture, and HDMI contribution paths, then ingest them into managed FrameWorks streams or self-hosted clusters without hand-built local glue.
Playback
Section titled “Playback”What ships today in this area: Platform capabilities → Playback.
DRM Next
Section titled “DRM ”FairPlay, Widevine, and PlayReady support is in development, built on playback access control and the player SDKs. Until DRM lands, premium playback workflows that require it should stay on their existing provider.
Media Library
Section titled “Media Library”What ships today in this area: Platform capabilities → Media Library.
Scheduled Programming Next
Section titled “Scheduled Programming ”Two scheduling layers are planned on the recording and VOD foundations. Scheduled recordings are calendar-driven DVR captures for places of worship, periodic events, classes, and any workflow where a stream goes live on a known schedule: recording starts and stops automatically against a stream that may already be live 24/7, and the operator does not need to be at the desk when the window opens. Scheduled VOD streams are linear live channels assembled from existing VOD assets: the scheduler selects finalized artifacts, verifies or pre-hydrates frozen assets before their playout window, and materializes a rolling live stream without bypassing artifact ownership, retention, or billing semantics.
Processing & AI
Section titled “Processing & AI”What ships today in this area: Platform capabilities → Processing & AI.
Gateway-Backed Transcoding Now
Section titled “Gateway-Backed Transcoding ”Livepeer Gateway integration is active. We are expanding native controls, plan-aware defaults, and dashboard/API workflows for adaptive renditions.
Live AI Processing Next
Section titled “Live AI Processing ”An ONNX runtime in the media engine is in active development, running ultralight CPU models directly on the in-memory stream buffer of a media edge node. Object detection and segmentation (YOLO) and audio transcription (Parakeet) are already tested; candidate workloads include content moderation, audio event tagging and speaker identification, and frame/text embeddings for semantic search. Heavy models defer to dedicated compute via the Livepeer network, with client-side processing stats in the media engine and processing-aware cluster scheduling as the remaining orchestration work. Pilot access is available via contact.
Workload Cost Model Next
Section titled “Workload Cost Model ”Processing placement today routes by node class and current load; what a job will actually cost is only knowable after it runs. The planned cost model predicts a job’s footprint — CPU, GPU/VRAM, bandwidth — from its parameters (codec, resolution, framerate, model size, faster/slower-than-realtime factor), corrects those predictions continuously from measured costs of completed jobs, and accounts for interference between co-placed jobs and live serving on the same node. The scheduler will measure and allocate GPU and VRAM. The model extends processing orchestration and the capacity score used by viewer routing, so transcode and AI jobs are placed before they overload a node.
Composition and SSAI Later
Section titled “Composition and SSAI ”Composition stays inside the media engine: a MistServer-native blitter for logos, watermarks, and lower-third overlays; MistServer’s Composer reused for server-side ad insertion (SSAI) and raw-pixel composition; picture-in-picture and automated clipping layered on top.
Analytics & Observability
Section titled “Analytics & Observability”What ships today in this area: Platform capabilities → Analytics & Observability.
View-Level QoE Analytics Now
Section titled “View-Level QoE Analytics ”Stream and routing analytics already exist, and first-party view-level QoE now ships for the FrameWorks player — rebuffering, frame drops, startup time-to-first-frame, and per-asset VOD retention/watch-density. The active telemetry pass is reducing time-to-first-frame and measuring and reducing cross-region stream-replication time. What’s still ahead is the breadth: QoE capture from third-party / non-FrameWorks players and deeper per-view tracing.
Incidents and Alerts Now
Section titled “Incidents and Alerts ”Lookout now turns platform alerts into tenant-aware incidents with acknowledge, assignment, resolution, notes, realtime updates, operator notifications, and Skipper investigations. Tenants see incidents only for clusters they own; platform operators retain the cross-tenant operational view. See the incident API guide and operator setup.
The remaining work is broader alert coverage, especially richer edge reachability, certificate, DNS, capacity, and per-stream causes. Those signals can join the same incident workflow without changing its ownership or authorization model.
Infrastructure & BYOC
Section titled “Infrastructure & BYOC”What ships today in this area: Platform capabilities → Infrastructure & BYOC.
Bring Your Own Edge Now
Section titled “Bring Your Own Edge ”Bring your own MistServer and Helmsman nodes while FrameWorks operates Foghorn, federation, DNS/TLS, Livepeer, Chandler, durable storage, analytics, billing, and access control. Virtual private clusters are logical tenant-private slices of that FrameWorks-operated routing plane. Teams can mix their edge capacity with managed FrameWorks regions or list spare edge capacity without operating a federation peer. Teams that want to run Foghorn and the rest of the platform themselves can self-host the entire stack as an independent platform with the operator guides.
Dedicated Provider Capacity Next
Section titled “Dedicated Provider Capacity ”FrameWorks-provisioned dedicated capacity remains future work: isolated provider-operated nodes for one tenant, with reserved-capacity pricing and an operator console, built on edge clusters, virtual private routing slices, and the planned Edge images. Running Foghorn on your own infrastructure is covered by full self-hosting, which also means running federation identity, Livepeer, Chandler, object storage, DNS, analytics, and the control plane yourself.
Edge ISO and Cloud Images Next
Section titled “Edge ISO and Cloud Images ”Edge enrollment and bootstrap exist today; the packaging is next: a bootable FrameWorks Edge ISO for bare metal and prebuilt images with cloud-marketplace listings (AWS, GCP, DigitalOcean, Hetzner, Linode, Vultr) so a media cluster can scale on demand. The same images serve FrameWorks’ own capacity and BYOC deployments, and they are groundwork for hosted-private-cluster provisioning automation.
Public Cluster Marketplace Next
Section titled “Public Cluster Marketplace ”Marketplace primitives — listing, invites, subscription requests, approvals, preferred-cluster routing, pricing models, and metered/custom rating — ship today. The remaining work is the public operating model: operator vetting, published commercial terms, support boundaries, and a production onboarding workflow for third-party capacity.
Placement Policy and Storage Tiering Next
Section titled “Placement Policy and Storage Tiering ”Where content lives becomes policy-driven from two sides: cluster owners declare what workload they accept, content owners declare where their material may go — data residency, minimum durable copies — and both compile into signed enforcement bundles evaluated at every decision point (serve, ingest, process, store, replicate, peer). Underneath sits a storage tier ladder from cold archive to hot in-memory, with a ledger of which copies exist where. The same policy model will cover managed SaaS, customer edge capacity, and authorized federation peers.
Stream Replication Orchestration Next
Section titled “Stream Replication Orchestration ”Replication today is on-demand: a viewer shows up, the edge pulls the stream. Orchestration adds the proactive half — pre-emptively spreading a stream to a cell or region ahead of expected demand, explicit hop topology between origin and edge, and per-stream replication policy (replica caps, allowed regions).
Federation State Synchronization Next
Section titled “Federation State Synchronization ”Federation-wide configuration and state distribution today flows through one central management point. This work makes it decentral: clusters and servers of independent parties join, leave, or drop offline at will; concurrent changes from multiple parties resolve automatically without a central coordinator; and parts of the network that diverge during a partition reconverge when connectivity returns.
NAT-Aware Routing and Traversal Next
Section titled “NAT-Aware Routing and Traversal ”Self-hosted nodes often sit behind NAT, where reachability depends on NAT type and connection direction. The control plane gains NAT-type classification as a routing and placement signal, coordination of traversal attempts between the right node pairs, and platform-managed probe/relay infrastructure that also measures inter-server network performance (latency, throughput) as an input to routing and capacity decisions — so a node in an office network participates fully in the federated network.
Platform Trust and Operations Hardening Next
Section titled “Platform Trust and Operations Hardening ”Two operational deepenings of the platform itself: live rotation of trust material (intermediate CA rotation with overlapping validity, asymmetric token signing where keys never leave the issuing service, cluster-bound service identity) and drain-integrated OS updates, where each server role defines what a safe restart means — media sessions run out, database replicas gate on recovery, brokers hand over leadership — while cluster capacity floors hold during the update wave.
Managed DNS, Proxying, and Storage Services Later
Section titled “Managed DNS, Proxying, and Storage Services ”Managed DNS, generic CDN/proxying, and standalone object/block storage are backlog items adjacent to video delivery. FrameWorks already runs DNS automation, service proxying, and media storage internally for operated deployments; the roadmap work is turning the right parts into customer-facing products with domains, origins, Ceph-backed storage resources, self-hosted/Anycast DNS paths, policies, billing, and support boundaries.
Product Boundary: Customer-Operated Control Plane
Section titled “Product Boundary: Customer-Operated Control Plane”FrameWorks supports three ways to run: hosted, self-hosted edges attached to the FrameWorks platform, and full self-hosting of the entire stack (control plane, Foghorn, edges, Livepeer, Chandler, databases, analytics, and interfaces) as an independent platform deployed with the frameworks CLI; see the operator guides. A self-hosted platform has its own Foghorn, federation identity, and trust root. Federating an independently operated platform with the FrameWorks platform as one network, such as a customer Foghorn joining the FrameWorks network or mixing trust roots, is not supported and is not on the roadmap.
Commerce & Billing
Section titled “Commerce & Billing”What ships today in this area: Platform capabilities → Commerce & Billing.
Operator Settlement and Attribution Next
Section titled “Operator Settlement and Attribution ”In a federated network, one viewer session can cross clusters run by different operators. Settlement attributes every served byte to the operator who actually carried it — manipulation-resistant, so no participant can claim traffic they didn’t serve — and closes the loop: credit accrual, operator-visible reporting, and payout execution. The accrual ledger exists internally today; the attribution hardening, reporting surface, and payouts are the roadmap work.
Stream-Level Balances Later
Section titled “Stream-Level Balances ”Optional per-stream balances that fund usage before the tenant balance — enabling pay-per-view, tips, and sponsor-funded streams — plus promo codes, referral rewards, and volume discounts.
Developer Platform & Agents
Section titled “Developer Platform & Agents”What ships today in this area: Platform capabilities → Developer Platform & Agents.
Agent and Automation Workflows Now
Section titled “Agent and Automation Workflows ”We are expanding agent-facing workflows around operational diagnostics, billing preflight, and safe platform changes through MCP and GraphQL.
Agents use the same underlying controls as humans, with confirmation gates retained for sensitive or billable actions.
More SDK languages Later
Section titled “More SDK languages ”The TypeScript, Go, and Python SDKs ship today. SDKs for PHP, Ruby, Elixir, Java, and C# would be generated from the same operation set and pass the same conformance fixtures. Until then, those languages use the GraphQL API directly and a Standard Webhooks library for webhook verification.
Engagement & Interactivity
Section titled “Engagement & Interactivity”What ships today in this area: Platform capabilities → Engagement & Interactivity.
Conferencing and Chat Next
Section titled “Conferencing and Chat ”The next major feature theme after the current telemetry pass. Conferencing brings multi-party WebRTC rooms and remote contribution — a commentator or guest joins a room and their audio (video later) is mixed into the managed stream. Viewer chat ships alongside it as the first surface of the rooms service.
Rooms and Interactivity (Parlor) Next
Section titled “Rooms and Interactivity (Parlor) ”Beyond chat, the rooms service grows into engagement primitives synced to the stream: channel points, hype trains, leaderboards, viewer flair, viewer games, and moderation views with per-viewer history. Events bind to the stream timeline per viewer — everyone sees a reaction at the moment it belongs to, regardless of how far behind the live edge they watch.
Live Commerce (Shopping and Auctions) Next
Section titled “Live Commerce (Shopping and Auctions) ”Shopping and auctions attached to live streams: product showcases, carts and orders, and server-authoritative auction mechanics. The hard problem is latency fairness — viewers watch at different distances behind the live edge, so interactive events must bind to the stream timeline, and competitive interactions like auction closes need one authoritative truth that treats differently-delayed bidders fairly. This depends on rooms, timeline-aware interactivity, and stream-level balances.
Account & Apps
Section titled “Account & Apps”What ships today in this area: Platform capabilities → Account & Apps.
Team Accounts and Permissions Next
Section titled “Team Accounts and Permissions ”Multi-user accounts, role-based permissions (owner, operator, developer, finance), and audit visibility are planned for tenants that need shared operations.
Mobile Apps and Help Center Later
Section titled “Mobile Apps and Help Center ”Native mobile apps and an integrated help center are planned, but they come after the core platform surfaces are complete.