Production checklist
What this checklist means
Section titled “What this checklist means”These are deployment tasks, not unresolved bugs in the Tomo Streaming codebase. The public repositories, SDK contracts and CI can be healthy while an installation still needs production hardening. Mark each item when it has been verified in the target environment; do not treat an unchecked item as a failed build.
The current self-hosted release is v0.1.0 (developer preview). Use this page as an operator runbook before inviting real users, and keep the release notes alongside your deployment record.
Project status vs. deployment status
Section titled “Project status vs. deployment status”| Area | Project status | Operator action |
|---|---|---|
| Source and SDKs | Public, versioned and covered by CI | Pin the version used by the deployment |
| Self-hosted runtime | v0.1.0 developer preview |
Validate it on the target Linux host |
| Cloud offering | Planned / coming soon | Do not advertise cloud capacity as generally available |
| Production security | Environment-dependent | Complete the network and secret controls below |
| Horizontal scaling | Not the default preview path | Add shared leases before running multiple control planes |
An unchecked box therefore means “not verified for this environment”, not “the repository is broken”.
Network and security
Section titled “Network and security”- Terminate TLS and expose signaling only through
wss://. - Configure TURN and test from mobile and restrictive enterprise networks.
- Keep API keys in a secret manager and rotate them periodically.
- Restrict inbound ports with a firewall; expose only the reverse proxy and required TURN ports.
- Restrict access to the Docker socket, worker network and capture devices.
- Run application input agents with minimum privileges.
- Pin images to a release tag or immutable digest; never use
latestin production.
Capacity
Section titled “Capacity”- Set CPU, memory and concurrent-session limits.
- Measure session startup p50/p95 rather than publishing assumed numbers.
- Stop empty sessions after a defined idle period.
- Track TURN bandwidth and cost separately from direct peer connections.
- Load-test the configured
MAX_STREAM_SESSIONSlimit before inviting users.
Observability
Section titled “Observability”- Monitor container exits and restart causes.
- Record session status transitions and startup latency.
- Alert on worker saturation and repeated signaling failures.
- Forward structured logs to a central sink.
- Never log API keys, host tokens or player access tokens.
Scaling boundary
Section titled “Scaling boundary”The developer-preview control plane stores leases in memory. Before running multiple replicas, add a shared lease store and worker scheduler while preserving the existing HTTP, SDK and WebRTC contracts.
- Keep one control plane per worker for the preview deployment.
- If adding replicas, implement shared leases and test failover before routing traffic to both.
Launch readiness
Section titled “Launch readiness”For a public cloud preview, define hard free-session limits, abuse controls, quota visibility and a support path before opening capacity broadly.
- Document rollback to the previous known-good image.
- Confirm camera, desktop and audio consent with every participant before publishing a room.
- Define an incident owner and a support contact.
Completion record
Section titled “Completion record”Keep a dated copy of the completed checklist with the deployment configuration. Record the image digests, host capacity, TURN test result, load-test result and rollback target. This turns the page into evidence of an environment review rather than a generic list of promises.