Use case · Rendering
Operate render workers as managed processes, not manual screen sessions
Sysaro links an exact Node.js LTS runtime, FFmpeg/FFprobe, a Remotion worker, systemd/cgroups and S3-compatible storage.
Verified against public version: 0.20.02026-09-15Factual boundary · roadmap is not presented as shipped
A Remotion worker is created through a Managed Process preset and can bind to an exact inventoried Node.js runtime. FFmpeg/FFprobe are checked as a pair, while input/output storage can use an S3-compatible endpoint.
Render pipeline
1
Runtime
Node.js LTS exact binding
2
Media tools
FFmpeg + FFprobe completeness
3
Worker
systemd supervision + cgroup limits
4
Storage
local MinIO or external S3-compatible endpoint
Operational guarantees
| Area | Current boundary |
|---|---|
| Runtime | Executable is pinned server-side when a managed runtime is selected |
| Worker | Known unit/process model instead of hidden shell loops |
| Storage | Agent-side SigV4 health check; external endpoints require HTTPS |
| Readiness | Service Fleet shows component state rather than one opaque “rendering” switch |
Application boundary
Sysaro does not inject a universal render script: the entrypoint stays an explicit part of the application.
That keeps worker infrastructure management separate from Remotion composition logic.