Remotion workers as reproducible workloads, not hidden universal render scripts
Sysaro provides a Managed Process template and verifies infrastructure prerequisites while keeping the application-specific worker entrypoint as explicit project code. The render logic stays owned by the application.
How the service fits into Sysaro
Runtime and executable
When a managed Node runtime is selected, the executable comes from inventoried runtime state and cannot be replaced manually in the request.
Service Catalog explicitly verifies Node LTS status instead of accepting any installed Node version.
FFmpeg and FFprobe are treated as one prerequisite set; ffmpeg alone is reported as an incomplete installation.
The worker stays application code
The process template proposes scripts/remotion-worker.mjs as an explicit application entrypoint.
Sysaro does not generate hidden universal rendering business logic: queue semantics, composition and storage contracts belong to the project.
That keeps deployments auditable and prevents the infrastructure panel from absorbing application code.
How the render stack fits together
Managed Process/systemd fits a persistent worker on a server; backend-aware Service Fleet can also discover a canonical OCI workload.
S3-compatible storage provides a separate boundary for input/output artifacts and can be external production S3 or local MinIO.
Stack readiness treats Node.js, FFmpeg/FFprobe, the worker and OCI runtime as connected operational prerequisites.
What this page does not claim
Detection, lifecycle or a typed subset is not described as complete management of every upstream capability. The canonical current scope is also published in service-evidence.json and the 18-service catalog.