Workload fit
Pick Apple Silicon when wall-clock or VideoToolbox matters.
Cloud containers are excellent for elastic ops. For Chromium Remotion and Mac-native encodes, our measured standard-1 shapes were much slower than a single idle Mac. Use this page to decide which workloads belong on RenderMac versus a generic container fleet.
| Workload | Best measured Mac | Best measured / projected cloud | Prefer |
|---|---|---|---|
| Remotion Light 5 s | 3.5 s M2 Max | 54.1 s CF live | Apple Silicon |
| Remotion 3 min kinetic | 111.5 s M2 Max / 134–146 s M1 | 2175 s CF live | Apple Silicon |
| Remotion 20 min kinetic | 679.5 s M2 Max | ~14502 s PROJECTED CF | Apple Silicon |
| Encode 20 min VT | 95 s M2 Max | N/A on CF Linux | Apple Silicon |
| Encode 20 min x264 | 103 s M2 Max | 2371 s Docker CF-shape | Apple Silicon for speed; containers for ops |
| Massive parallel Lambda-style fan-out | single Mac not comparable | many functions (not run here) | Distributed cloud if you need that shape |
Choose Apple Silicon when…
- You need Remotion Chromium renders without waiting on a 0.5 vCPU box.
- You need VideoToolbox or other Mac-native codec paths.
- You want organization-private pools and macOS execution parity.
Choose cloud containers when…
- Ops elasticity and region sprawl matter more than per-job wall-clock.
- The workload is pure Linux software encode with no Mac-only API.
- You are already committed to Lambda/Cloud Run style fan-out and will shard aggressively.
Honest boundary: RenderMac is not a universal GPU marketplace and does not claim to beat every cloud configuration. Quotes, service IDs, and the status page remain the operational truth.