Deployment
EncodeFlow applications ship as independent containers. The Manager and Workers need runtime configuration and infrastructure access. The Admin server also needs private Manager connectivity and OIDC configuration; the docs app is standalone.
Build images with Nx
yarn nx run @encode-flow/manager:docker:build
yarn nx run @encode-flow/worker:docker:build
yarn nx run @encode-flow/admin:docker:build
yarn nx run @encode-flow/docs:docker:build
The Next.js images use standalone output and run as the unprivileged node user. The docs container listens on port 3000; the optional local Compose profile maps it to 4502.
docker compose --profile docs up --build docs
Worker image and GPU runtime
The Worker image is based on the official Node.js 24 Trixie slim image. It installs Debian's FFmpeg 7.1 package with H.264, NVENC, VA-API, subtitles, and HLS support, plus the Intel and Mesa VA-API drivers. The Docker build runs a CPU smoke test for MP4, subtitle rendering, and HLS and verifies that the GPU encoders and filters are present.
The image does not install a host NVIDIA driver. NVIDIA's container runtime mounts the host driver and device nodes at startup, so GPU Workers must be started with the NVIDIA Container Toolkit and video capability enabled:
docker run --rm --gpus all \
-e NVIDIA_DRIVER_CAPABILITIES=compute,video,utility \
apps-worker \
sh -c 'ffmpeg -hide_banner -encoders 2>&1 | grep nvenc'
The Worker performs the real NVENC/NVDEC smoke tests after startup. If the host GPU, driver, or container runtime is unavailable, the GPU path is not advertised (the CPU path can remain ready); a Worker is quarantined only when no certified execution path passes.
Service dependencies
| Service | Required dependencies |
|---|---|
| Manager | PostgreSQL, NATS with JetStream, optional OTLP/HTTP collector |
| Worker | NATS, S3-compatible storage, FFmpeg/ffprobe, persistent local state |
| Admin | Private Manager access, OIDC issuer/client settings, and session encryption keys |
| Docs | None; static documentation is bundled into the server image |
Kubernetes Manager
The repository’s deploy/kubernetes/manager example includes a Deployment, Service, ConfigMap, Secret template, probes, resource settings, and an external Grafana Alloy exporter policy.
- Readiness:
/api/health/ready - Liveness:
/api/health/live - Termination: allow the coordinated shutdown and telemetry flush to finish
- Secrets: inject database, NATS, enrollment, and OTLP values from Secret resources
Worker placement
Place Workers near their compute device and media storage path. Give GPU pools the matching device plugin/runtime, mount a persistent state volume, and reserve enough ephemeral disk for the largest concurrent source and output set.
Use a drain request before voluntary node maintenance, then wait for capacity.activeJobs to reach zero.
Workers expose the same version-neutral probe paths as the Manager. Worker readiness requires a current lease, a passing CPU or GPU certification path, and a state that can accept or finish work.