Skip to content
Fluxx

AYON Port / Reject

AYON is the most architecturally relevant open-source pipeline framework in production VFX today. Fluxx treats AYON as a blueprint reference: port the patterns that solve the right problems, reject the patterns that solve the wrong problems. AYON is not a dependency. No AYON code ships in Fluxx.

The Port catalogue lists architectural patterns Fluxx adopts as reference and reimplements Fluxx-native. The Reject catalogue lists patterns Fluxx explicitly does not adopt because they are incompatible with the Fluxx-native primitives (cloud-VM, content-addressed Vault, multi-tenant, pipeline-owned VM lifecycle).

Why AYON specifically (not ShotGrid, not ftrack). ShotGrid is proprietary, Autodesk-controlled, walled docs post-Flow rebrand. ftrack is the integration substrate Fluxx talks to (Q-G15) and informs reference design only. AYON is Fair Source, server-first, has the cleanest plugin SDK in the category, and has explicit documentation of what its predecessor OpenPype got wrong. Reading AYON cold tells you the most about what a working production-pipeline framework looks like in 2026.

Port (patterns Fluxx adopts as reference)

Plugin and addon shape

  • package.py manifest. Single-file Python declarative manifest at addon repo root. Fields: name, title, version, client_dir, services, ayon_server_version, ayon_required_addons. Cleanest pipeline-addon manifest format in the category. Fluxx renames to fluxx_plugin.py; same field shape with fluxx_pipeline_version and fluxx_required_plugins.
  • Four-folder addon directory layout. server/, client/, frontend/, services/ plus public/, private/, create_package.py, package.py. Each layer has a distinct deployment story. Fluxx adopts identically; pipeline/ may rename server/ to reflect that the receiver is the pipeline service.
  • Plugin path taxonomy. actions, create, load, publish, inventory as the structural decomposition of pipeline plugin categories. Fluxx adopts the five and extends with four Fluxx-native: provenance, track-assign, stage, cost-attribution. See Plugin SDK for the full taxonomy.
  • BaseServerAddon + AYONAddon class pattern. Server-side and client-side base classes with interface markers (IPluginPaths, IHostAddon, ITrayAddon) declaring capabilities. Single initialize(settings) entry point. Fluxx renames to BaseFluxxPipelinePlugin plus FluxxPlugin; adds IProvenancePlugin, ITrackAssignPlugin, IStagePlugin.

Configuration and settings

  • Pydantic-with-scope settings. BaseSettingsModel plus SettingsField with four scopes (studio, project, site, studio-site). Right tri-tier inheritance for production-management surfaces. Fluxx extends to six scopes by adding tenant and production.

Distribution and versioning

  • Bundle abstraction. A bundle is (launcher version + dependency packages + pinned addon set), with three modes (Production / Staging / Development). Only one bundle per mode active at a time. Solves version pinning and dev/staging/production discipline simultaneously. Cleanest plugin-distribution model in the category. Fluxx adopts and extends with per-tenant bundles for Fluxx Cloud.
  • Public/private static-content distribution. Server-served /addons/<name>/<version>/public/<path> (no auth) and /private/<path> (auth-required); the server is the distribution mechanism for client code. Artist does not pip-install plugins. Fluxx adopts; in Fluxx Cloud the equivalent is VM image baking the addon set at provision time.
  • Custom event handler archives. .zip or .tar with manifest.json for third-party extensibility without modifying core services. Fluxx adopts the extension-point pattern; refactors for container-based services.

Event spine

  • Event spine split. Persistent events (DB-stored, state machine pending → in_progress → finished/failed/aborted/restarted, depends_on chaining for genealogy) versus fire-and-forget WebSocket events (ephemeral UI notifications). Producers emit via REST endpoints or addon-emit; consumers subscribe via WebSocket (clients) or enroll-endpoint polling (services). Fluxx adopts verbatim and adds tenant scoping at every event.
  • Leecher / processor / transmitter pattern. Three-service decomposition per tracker integration. Leecher listens to tracker events and stores them in the DB durably. Processor consumes the event log sequentially, applies reconciliation. Transmitter listens to AYON-side events and propagates back to tracker. The pattern is the AYON-specific innovation worth understanding cold. Tracker-agnostic at the contract level. Fluxx ports verbatim for ftrack now, Kitsu later.

Runtime and deployment

  • Services-as-Docker-containers. Long-running integration workers Dockerized, distributed via image registries. Fluxx adopts; deploys to the pipeline service’s container cluster rather than AYON Service Host.
  • Headless mode via env-var flag. AYON_HEADLESS_MODE suppresses UI; same code path runs in render workers. Fluxx adopts verbatim as FLUXX_HEADLESS_MODE.
  • Launcher bootstrap via env vars. Standardized convention (AYON_SERVER_URL, AYON_API_KEY, AYON_BUNDLE_NAME, etc.) plus DCC startup Python-userpath discovery. Fluxx adopts the env-var convention but replaces the desktop launcher with the in-VM fluxxd daemon, image-baked at provision time.

Publish discipline

  • Pyblish-style publish (validate / extract / integrate). Three-stage discipline, priority-ordered plugin discovery, halt-on-validation-failure semantics. Fluxx adopts; the integrate step writes to Vault (content-addressed, provenance-attached) rather than file system.

Reject (patterns Fluxx does not adopt)

Substrate mismatches

  • LAN-and-file-system substrate. AYON assumes the DCC runs where the artist is, talking to a self-hosted AYON Server over LAN, with file system asset paths. AYON’s load plugins resolve Version → Representation → file path via path templates (an OpenPype inheritance). This breaks in cloud-VM + S3 + multi-tenant targets: making the file path an S3 URL would require rewriting every DCC plugin. Fluxx instead resolves Version → Representation → cloud object storage URL (provider-agnostic: s3://, gs://, az://) → in-VM cache → DCC load. Vault translates the storage URL; the DCC plugin sees a local cache path.
  • Self-hosted-with-LAN-DCC default deployment. AYON, OpenPype, Prism all default to this. Fluxx Cloud defaults to cloud-VM + intra-VPC pipeline service + cloud-object-storage. The substrate is the architectural decision.
  • USD-aware (not native) entity model. AYON treats USD as one possible Representation format alongside Alembic, bgeo, etc. No native USD scene-graph substrate. Fluxx may go USD-native at the Vault tier (decision open per Fluxx_Pipeline_Architecture_v0.1.md §10); not constrained by porting from AYON.

Tenancy

  • Single-tenant data model. AYON is one deployment per studio; multi-tenancy is “run multiple AYON instances.” No addon-mediated tenant isolation pattern to port. The event spine doesn’t carry tenant tags. Fluxx instead is multi-tenant by design from v0.1, with tenant scope at every entity, every event, every cost ledger entry. Adding tenancy later means refactoring every subscriber; adding from v0.1 keeps the schema invariant.

Lifecycle

  • No VM lifecycle integration. AYON has no analog because it assumes a long-lived host. The launcher does not provision VMs. There is no addon-side hook for “VM is about to be provisioned” or “VM is about to be torn down.” Fluxx instead has the pipeline service own VM provisioning plus teardown and emit lifecycle events (vm.provision_requested, vm.provisioned, vm.session_started, vm.context_changed, vm.teardown_requested, vm.teardown). Plugins react via on_vm_provisioned and on_vm_teardown hooks.
  • Local-launcher distribution. AYON Launcher is a standalone desktop app; bundle update happens via in-session pull from the launcher. Fluxx instead distributes via VM image baking at provision time; the launcher equivalent is fluxxd, a small in-VM daemon. Cost-attribution at the VM-hour tier requires pipeline-service ownership of provisioning, which a user-side launcher cannot do.

Cost attribution and orchestration

  • Worker-pool-only render orchestration. Deadline, Tractor, Royal Render model worker-pool utilization but not per-shot cost attribution. Fluxx adds the attribution layer above for multi-tenant JV economics. Per-shot, per-finish-track, per-tenant cost attribution is layered above whichever job-queue substrate ships.

Review and dailies

  • Next-day dailies topology. Flow Capture, Moxion, and the traditional dailies tool category assume overnight cut → director-and-DP-review-tomorrow. Fluxx’s on-set Near-Time PostViz moves review to the same shoot day before strike. The traditional dailies tool category is structurally obsolete for Fluxx productions. The camera-to-cloud ingest pattern is fine; the destination is the Vault, not Frame.io.

AI provenance

  • AI provenance as a separate vertical product. LoftApp positions provenance as a standalone SaaS. Fluxx absorbs the same field set inside Vault as the system of record. Port the schema fields (prompt, seed, model, model_version, LoRA, generation_timestamp, generation_tool, parent_asset_id) plus C2PA pass-through; reject the standalone-product framing.

Substrate ownership

  • NVIDIA Omniverse Nucleus as runtime substrate. Omniverse is the closest deployment-topology reference (cloud VMs with DCCs inside), but Nucleus is NVIDIA-owned and binds the production to NVIDIA’s USD opinions and roadmap. Port the topology, reject the substrate. Vault is Fluxx-owned; no third-party at the core of the stack.
  • TACTIC-style bundling of tracker plus asset management. Query and concurrency patterns diverge sharply at scale. Fluxx splits the two systems (ftrack for tracking integration substrate, Vault for asset management).

Architectural lock

No third-party at the core of the stack. AYON is blueprint reference only. ftrack is reference design only (Q-G15 integration substrate; Fluxx Automate replaces ftrack at the runtime layer in production tracking). Production tracking is built in-house under Fluxx Automate (Cat 3, see Build Categories).

Source dependencies

  • 02_Working/Pipeline_Research/Fluxx_Pipeline_Architecture_v0.1.md (Port and Reject catalogue source)
  • 02_Working/Pipeline_Research/AYON_Architecture_Deep_Dive.md (640-line centerpiece, the primary AYON reference)
  • 02_Working/Pipeline_Research/sources/ayon_server.md, ayon_core.md, ayon_tracker_addons.md, ayon_cloud_community_adoption.md, openpype_to_ayon_evolution.md (Phase 1 sub-agent stubs; superseded by the Deep Dive)

Synthesis gaps

The following items the AYON research package flagged as unresolved or not extracted:

  • Per-DCC integration framework depth (ayon-maya, ayon-nuke, ayon-houdini, ayon-unreal addon-internal architecture)
  • OpenPype → AYON migration mechanics (GAP)
  • Fair Source license terms (GAP)
  • Community health quant (community.ynput.io) (GAP)
  • Path-template system depth (OpenPype inheritance) (GAP)
  • AYON Planner architecture (Feb 2026) (GAP)
  • AWS Deadline Cloud integration depth (GAP)
  • Hot-reload posture (undocumented; known weak spot for OpenPype-lineage tools generally)
  • Event topic catalogue (specific topics that fire: workfile.open, publish.start, etc.) (not extracted)
  • USD support depth (Hydra delegate, composition arc round-tripping, Solaris-aware) (GAP)

Audience visibility

industry, vendor, counsel, investor.