FrameWorks 0.3.0
FrameWorks 0.3.0 is out. Until this release, running a FrameWorks platform meant answering many everyday questions from private dashboards and a database console. 0.3.0 gives operators and tenants a supported view of what is happening, keeps viewers watching through control-plane blips, lets you say where your streams may run, and puts guardrails around what AI agents can do. Operators upgrading self-hosted edges should read the note at the end first.
Operators and tenants can see what is happening
Section titled “Operators and tenants can see what is happening”Platform admin is the most direct change. A cross-tenant admin API and admin console give operators one supported place to inspect tenants, clusters, billing, and content. Access to it is an explicit grant, and every use lands in an audit log. That matters for hosted operations and for anyone running more than one cluster.
Analytics is moving out of the internal-only bucket. Playback quality of experience, tenant activity, operator activity, stream monitoring controls, and a consolidated set of dashboard charts put the platform’s state in front of the people who can act on it. The goal is answering normal operational questions without opening three private dashboards and a SQL console. For programmatic access, see the analytics API.
Playback and placement hold up under failure
Section titled “Playback and placement hold up under failure”Viewers who are already watching keep watching when the control plane is briefly unreachable. New viewers are admitted from signed answers the media cluster already holds, so a short central outage does not turn into refused playback. One viewer’s approval is never reused for another: an earlier yes says nothing about the new viewer’s location, their permission, or a policy that changed since. Viewers keep watching when the control plane blips explains the rule and its limits. Alongside it, clusters tell each other which streams they can serve, so a viewer can be served through a peer cluster, and native edge installs on Linux and macOS are smoother.
Media placement is the other routing change. Where a request is answered, where a stream originates, and where a viewer receives it are three different places, and 0.3.0 stops treating a cluster boundary as a distance penalty. On top of that sits a placement policy per account and per stream: prefer your own capacity, spill over only when you run out of capacity or have no coverage in a region, never use platform-official capacity, or rank marketplace capacity by effective price. A policy only takes effect in a cluster that has confirmed it enforces it. Your stream, your edge tells the full story, and the media placement docs show how to preview a policy. Storage and processing placement are not in this release.
Agents can act, with guardrails
Section titled “Agents can act, with guardrails”Skipper and MCP ship in 0.3.0 because AI agents are becoming part of how people operate streams. The useful work is diagnosis from real stream state, schema-aware API help, a billing preflight before expensive actions, confirmation before anything changes, and labels that say whether an answer came from docs, schema, metrics, or model inference. Billing changes and private-infrastructure tools now require an owner or admin identity as well as the matching API token scope, so an agent linked to a regular member account no longer sees those tools at all. The MCP docs cover connecting an agent.
What is not in 0.3.0
Section titled “What is not in 0.3.0”Chat and conferencing are next, because FrameWorks already has pieces of the real-time stack: support conversations, message lifecycle events, live subscriptions, and Skipper conversations. Conferencing still needs room state, participant identity, moderation, recording rules, pricing, and media routing built around active participants. 0.3.0 tightens the real-time and operator foundations that work depends on.
Composer stays on the roadmap. Overlays, lower thirds, server-side ad insertion, transcription, object detection, picture-in-picture, and automated clipping are among the more interesting media features we could build, and each carries a product contract: API shape, placement, lifecycle, billing meters, permissions, dashboard controls, and MCP access. It ships once those contracts are defined.
Bring-your-own-compute also gets a clearer boundary. You can run your own edge nodes with MistServer, and FrameWorks keeps running routing, federation, transcoding, storage, DNS, analytics, billing, and the control plane. There is no deeper tier where a customer runs part of that coupled stack. Teams that want all of it self-host the entire stack as an independent platform.
Operator note: self-hosted edges must be redeployed
Section titled “Operator note: self-hosted edges must be redeployed”This release raises the minimum protocol version between edges and the control plane, with no window where old and new versions work together. The control plane upgrades first. From that moment, edges on the older protocol are refused, drop out of routing, and cannot receive the automatic update that would fix them.
If you run edge nodes yourself, redeploy them with the 0.3.0 edge image after the control plane rollout. The same applies to an older edge that was offline during the rollout and comes back later: it cannot reconnect until it has been updated. This one-time interruption was a deliberate trade: an edge that cannot show it speaks the new protocol is refused rather than trusted. The upgrade guide has the redeploy command, and the self-hosted edge rollout runbook covers release order and recovery.