Cruise

Cruise is Architect's own checkpoint engine: the component that takes a checkpoint of a running container and restores it later. Every hibernation, wake, and migration goes through a checkpoint engine, and today that engine is CRIU. Cruise is the engine we are building to take its place — written in Zig and built into Architect rather than pulled in as an external dependency. For the background on why, see The Math Changed: Rewriting Stale Open Source In The AI Era and AI Took My Coding. What's Left For Me?.

Why Cruise

Checkpoint/restore is the foundation of what Architect does, so we want it to be fast, predictable, and ours to fix when it breaks. Cruise is a focused engine built specifically for the way Architect checkpoints and restores managed containers:

• Purpose-built. Cruise implements the slice of checkpoint/restore that Architect's hibernate, wake, and migration flows rely on, and leaves out the parts we don't need.
• Ours to fix. Because the engine is in-tree rather than a large external dependency, Architect can optimize the checkpoint/restore path and ship fixes on its own timeline.
• Room to grow beyond CRIU. Because the engine is ours, we can extend checkpoint/restore to cases CRIU does not handle. Support for additional capabilities, such as processes that use io_uring, is being added.
• Drop-in integration. Cruise speaks CRIU's worker RPC protocol directly, so runc drives it exactly as it drives CRIU. Nothing else in the pipeline changes when you switch engines.
• Cross-architecture. Cruise runs on both x86_64 and arm64 nodes.

As Cruise's workload coverage grows, it is intended to fully replace CRIU as Architect's default engine.

Enabling Cruise

Cruise is opt-in per pod, through the checkpoint-engine annotation:

architect.loopholelabs.io/checkpoint-engine: "cruise"

This routes checkpoint/restore for the pod's managed containers to Cruise instead of CRIU. It is a pod-global setting; unmanaged containers are never checkpointed. The default is criu.

Verified applications

Cruise is exercised against a growing set of real applications in Architect's continuous test suite, each checkpointed and restored on every change.

"Verified" here means the application checkpoints and restores in place, as in a hibernate/wake cycle on the same node. It does not imply live migration across nodes with active connections preserved, which depends on the TCP support Cruise does not yet have (see Limitations). The current coverage:

Not yet supported. A few real applications do not checkpoint/restore on Cruise yet and should stay on the default CRIU engine: Node.js 24 and MinIO.

Limitations

Cruise implements a subset of CRIU's capabilities. Some workloads that checkpoint and restore cleanly under CRIU are not yet supported, and coverage expands each release. If a checkpoint or restore is not yet supported under Cruise, switch the workload back to CRIU by removing the checkpoint-engine annotation.

Networking. Cruise's networking support is minimal. It does not currently checkpoint or restore active TCP connections, so it should not be used for live migration that relies on preserving established connections across the move (the rewrite-established-addresses-containers annotation). Workloads that depend on keeping connections alive through a checkpoint/restore should stay on CRIU.