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”The active engineering batch is internal hardening (security, performance) and deployment flexibility — making it easier to plug your own long-term storage, cloud compute, or on-premise capacity into the platform. Next comes a playback-telemetry pass: reducing time-to-first-frame and measuring and reducing cross-region stream-replication time. After that, conferencing and chat open as the next major feature theme. In parallel, DRM (FairPlay, Widevine, PlayReady) and the media-engine ONNX runtime for live AI are in active development.
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.
Outcome: bring RTSP cameras, SRT/RIST feeds, HLS origins, MPEG-TS sources, and Mist/DTSC sources into FrameWorks with clearer failure states.
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. It composes with the rest of the edge story: a discovered camera becomes a managed stream, and the same node can run live AI on that feed.
Builds on: edge clusters and the Tray/CLI companion runtime.
Outcome: let an on-prem FrameWorks Edge 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. Until DRM lands, premium playback workflows that require it should stay on their existing provider.
Builds on: playback access control and the player SDKs.
Outcome: protect premium playback workflows without moving video delivery out of the FrameWorks control plane.
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.
Outcome: a weekly service or lecture records itself on its own schedule, and a VOD catalog becomes a programmed live channel — with the resulting assets staying in the normal library lifecycle.
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.
Outcome: enable ABR when source bitrate or viewer networks make a single rendition impractical.
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.
Builds on: processing orchestration and edge clusters.
Outcome: run real-time AI where the stream already is — on the edge node — and burst heavy models to dedicated compute without leaving the control plane.
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. GPU and VRAM become first-class, measured resources.
Builds on: processing orchestration and viewer routing’s capacity scoring.
Outcome: place transcode and AI jobs where they actually fit — before they run — instead of discovering overload after the fact.
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.
Outcome: move more production work into the same control plane that already handles ingest, delivery, assets, and analytics.
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.
Outcome: answer which viewers buffered, why they buffered, and which route or rendition they used — across any player, not just the FrameWorks one.
Incidents and Alerts Next
Section titled “Incidents and Alerts ”A tenant-scoped incident feed is planned: node-health, certificate, DNS, capacity, and cluster alerts aggregated with acknowledge/resolve workflows, realtime delivery, and agent tooling for triage. Self-hosted operators get visibility into their own clusters — certificate expiry, port reachability, DNS resolution, resource thresholds — without standing up a separate monitoring stack.
Outcome: see what needs attention across streams, nodes, and clusters, and let humans or agents acknowledge and resolve it from the same platform.
Infrastructure & BYOC
Section titled “Infrastructure & BYOC”What ships today in this area: Platform capabilities → Infrastructure & BYOC.
Bring Your Own Cloud: Edge, Hybrid, and Federation Now
Section titled “Bring Your Own Cloud: Edge, Hybrid, and Federation ”FrameWorks runs across a spectrum of ownership, from fully hosted to fully sovereign. The first BYOC level ships today: bring your own MistServer edge nodes and let FrameWorks handle DNS, TLS, geo-balanced routing, cluster federation, tenant subdomains, analytics, playback access control, and the rest of the operations layer around them. The same plane supports teams running self-hosted clusters, teams that mix their own infrastructure with managed FrameWorks regions, and teams that want to list spare capacity to others. We are hardening this path and the diagnostics around self-hosted deployments.
Outcome: stand up a production-grade MistServer cluster without gluing together ten separate services for DNS, certificates, routing, observability, billing, and access control.
Dedicated and Private Clusters (BYOC) Next
Section titled “Dedicated and Private Clusters (BYOC) ”Two deeper BYOC levels are in design. A private media cluster lets you run the media and data plane on your own cloud while leaning on the FrameWorks control plane for tenancy, routing, billing, and access control; the remaining work is federation-trust hardening (scoped per-cluster credentials or mutual TLS) for clusters on customer-controlled infrastructure. Hosted private clusters let FrameWorks provision dedicated, isolated capacity for a single tenant with reserved-capacity and fixed-rate pricing; the remaining work is cloud-provider provisioning automation, a reserved-capacity billing model, and an operator console.
Builds on: edge clusters and federation for the private level; the Edge ISO and cloud images below for hosted provisioning.
Outcome: keep more of the stack on infrastructure you choose, or reserve dedicated FrameWorks-operated capacity, without dropping to a fully hand-built deployment.
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.
Outcome: boot a FrameWorks Edge from an ISO or a marketplace image and add media capacity on demand — on our infrastructure or yours.
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.
Outcome: turn the existing marketplace plumbing into a vetted public program so tenants can buy capacity from third-party operators with a known support and trust contract.
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.
Builds on: BYOC ownership levels and the cluster marketplace.
Outcome: run one policy model across SaaS, self-hosted, and federated deployments — so sovereignty requirements are enforced by the platform, not by operational discipline.
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).
Builds on: the federation network and viewer routing.
Outcome: position streams where the audience will be before the audience arrives, under explicit per-stream policy.
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.
Builds on: the federation network.
Outcome: a federation where no single party’s outage or authority blocks the rest of the network from changing and converging.
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.
Builds on: edge clusters and the federation network.
Outcome: stop treating NAT’d nodes as second-class — route and place around reachability instead of failing on it.
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.
Outcome: long-lived clusters that refresh their own trust and patch their own hosts without maintenance windows or service interruption.
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.
Outcome: cover more of the infrastructure teams already wire around their video workloads without pretending internal operator plumbing is a self-serve product.
Fully Sovereign Self-Hosting (BYOC) Later
Section titled “Fully Sovereign Self-Hosting (BYOC) ”The deepest BYOC level: run the entire stack with no runtime dependency on FrameWorks, including your own object storage and analytics store, your own DNS, and an isolated control plane and identity root. Self-hosting the stack is possible today, but the control and data plane still assume a shared FrameWorks root. Making them fully portable needs dedicated-database and identity decoupling, self-hosted DNS (PowerDNS is planned, not built), and a bring-your-own storage and analytics path. Today FrameWorks runs ClickHouse and S3-compatible storage for hosted tenants; this is the work that turns “self-host the stack” into “host nothing on us at all.”
Builds on: standalone object/block storage and managed DNS from the Managed DNS, Proxying, and Storage Services item above.
Outcome: operate FrameWorks entirely within your own jurisdiction and ownership boundary, with no control-plane dependency on us.
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.
Builds on: the cluster marketplace and federation network.
Outcome: third-party operators get paid for the traffic they serve, with numbers both sides can verify.
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.
Outcome: let a stream pay for itself, funded by its audience or its sponsor, without touching the tenant’s main balance.
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.
Outcome: let agents operate FrameWorks with the same controls humans use, while preserving confirmation gates for sensitive or billable actions.
Event Webhooks Next
Section titled “Event Webhooks ”Outbound webhooks are planned for platform events such as stream lifecycle changes, asset readiness, billing events, and operational alerts.
Outcome: connect FrameWorks events to your own systems without polling.
Backend SDKs Later
Section titled “Backend SDKs ”Server-side SDKs are planned for Node, Python, PHP, Ruby, Elixir, Java, and C#, wrapping the GraphQL API, webhook verification, uploads, and access-token/JWT workflows. Delivery is phased, starting with Node and Python. Frontend packages for the player and StreamCrafter ship today.
Outcome: integrate FrameWorks from your backend in your language of choice without hand-writing GraphQL plumbing.
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.
Outcome: bring guests and commentators into the stream itself and give every stream a live chat, without third-party tooling.
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.
Outcome: give streamers first-class engagement and monetization mechanics on their own infrastructure instead of bolting on overlay services.
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.
Builds on: rooms and interactivity, and stream-level balances for funding flows.
Outcome: sell and auction inside the stream itself, with mechanics that stay fair at live-streaming latencies.
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, and audit visibility are planned for tenants that need shared operations.
Outcome: separate owners, operators, developers, and finance workflows without sharing a single account credential.
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.
Outcome: make FrameWorks easier to operate from more places without splitting the product experience.