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

ServiceRequired dependencies
ManagerPostgreSQL, NATS with JetStream, optional OTLP/HTTP collector
WorkerNATS, S3-compatible storage, FFmpeg/ffprobe, persistent local state
AdminPrivate Manager access, OIDC issuer/client settings, and session encryption keys
DocsNone; 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.

Network policy