Host
Apple M2 Max, 96 GB RAM, 12 logical host CPUs, macOS 26.5.1.
Virtualization bakeoff · measured 2026-07-25
Apple’s new Container machine is fast to start. Native macOS is still far faster to render.
On an M2 Max, Apple’s WWDC26 Container machine was the quickest of three Linux virtualization paths. Its median HeavyMotion render took 95.018 seconds—3.09× the native macOS time of 30.753 seconds.
The decision in one paragraph
Use Container machine for persistent Linux development environments and compatibility work. For RenderMac’s Remotion and FFmpeg services, keep the fixed execution path native on macOS: it retains Apple’s media stack and avoided a roughly threefold render-time penalty in this test.
3.09×Container-machine HeavyMotion time vs native
Median render time
Lower is better. Each number is the median of three measured renders after one uncounted warm-up. All outputs were nonempty MP4 files.
| Runtime | Execution model | Light 150 frames | Medium 300 frames | Heavy 450 frames | Heavy vs native |
|---|---|---|---|---|---|
| Native macOS | Direct host process | 3.480 | 7.072 | 30.753 | 1.00× |
| Colima Docker / VZ | Container in persistent VZ VM | 11.152 | 22.303 | 97.668 | 3.18× |
Apple container run | One lightweight VM per container | 10.864 | 22.410 | 98.168 | 3.19× |
| Apple Container machine | Persistent lightweight VM | 10.094 | 21.882 | 95.018 | 3.09× |
HeavyMotion · 450 frames
Linux-only reading: Container machine’s HeavyMotion median was 2.7% faster than Colima VZ and 3.2% faster than Apple’s per-container VM. That is a real but modest difference beside the native-versus-Linux gap.
Every measured trial
These are the individual wall-clock readings behind the medians. Times are seconds; σ is sample standard deviation.
| Runtime | Composition | Run 1 | Run 2 | Run 3 | Median | Mean | σ |
|---|---|---|---|---|---|---|---|
| Native macOS | |||||||
| Native | LightMotion | 3.397 | 3.518 | 3.480 | 3.480 | 3.465 | 0.062 |
| Native | MediumMotion | 7.072 | 7.066 | 8.162 | 7.072 | 7.433 | 0.631 |
| Native | HeavyMotion | 30.753 | 31.758 | 30.743 | 30.753 | 31.084 | 0.583 |
| Colima Docker / Virtualization.framework | |||||||
| Colima VZ | LightMotion | 11.134 | 11.152 | 11.208 | 11.152 | 11.164 | 0.039 |
| Colima VZ | MediumMotion | 22.470 | 22.303 | 22.277 | 22.303 | 22.350 | 0.105 |
| Colima VZ | HeavyMotion | 97.668 | 96.891 | 99.316 | 97.668 | 97.958 | 1.239 |
Apple container run | |||||||
| Apple container | LightMotion | 10.711 | 11.047 | 10.864 | 10.864 | 10.874 | 0.168 |
| Apple container | MediumMotion | 22.301 | 23.065 | 22.410 | 22.410 | 22.592 | 0.413 |
| Apple container | HeavyMotion | 99.055 | 98.168 | 98.124 | 98.168 | 98.449 | 0.525 |
| Apple WWDC26 Container machine | |||||||
| Container machine | LightMotion | 11.527 | 10.094 | 9.825 | 10.094 | 10.482 | 0.915 |
| Container machine | MediumMotion | 22.781 | 21.833 | 21.882 | 21.882 | 22.166 | 0.534 |
| Container machine | HeavyMotion | 97.644 | 94.575 | 95.018 | 95.018 | 95.746 | 1.659 |
Startup and suite overhead
The new persistent machine starts quickly. For these 30–100 second render jobs, the render path still dominated end-to-end time.
| Runtime | Bundle | Warm-up | Measured suite | Outer wall | Launch overhead | Cold restart |
|---|---|---|---|---|---|---|
| Native macOS | 0.565 | 3.473 | 131.368 | 131.603 | 0.235 | — |
| Colima VZ | 2.655 | 11.189 | 409.316 | 409.687 | 0.371 | — |
| Apple container | 2.097 | 10.638 | 409.544 | 410.839 | 1.295 | — |
| Container machine | 2.207 | 11.003 | 399.407 | 399.762 | 0.355 | 0.728 |
Container machine’s first local image create-and-boot took 1.179 seconds. “Launch overhead” is outer process wall-clock minus the suite’s own timer; the Colima and Container-machine VM were already running for that measurement.
Test design and controls
Linux allocation
4 vCPUs, 8 GB RAM. Colima used VZ and VirtioFS. Apple container was 1.1.0.
Render workload
Remotion 4.0.381, 1920×1080, 30 fps; Light 150, Medium 300, Heavy 450 frames.
Run policy
Concurrency fixed at 4. One uncounted LightMotion warm-up, then three iterations per composition.
Linux image
One shared ARM64 Debian/Chromium OCI image across all three virtualized paths.
Validation
Each command had to complete and produce a nonempty MP4. Bundle output was reused within each runtime.
What is—and is not—held constant?
All runtimes used the same Remotion project, composition settings, explicit concurrency, trial count, and logical Linux resource allocation. Native macOS necessarily used Remotion’s macOS browser build, while Linux used Debian Chromium. Native-versus-Linux therefore measures the combined OS, browser, and VM execution path. The three Linux rows are the cleaner runtime-to-runtime comparison.
What did Apple announce?
Apple introduced Container machine at WWDC26 as a persistent Linux environment based on an OCI image and a lightweight VM. It is distinct from container run, where each Linux application container gets its own lightweight VM. Apple publishes the Container machine documentation in the open-source container project.
Media acceleration probe
The guest did not expose the Mac’s media encoders
Host FFmpeg advertised h264_videotoolbox, hevc_videotoolbox, and prores_videotoolbox. The identical Linux image under all three virtualized paths advertised no VideoToolbox encoders and had no /dev/dri device.
0VideoToolbox encoders visible in the tested Linux guests
This is a measured capability result for this configuration, not a claim about every future Containerization or Virtualization.framework API.
Limits and interpretation
- This is one M2 Max, one day, and three sequential iterations per cell—not a randomized lab study.
- The Mac was an active development machine and the trials were not temperature-controlled.
- Native macOS exposed 12 logical CPUs, but render concurrency was fixed at 4. Every Linux runtime received a four-CPU quota and 8 GB.
- Apple’s per-container guest reported five visible processors while its cgroup quota was four CPUs.
- Completion and nonempty files were checked. Visual quality, bit-exact output conformance, wall-outlet power, and long-run thermal behavior were outside this pass.
- Different macOS and Linux Chromium builds produced different output byte counts. Treat timing as the primary result and inspect the raw files before making output-conformance claims.
Claim boundary: this result supports “native macOS was roughly three times faster than these three four-vCPU Linux paths for this Remotion suite.” It does not support “native beats every VM, container, cloud size, or distributed render system.”
Raw data and reproduction
The summary contains host metadata, every measurement, output byte counts, derived medians, means, ranges, standard deviations, and native slowdown ratios. The per-runtime files are smaller downloads of the original emitted results.
Complete summary JSONAll runtimes + derived statistics
Native macOS JSONWarm-up + 9 measured renders
Colima VZ JSONDocker in persistent VZ VM
Apple container JSONPer-container lightweight VM
Container machine JSONPersistent lightweight VM
Reproduction commands
./research/apple-silicon-idle-render-network/benchmarks/prepare_virtualization_benchmark_image.sh
python3 research/apple-silicon-idle-render-network/benchmarks/run_virtualization_render_benchmark.py \
--iterations 3 \
--compositions LightMotion,MediumMotion,HeavyMotionThe repository also retains the raw logs and human-readable report under research/apple-silicon-idle-render-network/benchmarks/results/virtualization-full-2026-07-25/.