Before you commit to a self-hosted streaming server, verify how it behaves in your environment: what protocols and ports you’ll operate, which licensed features actually start, how ingest and playback are controlled, and what happens when uploads or webhooks fail. This article provides a concrete, testable checklist tailored to a Nighthawk-style deployment so you can validate the critical paths before you buy.
1) Networking and protocols: bind only what you intend to run
Confirm you can expose just the protocols you need and that your firewall and load balancer rules match.
- Typical endpoints (configurable via environment variables when running in Docker):
- RTMP ingest on TCP 1935
- SRT ingest on UDP 10080
- HTTP for HLS/HTTP-FLV and WebRTC signaling on TCP 8080
- WebRTC media on UDP 8000
- RTSP ingest for IP cameras on TCP 8554
- Action: Map these ports in staging exactly as you expect in production. Close or omit protocols you won’t use. Verify external reachability and that encoders/players connect successfully.
- Limitation to note: Port exposure alone doesn’t ensure end-to-end delivery or latency—treat it as connectivity only.
See /server-docs for installation and configuration context.
2) Licensing and feature gates: know what the runtime will disable
In a self-hosted setup, the runtime disables blocks that aren’t licensed at startup. Validate licensing early so you don’t plan around features that won’t come up.
- What can be disabled when unlicensed:
- SRT and WebRTC services
- DVR/Recording block
- Adaptive Bitrate (ABR) transcoding:
- ABR requires an appropriate license; when requested without it, ABR is disabled at startup.
- Only specific variants are accepted (e.g., 1080p, 720p, 480p, 360p, 240p). Unknown variants are skipped.
- Actions:
- Boot with your intended license and inspect logs to confirm which services are enabled.
- If you plan to use ABR, configure only supported variants and confirm the master/variant playlists appear during a test publish.
- Limitation to note: Feature enablement is a capability toggle. It does not imply any throughput, latency, or availability profile.
3) Ingest control: require a publish password (stream authentication)
Protect your contribution ingress so only authorized encoders can publish.
- How to enable: Set an environment variable to require a password on publish; on startup the server notes that stream authentication is enabled.
- Encoder format: Append ?password=YOUR_PASSWORD to the stream key in your encoder. Viewers are not prompted; this control applies to ingest only.
- Failure behavior to test: A publish with a missing or incorrect password is rejected during the on_publish path.
- Limitation to note: This is an application-layer check. Correct encoder configuration and secret handling remain your responsibility.
4) Viewer access: enforce signed playback URLs (and test token failures)
If you need viewer-side access control, enable signed playback and issue short-lived tokens from your backend.
- How to enable: Set a playback secret in the environment. At startup, the server enforces signed playback and ensures HLS sessions trigger validation on play so tokens can be checked.
- Token format and signing: Use the provided helper or your own code to generate a token using HMAC over the stream key plus an expiry. Tokens and expirations are conveyed in query parameters that the local control path validates.
- Special case: When ABR is actually enabled, internal loopback fetches by the transcoder may be exempted from viewer token checks so internal pulls don’t break your pipeline.
- Failure behavior to test:
- Missing token → playback rejected
- Bad signature → playback rejected
- Expired token → playback rejected
- Limitations to note: Token TTL, secret storage/rotation, and URL issuance are your responsibility. Signed playback does not guarantee end-to-end security or delivery.
5) Lifecycle webhooks: wire them up and expect fire-and-forget delivery
Stream events are useful for automation, but treat webhook delivery as best-effort.
- How to enable: Set an HTTP or HTTPS endpoint URL in the environment. On startup, event forwarding is enabled.
- Delivery model: Webhooks are forwarded as raw JSON with an event header, fire-and-forget, with a short timeout. If your endpoint is slow or unreachable, events may be lost.
- Actions:
- Point to a fast, resilient handler that returns 2xx quickly and offloads heavy work asynchronously.
- Generate test events (publish, play, recording) and confirm your endpoint receives and parses them.
- Limitation to note: There is no built-in retry beyond the one-shot forwarder; design idempotency and internal queues on your side.
6) Recordings and object storage uploads: prerequisites and failure handling
Confirm exactly when recordings upload and what happens when object storage is unavailable.
- Prerequisites:
- DVR/Recording must be licensed and enabled; otherwise no recording files are produced.
- Set object storage variables: bucket plus access and secret keys. If the bucket is set but keys are missing, upload is disabled.
- Upload behavior:
- Each file upload is a single signed PUT; the uploader retries up to three times on errors.
- If all attempts fail, the local file is kept.
- Optional cleanup: delete the local file only after a successful upload and only when you explicitly enable deletion.
- Safety checks: The local control plane validates safe file names and restricts uploads to real files beneath the recordings directory.
- Actions:
- Test with valid credentials and confirm objects appear in the expected path.
- Simulate a failure (e.g., block egress or use bad credentials) and verify that retries happen and local files remain.
- Enable the “delete local after upload” option only after you verify end-to-end success and retention needs.
- Limitation to note: Retries and local retention reduce risk but do not guarantee object-store delivery.
7) Verification checklist (actionable)
Run this in a staging environment that mirrors production.
- Networking and protocols
- Open only the protocols you need (RTMP/SRT/HTTP/WebRTC/RTSP) and confirm external reachability on the expected ports.
- Licensing and features
- Start the server with your intended license and confirm SRT/WebRTC/DVR blocks are enabled or disabled as expected.
- If using ABR, configure supported variants only; confirm ladder output and skip logs for any unknown variants.
- Ingest control
- Set the publish password and publish from an encoder with and without the password; verify rejects on failure.
- Viewer access
- Enable signed playback, generate tokens, and test success and the three failure cases (missing, bad signature, expired).
- Webhooks
- Configure the webhook URL, trigger publish/play/recording, and verify your endpoint receives JSON with the event header. Confirm your handler returns quickly.
- Recordings and uploads
- Produce a short recording, confirm upload success, and (optionally) enable local deletion and verify it deletes after a confirmed upload.
- Simulate upload failures and confirm files remain local.
Where to read more and how to compare options
- For installation, configuration, and protocol details, see /server-docs (sections include Installation & Updates, Configuration & Ports, Publishing & Playback, Recording & Features, Management APIs, Licensing, and Troubleshooting).
- For background on self-hosted streaming and evaluation criteria, see /self-hosted-streaming-server.
- If you later compare self-hosted licensing with cloud plan options, see /#pricing for plan information. Avoid mixing license features with your separate infrastructure assumptions (compute, storage, egress) when modeling total cost.
By validating these behaviors upfront—especially the negative paths—you reduce surprises on launch day and buy a server that matches your operational posture. Treat each control as a building block in a layered design rather than a promise of security, availability, or performance.