Remotion worker как воспроизводимый workload, а не скрытый универсальный render script
Sysaro даёт шаблон Managed Process и проверяет инфраструктурные prerequisites, но оставляет application-specific worker entrypoint явной частью проекта. Это сохраняет контроль над кодом рендера у приложения.
Как сервис встроен в Sysaro
Runtime и executable
При выборе managed Node runtime executable берётся из инвентаризированной среды и не может быть подменён вручную в request.
Service Catalog отдельно проверяет, что Node является LTS, а не просто любой установленной версией.
FFmpeg + FFprobe считаются комплектом: наличие одного ffmpeg не выдаётся за готовый media toolchain.
Worker остаётся частью приложения
Шаблон процесса предлагает scripts/remotion-worker.mjs как явный application entrypoint.
Sysaro не генерирует скрытую универсальную бизнес-логику рендера: queue semantics, composition и storage contract принадлежат проекту.
Это облегчает аудит deployment и не смешивает инфраструктурную панель с кодом приложения.
Как складывается render stack
Managed Process/systemd подходит для постоянного worker на сервере; backend-aware Service Fleet также распознаёт канонический OCI workload.
S3-compatible storage даёт отдельный boundary для входных/выходных artifacts и может быть внешним production S3 или локальным MinIO.
Stack readiness показывает Node.js, FFmpeg/FFprobe, worker и OCI runtime как связанную operational готовность.
Чего эта страница не утверждает
Discovery, lifecycle или typed subset не выдаются за полное управление всеми возможностями upstream-сервиса. Каноническая текущая граница также опубликована в service-evidence.json и каталоге 18 сервисов.