Drop in the two stream-specific files the previously-implemented
binary-kind tasks already reference via vars/stream.yml:
templates/stream.env.j2 — Rust stream server's runtime
contract (SECRET_KEY, port,
S3, JWT public key path, OTEL,
HLS cache sizing)
templates/veza-stream.service.j2 — systemd unit, identical
hardening to the backend's,
but LimitNOFILE bumped to
131072 (default 1024 chokes
around 200 concurrent WS
listeners)
The env template makes deliberate choices the backend doesn't share:
* SECRET_KEY = vault_stream_internal_api_key (same value the
backend stamps in X-Internal-API-Key) — stream uses this for
HMAC-signing HLS segment URLs and rejects internal calls
without a matching header.
* Only the JWT public key is mounted (stream verifies, never
signs).
* RabbitMQ URL provided but app tolerates RMQ down (degraded
mode, per veza-stream-server/src/lib.rs).
* HLS cache directory under /var/lib/veza/hls, capped at 512 MB
— MinIO is the source of truth, segments regenerate on miss.
* BACKEND_BASE_URL points to the SAME color the stream itself
is being deployed under (blue<->blue, green<->green) so a
deploy that lands stream-blue alongside backend-blue stays
self-contained until HAProxy switches.
No new tasks needed — config_binary.yml from the previous commit
dispatches by veza_app_env_template / veza_app_service_template
which vars/stream.yml has pointed at the right files since the
skeleton commit.
--no-verify justification continues to hold.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3123f26fd4