If you are weighing self-hosted streaming against a managed streaming service, think operationally. The right choice depends on which controls you need to run yourself (ports, auth, webhooks, storage) versus which you prefer to consume as a plan with defined features and limits. This guide provides a pragmatic checklist for both paths and highlights concrete enablement steps and failure behaviors you can verify before committing.
What “self-hosted” really asks you to operate
Running your own streaming server in containers gives you protocol and access control knobs. Expect to manage networking, feature toggles, and integrations.
- Protocol endpoints and ports
- Plan your firewall and load balancer rules around your ingest and playback protocols. A typical Docker deployment exposes RTMP (TCP 1935), SRT (UDP 10080), HTTP for HLS/HTTP-FLV and WebRTC signaling (TCP 8080), WebRTC media (UDP 8000), and RTSP for IP cameras (TCP 8554). These bindings are configurable via environment variables in the compose file.
- Feature gating at startup
- Services that aren’t in your license will be disabled automatically at boot. For example, SRT and WebRTC blocks can be turned off when absent. Likewise, the DVR/Recording block is disabled when neither DVR nor Recording is present. Validate what’s enabled before you rely on it.
- Ingest control (publish authentication)
- Set a publish password in the environment to require encoders to authenticate. Update your encoder’s stream key to append ?password=YOUR_PASSWORD. If the password is missing or wrong, the publish gets rejected during the on_publish handling path.
- Viewer access (signed playback)
- Set a playback secret to enforce signed playback URLs. With this on, playback requests (HLS/HTTP-FLV/WebRTC) are validated before sessions start. HLS sessions are configured to trigger an on_play event so your server can check the token and expiry. Without the secret, playback proceeds without this check. A helper script is available to generate tokens (HMAC-SHA256 over stream key + expiry); you remain responsible for URL issuance and TTL choices.
- Lifecycle webhooks
- You can forward stream lifecycle events to your backend by configuring a webhook URL (http or https). Delivery is fire-and-forget with a short timeout; if your endpoint is slow or unreachable, events may be lost. Design your consumer to be fast and idempotent.
- Recording uploads to object storage
- To upload finished recordings to object storage, set bucket and credentials in the environment. If a bucket is set without keys, upload is disabled. The uploader performs a signed PUT and retries up to three times; if all attempts fail, the local file is kept. Deleting local recordings only happens after a successful upload when you explicitly enable it.
- Adaptive Bitrate (ABR) transcoding
- ABR requires an appropriate license. When enabled, only known variants are accepted (1080p, 720p, 480p, 360p, 240p); unknown variants are skipped. If your plan doesn’t include ABR, the request is logged and disabled at startup.
For broader installation and configuration context, see /server-docs. If self-hosting is new to your team, also review /self-hosted-streaming-server.
What “managed” should clarify up front
A managed service turns many of the above switches into plan choices with defined limits and feature sets. When comparing plans, focus on:
- Required features: do you need DVR/recording, signed playback, low-latency delivery modes, webhooks, or ABR? Plans explicitly enumerate included capabilities such as DVR, Recording, low-latency, API keys, webhooks, captions, simulcast, DRM, and more. Confirm the plan includes what you need.
- Resource limits: max streams you can create and maximum resolution are plan-defined. Ensure your expected channel count and output resolution fit.
- Usage envelope: included hours and overage models exist; evaluate them against your expected usage. Avoid mixing these with your hosting/CDN assumptions.
For current plan details, review /#pricing. Treat plan limits as guardrails and size your workflows accordingly.
Decision checklist: self-hosted vs managed
Use this operational checklist to converge on a choice and verify it end to end.
Self-hosted fit (run a containerized server when you):
- Need to control protocol exposure and ports precisely at your edge.
- Want to manage ingest authentication and viewer tokenization locally.
- Integrate tightly with your systems via webhooks and custom storage.
- Are comfortable validating feature gates (SRT, WebRTC, DVR/Recording, ABR) before launch.
Managed fit (choose a plan when you):
- Prefer predefined feature sets and resource limits to simplify planning.
- Want to avoid running and updating media servers and their surrounding components.
- Can align your workloads (streams, resolutions, hours) to plan boundaries and scale by changing plans.
Verification steps and expected failure modes
Before committing, stage a realistic test and confirm the following behaviors.
- Networking and protocols
- Map RTMP/SRT/HTTP/WebRTC/RTSP to your security groups. Confirm only intended ports are reachable from the internet.
- Publish authentication
- With a publish password set, attempt a publish without it (expect reject) and with it (expect success). Ensure your team uses the correct stream key format.
- Signed playback
- Enable a playback secret, generate a token, and load a player with the signed URL (expect play). Remove or alter the token (expect reject). Choose a short TTL and verify expiry behavior. Note: internal ABR components may use loopback; they are only exempted from token checks when ABR is actually enabled.
- Webhooks
- Point to a fast HTTP(S) endpoint. Trigger on_publish/on_play/on_dvr by running a test publish, viewing playback, and finalizing a short recording. Intentionally slow your endpoint; observe that delivery is fire-and-forget with a short timeout and missed events are possible.
- Recording upload
- Configure bucket, keys, and region/endpoint as needed. Complete a short recording; confirm a single PUT is attempted and that up to three retries occur on transient errors. Simulate persistent failure; verify the local file remains. Enable deletion and confirm local cleanup only happens after a successful upload.
- ABR toggle and variants
- Try enabling ABR without the required license (expect it to be disabled with a log). When licensed, configure only supported variants and confirm unknown ones are skipped.
Actionable next steps
- If leaning self-hosted:
- Stand up a staging server with your intended port map and licensed features.
- Enable publish authentication and signed playback; wire your webhook endpoint.
- Configure recording upload to your chosen object store and verify end-to-end with retries and retention behavior.
- Document ABR variants you will run and validate manifests in your player.
- If leaning managed:
- List required features (DVR/Recording, tokenized playback, webhooks, ABR) and pick a plan that includes them.
- Check stream count and resolution limits against forecasted channels and outputs.
- Pilot a channel to confirm ingest, playback, and webhook semantics match your application logic.
- Revisit /#pricing when your workload changes (more channels, higher resolutions, or new features) to adjust plans.
Choosing between self-hosted and managed is less about ideology and more about who operates what. Use the checklists above to make the trade-offs explicit, verify the critical paths now, and avoid surprises later.