If you run self-hosted streaming, it’s easy to blur three very different buckets: infrastructure (compute, storage, egress), bandwidth (ingest and viewer delivery), and software licensing. That blur leads to surprises—either overbuying licenses you don’t use, or underestimating network and storage you absolutely do. This guide shows how to separate these concerns in a Nighthawk-based stack and gives you a practical worksheet to estimate each side without mixing signals.
See /server-docs for installation, configuration, and protocol context.
1) Separate the concerns: what licensing controls vs. what hosting pays for
- Hosting and bandwidth
- Your compute, storage, and network egress are infrastructure expenses. Expect them to scale with hours streamed, renditions produced, and viewers served.
- Protocol exposure and firewalling affect where traffic flows. With Nighthawk in Docker, the defaults are RTMP ingest (1935/TCP), SRT ingest (10080/UDP), HLS/HTTP-FLV/WebRTC HTTP (8080/TCP), WebRTC UDP media (8000/UDP), and RTSP (8554/TCP). Plan security groups and load balancers around these bindings.
- Software licensing
- Licensing features control what the server enables. Nighthawk will disable selected services at startup if the feature is not present (e.g., SRT, WebRTC, and DVR/recording blocks). Treat this as a capability toggle—separate from the infrastructure you provision for throughput or headroom.
- Adaptive Bitrate (ABR) transcoding is licensed. If ABR isn’t included, the request is refused at startup. Only the known variants (1080p, 720p, 480p, 360p, 240p) are accepted; unknown variants are skipped.
For Cloud plans, limits and features are explicit (max streams, max resolution, included hours, and features). For example, Free includes one stream at 720p with a small number of included hours; Pro increases streams and hours and includes features like DVR, recording, and low-latency; Business and Enterprise extend these further. Use these limits to plan usage and avoid mixing them with compute or CDN assumptions. For pricing details, see /#pricing.
2) Controls that help manage bandwidth and storage (and their limitations)
- Publish authentication (ingest control)
- Set a publish password to require encoders to authenticate before streaming. This is an application-layer control that reduces accidental or unauthorized publishes that would consume upstream and downstream bandwidth. If the variable is not set, the server won’t enforce this check.
- Signed playback URLs (viewer-side authorization)
- Set a playback secret to require signed tokens on playback requests (HLS, HTTP-FLV, and WebRTC). Your backend should mint time-bound tokens per viewer or session; a helper signs stream key + expiry with HMAC-SHA256. This helps control unauthorized playback but is not a delivery guarantee—expiry, secret management, and correct URL construction are your responsibilities.
- Lifecycle webhooks (automation and monitoring)
- Enable an endpoint to receive publish/play/DVR-style events. Delivery is fire-and-forget with a short timeout; if your endpoint is slow or unreachable, events may be lost. Use this for internal accounting (e.g., start/stop metering), not as a guaranteed audit trail.
- Recording upload to object storage
- Configure S3-compatible upload for DVR/recordings. If the bucket is set without credentials, upload is disabled. The uploader performs a signed PUT and retries up to three times; on failure, the local file is kept. If you explicitly enable local deletion, files are removed only after a successful upload. Use this to separate storage cost planning (object store) from local disk sizing.
3) ABR and egress: make an explicit decision
ABR increases quality coverage but also multiplies output renditions. If you enable ABR (and your license allows it), choose only the variants you need. The implementation accepts 1080p, 720p, 480p, 360p, and 240p. Unknown variants are skipped, and ABR is disabled outright when not licensed. Right-size the ladder to your audience rather than defaulting to all rungs; it affects both compute and CDN egress.
4) A planning worksheet you can run in an afternoon
- Define your workload
- Concurrent live channels now and at peak
- Hours streamed per month (by channel type: event vs 24/7)
- Expected viewer-hours per month and typical ABR ladder (number of rungs)
- Map protocols and ports to your network plan
- RTMP, SRT, HLS/HTTP-FLV, WebRTC, RTSP. Verify security groups and any UDP requirements (SRT, WebRTC) match your environment.
- Decide on controls to reduce waste
- Enable publish authentication to prevent stray publishes
- Enable signed playback to reduce unauthorized viewing
- Turn on webhooks for start/stop metering (with your own persistence, since delivery isn’t guaranteed)
- Storage and retention
- If you upload recordings to S3-compatible storage, plan object store lifecycle and keep the default “keep local on failure” behavior in mind. Enable local deletion only if your upload success path is proven.
- ABR choice
- If licensed, pick only necessary rungs from 1080p/720p/480p/360p/240p. Validate GOP and encoder settings on your side.
- Cloud plan alignment (if you use Nighthawk Cloud)
- Match your expected max streams, resolution needs, and included hours with an appropriate plan. Track included hours vs usage and understand that overages (if applicable) are usage-based. Avoid conflating included hours with your compute/CDN costs.
5) Failure modes to plan for
- Feature gating at startup
- If a feature isn’t licensed, its server block is disabled. Don’t assume a protocol is listening until you verify logs and ports.
- Tokenized playback
- Unsigned or expired playback requests are rejected when a secret is set. Token generation and expiry drift are on you; test clock skew and CDN caching.
- Webhook delivery
- Posts are non-blocking with a short timeout; they can be dropped under network issues. Build idempotent handlers and your own retry queues if events are critical.
- Recording upload
- Upload may fail after all retries due to network or credentials; local files remain for manual retry. If you enabled local delete, verify success logs before assuming retention.
Verification checklist before you commit a budget
- Ports and protocols
- Confirm RTMP 1935/TCP, SRT 10080/UDP, HTTP 8080/TCP, WebRTC 8000/UDP, and RTSP 8554/TCP bindings (or your overrides) are reachable as intended.
- Feature availability
- Restart and check logs to confirm SRT/WebRTC/DVR/recording/ABR are actually enabled (or intentionally disabled) for your license.
- Ingest control
- Set a publish password, update one encoder, and confirm wrong passwords are rejected and correct ones succeed.
- Playback control
- Set a playback secret, generate a signed URL, verify that unsigned and expired tokens fail while valid tokens play.
- Webhooks
- Point to a test endpoint, trigger publish/play, and ensure your service receives JSON events quickly. Account for the fire-and-forget model.
- Recording upload
- Enable S3 upload with valid credentials. Produce a short recording, confirm a successful PUT, and validate the local deletion setting behaves as configured.
Links for context: /server-docs for configuration, and /#pricing for plan and licensing information.