StateBridge preview

Type: Preview guide · Audience: Pipeline TDs and automation builders

Current StateBridge access is restricted to a hosted-only, default-off checkpoint-and-restore preview for narrowly compatible Azure render jobs. A proprietary standalone product is planned, but there is no customer-downloadable checkpoint engine or released public standalone API. StateBridge is not available through DCC plugins and has no recovery-time SLA. A compatible request can still be unavailable when its fleet is disabled or not fully configured.

Evidence and limits

Status — September 28, 2026: the next milestone is internal qualification of the standalone StateBridge engine, first CPU and then GPU, using KinoCloud-owned or synthetic data. Controller-readiness software has landed with required CI passing, but it is not a commissioned service or a customer release.

The qualification protocol has been strengthened so that a genuine Azure Spot eviction is the event under test, not a reason to abandon the test:

• an eviction that Azure itself records during a cell that is not testing eviction voids that cell, which is then repeated from scratch;
• the eviction cell keeps rendering the identical frame until Azure evicts the machine or a pre-registered time limit is reached.

Every such attempt is disclosed. The new complete qualification campaign has not run. Security review, approved infrastructure changes, commissioning and an independently verified preparation window come before the separately approved CPU and GPU campaigns. Earlier successful migration tests remain valid within their stated limits.

Passing engine qualification must be followed by separate KinoCloud and Molecule Studio integrations, client acceptance, and production/distribution approvals. Neither software tests nor a merged change automatically grant customer access.

• CUDA: historical same-host recovery on a real NVIDIA T4 passed 10/10. A September 25, 2026 mechanical drill also passed cross-node continuity onto a different physical T4 and passed one calibrated Blender comparison within tolerance.
• CPU: a September 25, 2026 mechanical drill passed cross-node continuity; separate drills exercised pre-copy convergence and block-delta reuse.
• Relay: authenticated transfer, immutable storage, safe retry, and stale timestamp rejection passed live checks. Exact-frame replay protection is covered in CI but has not yet been exercised over a deployed wire connection.
• These are controlled harness results. They do not prove the hosted product worker path, survival of an observed Azure Spot eviction, broad workload compatibility, or an SLA.
• StateBridge is not production-ready or generally available.

How to read the test language

• PASS / FAILED: a cell met every criterion, or broke one. Criteria include exact output (within 0.0005 per channel for Blender), verified continuity, and on-time cleanup as recorded by Azure. A FAILED result stops the campaign.

• VOID: Azure evicted the Spot machine during a cell that was not testing eviction. The cell is repeated from scratch, at most three times per campaign, and the VOID stays in the report. It is never counted as a pass.

• INCONCLUSIVE: no Azure-verified eviction happened within the pre-registered limit. This is neither a pass nor a failure, and the campaign closes without a qualification claim.

• A conflicting write was refused: good. The relay stopped an attempted overwrite and kept the original checkpoint unchanged.

• A stale authenticated frame was rejected: good. An old request could not write anything after its allowed time window.

• Replay was NOT_EXERCISABLE_OVER_WIRE: incomplete live proof, not a failure and not a live pass. The protection exists and passed code-level CI, but the current client cannot resend the exact malicious frame needed for the deployed test.

• 12.24% block reuse: the target still receives enough reused and newly sent bytes to reconstruct 100% of the checkpoint. This measures potential transfer savings; product-level base selection, reconstruction, restore, and safe fallback still need end-to-end proof.

• Dirty-to-ship ratio: below 1 means transfer can catch up with changing memory. At or above 1 it cannot, so the eventual product must switch to a bounded fallback instead of looping. Native-sample verification rejects observed backwards progress and lost history; sparse logs do not prove exactly-once execution of every internal operation.

• Blender passed within tolerance: the tested image was extremely close but not byte-identical. This is encouraging evidence for one scene, not a general guarantee for architecture, color-critical work, every renderer, or every output format. Broader scenes, the real color pipeline, perceptual checks, and a strict exact-output policy remain required.

Before availability, KinoCloud must also prove immutable workload artifacts, the full hosted product path, an observed real Spot eviction, repeatability, production security and cleanup, workload-specific acceptance policies, and measured customer-visible recovery objectives. Delta-transfer savings and low-pause claims require their own reconstruction/fallback and pre-copy evidence; they must remain disabled or unclaimed until qualified, not inferred from the first working engine campaign.

Check compatibility first

Always call compatibility before estimating, uploading, or submitting. Preserve the selected backend in the estimate and submit requests.

1. POST /api/v1/statebridge/compatibility
2. POST /api/v1/jobs/estimate
3. Upload and finalize the scene file.
4. POST /api/v1/jobs/submit
5. Poll GET /api/v1/jobs/{id}/migration.

The compatibility endpoint accepts a strict object. A CPU request looks like:

{
  "backend": "criu-cpu",
  "computeClass": "cpu",
  "jobType": "render",
  "renderHost": "blender",
  "provider": "azure",
  "operatingSystem": "linux",
  "gpuCount": 0,
  "cpuSku": "Standard_D8s_v5",
  "multiNode": false,
  "topology": "single-node",
  "recovery": {
    "mode": "uninterruptible",
    "checkpointIntervalSeconds": 300
  }
}

Use the deployed SKU, not the example value. For CUDA, use criu-cuda, computeClass: "gpu", gpuCount: 1, and the configured T4 gpuSku.

Use this canonical recovery object in both the estimate and submit bodies:

{
  "recovery": {
    "mode": "uninterruptible",
    "backend": "criu-cuda",
    "checkpointIntervalSeconds": 300
  }
}

For the CPU route, change backend to criu-cpu. The checkpoint interval must be an integer from 60 through 3600 seconds.

Compatibility requirements

CPU (criu-cpu)

• KinoCloud-managed Azure, Linux, Blender render, single node, and zero GPUs.
• The requested CPU SKU must exactly match the configured source SKU, and the source and receiver VM SKUs must match each other.
• The CPU fleet and render-job allowlist must be enabled.
• Cross-node CPU continuity has controlled-harness evidence, but no CPU hardware configuration has completed product qualification.

CUDA (criu-cuda)

• KinoCloud-managed Azure, Linux render, single node, and exactly one GPU.
• The requested GPU SKU must exactly match the configured source pool's validated NVIDIA T4 SKU.
• The CUDA fleet and render-job allowlist must be enabled.
• Multi-GPU, multi-node/NCCL, Windows, CPU workloads on the CUDA profile, and unvalidated GPU families are rejected.

Public REST operations

Operation	Endpoint	Scope
Check compatibility	POST /api/v1/statebridge/compatibility	jobs:read
Read migration timeline	GET /api/v1/jobs/{id}/migration	jobs:read
Queue a manual checkpoint	POST /api/v1/jobs/{id}/checkpoint	jobs:write
Queue a restore	POST /api/v1/jobs/{id}/restore	jobs:write
List retained checkpoints	GET /api/v1/jobs/{id}/checkpoints	jobs:read
Queue checkpoint deletion	DELETE /api/v1/jobs/{id}/checkpoints/{checkpointId}	jobs:write

Checkpoint, restore, and deletion requests require an Idempotency-Key. For restore, supply a checkpoint UUID in checkpointId, or use { "checkpoint": "latest" }; only an available, integrity-verified checkpoint can be restored. These operations use the job's stored backend; clients cannot switch an existing CPU job to CUDA or vice versa. Checkpoint creation requires that backend's fleet to be enabled. Restore and deletion require its runtime profile to remain configured, plus their operation-specific ownership/lifecycle checks; restores also enforce funding and recovery conditions. They do not require an unrelated CUDA fleet. Endpoint existence does not establish customer availability.

CLI and MCP

The KinoCloud CLI exposes compatibility, migration, checkpoint, restore, snapshot and doctor commands. Both kino statebridge doctor and uninterruptible submission require an explicit backend. There is no implicit CPU or CUDA default.

kino statebridge doctor --backend cpu
kino statebridge doctor --backend gpu
kino submit scene.blend --software blender --frames 1-1 --recovery uninterruptible --backend cpu --estimate-only
kino submit scene.blend --software blender --frames 1-1 --recovery uninterruptible --backend gpu --estimate-only

These are hosted API contract examples for authorized preview users, not an invitation to enable a disabled fleet. --estimate-only does not upload or submit a workload. Standard and resumable submissions reject --backend.

Cloud MCP tools for compatibility, quote, and submission accept backend: "cpu" or backend: "gpu" and route to criu-cpu or criu-cuda. Query tools/list for the current catalogue. The MCP server controls the hosted KinoCloud API; it does not make StateBridge self-hosted.

What must happen before launch

1. Complete review, CI and commissioning of the corrected engine release.
2. Qualify CPU and GPU separately on the same frozen release and fixtures. A campaign without a qualifying real eviction is inconclusive, not a pass.
3. Accept both application integrations and their documented API, CLI and MCP flows.
4. Complete the supported-workload matrix, security/privacy and distribution approvals, operational/support policy and an explicit external-launch decision.

There is no committed launch date. Broader GPU families, arbitrary workloads and multicloud/BYOC remain separate qualification work, not implied capabilities.

Status names

• Job: SUBMITTING, SUBMITTED, PENDING, RUNNING, PAUSED, MIGRATING, RESTORING, SUCCEEDED, COMPLETED, FAILED, CANCELLED, CANCELED, or UNKNOWN; both success spellings and both cancellation spellings are terminal
• Migration: not_applicable, running, checkpoint_healthy, eviction_detected, capturing_final, checkpoint_stored, capacity_requested, restoring, resumed, failed, cancelled
• Operation: queued, claimed, running, succeeded, failed, cancelled
• Checkpoint: creating, available, restoring, expired, deleted, failed; integrity is pending, verified, or failed