Skip to content
Fluxx

Cloud-Side Operations

Fabrixx is the render-heavy compute layer of the Fluxx pipeline. When the camera cuts, low-res proxy plus lens / camera-tracking data uploads from Warp on set, loads into a cloud VM, and the cloud brute-forces the render passes, applies the pre-comp recipe in Nuke, and returns Near-Time PostViz back to the stage in 30 to 60 minutes at quarter resolution. Overnight, the same Fabrixx runs the full-quality pass that becomes final pixel. The capital concentrates here, not on the wall.

Fabrixx as equal pillar

Both compute layers operate in parallel with equal weight, not on-set-with-cloud-as-backup. Warp drives the LED wall on set for crew-flow only; even at lower resolutions the rendering required for an on-set proxy playblast is too complex for the on-set hardware to deliver in time without slowing the crew. Fabrixx is where the render passes actually happen. Fabrixx is just as important as the on-set compute. The capital concentrates in Fabrixx, not on the wall.

Anti-drift: do not say or imply “Fluxx doesn’t need cloud compute” or “Fluxx is on-prem-first.” Both layers are core architecture.

GPU stack

The GPU stack receives the low-res proxy transcode plus full lens and camera-tracking metadata per take from Warp, loads it into a virtual machine, brute-forces the render passes, applies the pre-comp recipe (now CompViz per Q-G56) in Nuke, and returns Near-Time PostViz to set for director review on the same shoot day. The Near-Time deliverable lands in 30 to 60 minutes at quarter resolution; the overnight brute-force pass at full quality produces final pixel.

The specific cloud provider stack (hyperscaler, specialty GPU cloud, multi-cloud) is parked per Q-G49 §7, Norman / Ari territory, likely deal-shape dependent. Fabrixx’s architecture does not lock to a single provider; cost attribution and workload routing live above the provider abstraction.

Render queue plus job orchestration

Render jobs flow through Fabrixx as workflow executions composed and dispatched by Fluxx Automate, the orchestration and workflow execution layer of the pipeline. Per-shot finish-track field, set per Q-G45 at the on-set PostViz checkpoint, decides what tier of render the shot gets: Near-Time (overnight render is the final, reopenable cleanly) or Near-Time VFX (overnight render plus slap comp, polish via Agentic Sequence Assist, comp review).

The job-queue substrate (Deadline, Tractor, Royal Render, or Fluxx-native with Conductor-style multi-cloud abstraction) is parked. Fluxx Automate composes workflows as node graphs, routes specific steps to specific bridges based on where the work needs to happen, and tracks status across the pipeline. Per Norman V7 M4 cloud platform build (FE/BE/DB split, job queue, AI QC integration) and M5 (hybrid compute orchestrator, agentic telemetry, advanced queue state management). Reference Q-G80 Fluxx Automate Orchestration Module.

Vault sync

Content-addressed Vault sync runs across cloud-VM and on-set Warp as the single asset substrate of the pipeline. Storage backend is cloud object storage, provider-agnostic at the URL layer (s3://, gs://, az://). Asset identity is a content hash, not a file-system path. Storage backend is an implementation detail behind the Storage API.

Each Fabrixx VM carries a per-VM cache layer at /fluxx/cache/, LRU eviction bounded by VM disk. The DCC inside the VM resolves Version, then Representation, then cloud object storage URL, then in-VM cache. Path templates abstract the URL scheme so DCC plugins do not hard-code the storage backend. Workfile is a Vault asset; the local file system inside the VM is scratch space.

VM provisioning lifecycle (Fluxx-native primitive)

Cloud-VM lifecycle is a Fluxx-native primitive. No incumbent pipeline manager models it; AYON’s launcher assumes a long-lived host on the artist’s laptop, not a short-lived cloud VM. Fluxx owns the lifecycle end-to-end inside the pipeline service.

Six lifecycle events:

  • vm.provision_requested
  • vm.provisioned
  • vm.session_started
  • vm.context_changed
  • vm.teardown_requested
  • vm.teardown

The pipeline service owns provisioning. The VM image is baked at provision time with the DCC binary, the fluxxd daemon, the addon set per the active bundle, and the environment variables (FLUXX_SERVER_URL, FLUXX_API_KEY, FLUXX_BUNDLE_NAME, FLUXX_HEADLESS_MODE for farm workers). Bundles work per-tenant: a JV licensee can pin their own production bundle while the main Fluxx Cloud cluster runs a different version.

Plugin hooks fire on the lifecycle events. on_vm_provisioned pre-warms scene data, populates the per-VM cache, and registers the session with the pipeline service. on_vm_teardown flushes session state, emits final events, and releases locks. DCC runs inside the VM; the artist remotes in via PCoIP or NICE DCV topology, intra-VPC with the pipeline service. Headless / farm mode shares the code path: a render-worker VM runs the same plugin set as an artist VM with no GUI, context entry via job spec rather than user action.

Artist Virtual Workstation

The Virtual Workstation is the artist-facing surface on top of the VM provisioning lifecycle. A VFX vendor or external artist remotes into a per-session cloud VM that the pipeline service provisioned, baked with the rendering and comp toolchain (Nuke for comp; rendering engine direction parked per Q-G49) plus the fluxxd daemon and the active addon bundle. From the artist’s seat the workstation feels like a workstation; underneath, it’s the short-lived VM described in the lifecycle section above with PCoIP or NICE DCV remote-in topology, intra-VPC with the pipeline service.

The workstation lives inside Fabrixx (the cloud product-surface naming is resolved — Fabrixx, no discrete sub-brand, per Q-G66 S141 lock + Q-G91 §3). That environment bundles the Vault Cloud Mirror (the cloud-resident node of the content-addressed Vault), the VFX Render Scene, and real-time metadata from the take (camera tracking plus lens data plus Near-Time script) into one working surface the artist sees through their session.

Inputs the workstation consumes: the VFX Render Scene resolved from the Vault Cloud Mirror through the Storage API (URL, not path), real-time metadata per take, and the per-shot Pre-Light artifacts (virtual set approvals, pre-comp approvals, Near-Time auto-assembly script) the pre-light cascade aligns into the shoot week per Q-G90. Outputs the workstation emits: Creative Changes and Shot Polish that the artist re-submits to the cloud render platform on the Near-Time VFX finish track. Director creative feedback consumes both the Near-Time auto-assembly output (same-shoot-day, quarter resolution) and the Final Creative Review output (overnight, full quality, post-polish), then either routes further changes back into the workstation or releases the shot to Final Delivery.

How the workstation slots into the finish tracks per Q-G45: Near-Time shots run the cloud render platform against the VFX Render Scene plus current metadata, hit Near-Time Review auto-assembly inside 30 to 60 minutes at quarter resolution, and reopen cleanly into the overnight full-quality pass. Near-Time VFX shots take the same Near-Time path then add the Shot Polish iteration in the workstation, where the artist applies Creative Changes against the overnight pass, re-submits to the cloud render platform, and gates Final Delivery through Final Creative Review.

Vendor isolation: each VFX vendor or external artist operates inside their tenant’s namespace per the multi-tenant boundary below. The Vault Cloud Mirror they see is scoped to their production; the render queue they submit into is scoped to their tenant; the cost ledger lines their workstation generates attribute to their (tenant, production, shot, finish-track) tuple at job-completion time.

Anti-drift: Fluxx is not a VFX studio. Fluxx is the pipeline that VFX vendors and external artists operate inside. The Artist Virtual Workstation is the surface on which those external actors do VFX work; Fluxx provides the substrate (compute, vault, render orchestration, automation), not the labor. Never describe Fluxx-the-company as “a studio,” and never describe Fluxx Cloud surfaces with names that imply Fluxx is one. Diagram 04’s “Fluxx Virtual VFX Studio” label is the trigger for this anti-drift and is queued for revision; see Q-G91 Open §3.

Multi-tenant isolation

Multi-tenant from day one. Tenant scope appears at every entity, every event, every cost ledger entry. A production or a JV licensee is a tenant with a stable ID, an isolation boundary, and an attribution scope. Storage isolation is per-tenant namespace at the bucket / prefix tier, enforced at the storage IAM layer. Cloud VMs are tagged with tenant ID at provision time; the job scheduler enforces tenant boundaries at queue and worker assignment.

VPC topology is an open call: per-tenant VPC (strong isolation, higher infra cost, slower provisioning) versus shared VPC with tenant tagging (cheaper, faster, weaker isolation surface). v0.1 default is shared VPC with tenant tagging plus IAM enforcement, with an upgrade path to per-tenant VPC for high-security tenants. TPN audit is required for any Sony, A24, or Netflix tier production.

Per-tenant cost attribution

Per-shot, per-finish-track, per-tenant cost attribution is a Fluxx-native layer above whichever job-queue substrate ships. Render-farm managers (Deadline, Tractor, Royal Render) track worker utilization; none of them ship per-shot dollar cost. Fluxx layers attribution on top.

cost.attributable_event events fire from render, load, and agent invocation. Every VM provision is a billable event in Fluxx Cloud. Per-VM-hour plus per-render-job cost attributes to a (tenant, production, shot, finish-track) tuple at job-completion time. Vault holds the attribution ledger; ftrack consumes it for resource-cost reporting through the leecher / processor / transmitter integration.

What’s different from incumbent pipelines

AYON’s launcher assumes a long-lived host on the artist’s box; Fluxx owns the short-lived VM lifecycle inside the pipeline service. AYON’s load paths resolve file-system paths through inherited OpenPype path templates; Fluxx resolves cloud object storage URLs through Vault’s content-addressed Storage API. Render-farm managers (Deadline, Tractor, Royal Render, Qube!) track worker utilization without per-shot dollar accounting; Fluxx layers per-shot, per-finish-track, per-tenant cost attribution above. Multi-tenancy in incumbent stacks is run-multiple-instances; Fluxx Cloud is tenant-scoped at every entity, every event, every ledger entry, from v0.1.

Cross-references

Sources

  • 02_Working/Strategy/Company_Overview/Compute_Architecture_Source_2026_05_03.md
  • 02_Working/Strategy/Company_Overview/Automation_System_Source_2026_05_14.md
  • 02_Working/Pipeline_Research/AYON_Architecture_Deep_Dive.md
  • 02_Working/Pipeline_Research/Fluxx_Pipeline_Architecture_v0.1.md
  • _Inbox/FluxxVP_Workflow_Diagram04.pdf (Diagram 04: Near-Time VFX Workflow, source for the Artist Virtual Workstation section)

Audience visibility

industry, vendor, investor, counsel.