A stream key is a credential for publishing to an Nginx RTMP application; it is not a security switch by itself. To secure publishing, make the server check the key and reject unknown or revoked credentials, then use address restrictions only as an additional control where publisher addresses are stable.
The community nginx-rtmp-module provides an on_publish callback that can ask an HTTP application whether a publish request is allowed. The callback supplies the decision point, but your authorization service must implement the key lookup and policy. The examples below are patterns to adapt to the exact module build and deployment, not a complete drop-in security design.
Understand what a stream key protects
When an encoder connects to an RTMP application, it presents a publish path, commonly including an application name and stream name. Operators often use a secret stream name as a key. That can make casual discovery harder, but if a person obtains the path, the name alone does not establish that the publisher is authorised. A key becomes a useful credential only when the server checks it before accepting a publish.
Treat a publish key like a password that grants permission to send a live feed. Someone who obtains it may be able to publish under the associated identity, interrupt a legitimate broadcast, or replace its content, depending on how the application is configured. Do not place it in a public web page, a shared screenshot, or a repository that others can read. Avoid including it in diagnostic output that is retained or shared.
Publishing and viewing are separate permissions. A rule that permits a key to publish does not automatically make playback private, and a publishing key should not be described as a viewer password. The community module documents separate publish and play rules and callbacks in its README. If viewers must be restricted, design and test that access path separately.
The same distinction matters if the setup sends HLS or DASH to viewers over HTTP. An RTMP publish check does not, by itself, protect playlists or media segments served by another path. NGINX Plus documentation lists RTMP, HLS and DASH as supported formats, but the precise delivery architecture determines where viewer authorisation belongs. Review the relevant NGINX RTMP documentation and secure the actual HTTP endpoints you use.
Use server-side publish authorisation
In the community module, on_publish sends a request to an HTTP endpoint when a client tries to publish. That endpoint can inspect the request, find the presented credential in server-side records and apply policy. The callback response status determines whether the module allows or rejects the publish, as described in the community module documentation.
The directive does not create users, generate secrets, store keys or revoke them for you. Those are responsibilities of the authorization application and its operational process. A useful design has a clear answer for each request: which publisher is this, is its key still active, and is it allowed to publish to this application or stream? If the service cannot validate the request, choose and document a deliberate failure policy rather than accidentally allowing it through.
Keep the authorization endpoint reachable only by the Nginx service or the trusted network path that needs it. Do not expose a management interface or key database to the public internet merely because the callback uses HTTP. The exact protections depend on how your components communicate; check the deployment's network boundaries and the callback module's behaviour before relying on assumptions about request origin.
This design is useful when several people or encoders publish to one server. Each can have a separate credential, which lets you disable one publisher without changing everyone else's access. For a single unattended feed, the same principle still helps: you can rotate the one credential without confusing it with the stream name or the viewing URL.
Configure an on_publish check
The following is a minimal shape for an application block, not a universal configuration. Confirm the syntax, callback variables and response behaviour against the exact fork and version you have installed before using it:
rtmp {
server {
listen 1935;
application live {
live on;
on_publish http://127.0.0.1:8080/authorize-publish;
}
}
}
The Nginx RTMP module invokes the endpoint when a client attempts to publish into live. Your authorization application should inspect the request data the installed module sends, identify the requested stream and submitted credential, then decide whether that credential is active and permitted for that destination. Do not assume a sample endpoint receives exactly the same fields across forks or versions; verify its request format from the deployed build's documentation and a controlled test.
A safe decision flow is straightforward. Parse the request using the endpoint's expected format, reject malformed or incomplete input, look up the key without writing it to ordinary logs, check that it is active and belongs to the requested publisher or channel, and return the documented success or failure status. The module README documents status-based decisions; build your handler around the behaviour documented for your version, rather than copying an unrelated web framework example.
Separate the key from the stream name when practical. For example, a publisher might use a stable destination name such as evening-aarti, while presenting a separate secret value that the authorization service checks. Keeping the two concepts distinct makes it easier to change a credential without changing the audience-facing identity. It also avoids relying on an obscure destination path as the only barrier.
Before applying a change to a live channel, identify whether your installation is NGINX Plus with its packaged RTMP module or a community module built from source. Their installation and module-loading steps differ. The official NGINX Plus RTMP guide describes its package and dynamic-module process; the community module README describes a separate source-build route. Do not assume commands for one distribution apply to the other.
Validate configuration using the test command appropriate to your package, commonly nginx -t, then follow that package's reload procedure. NGINX's documentation shows testing and reloading in its Plus guide. Make the change during a period when you can observe the result, and keep the current configuration available for rollback. A syntax test confirms that Nginx accepts the configuration; it does not prove that the authorization service accepts the correct publisher or rejects the wrong one.
Reject unknown and revoked keys
A callback is only as strong as its decision logic. The endpoint should reject a key that is absent, malformed, disabled, expired under your own policy, or assigned to a different publishing identity. Do not make an unknown key succeed merely because the request came from a familiar address or used a plausible stream name. Those attributes can contribute to a policy, but they do not prove possession of the authorised credential.
Revocation needs to take effect in a predictable way. Keep a server-side record that lets an operator mark a credential inactive, and ensure the authorization path consults that status when a new publish request arrives. If a key is exposed, disable it and issue a replacement rather than relying on a secret URL remaining obscure. Decide how to handle a publisher that is already connected: a check at publish time may not, by itself, terminate an existing session when a key is revoked. Verify the module's supported disconnect or reauthorisation behaviour for your build and have a practical way to stop an unwanted active publish.
Keep an audit trail of decisions without turning logs into a second key store. Record useful context such as a publisher identifier, time, requested application, and allow-or-deny result, while avoiding the raw secret. If troubleshooting requires detailed request inspection, do so in a controlled environment and remove or protect any temporary logs afterwards.
Test both sides of the policy before relying on it overnight. In a controlled window, confirm that a valid credential can publish, then try an invalid credential and a credential you have revoked. Confirm that the rejected attempt does not take over the stream and that the expected event appears in logs without exposing the secret. These checks are operational advice; they are not a guarantee that every surrounding access path is protected.
Use unique, unpredictable credentials
Give each publisher a distinct secret rather than sharing one key across people, channels or machines. If a devotional stream and a local news loop use the same value, a leak from either setup may require changing both. Distinct keys reduce the scope of a rotation and make an audit trail more useful because the authorization record can identify which publisher attempted access.
Generate keys with a trusted password manager or a cryptographic random generator appropriate to your environment. The reviewed module documentation defines the callback mechanism, not a required key length or generation recipe, so do not treat a particular example length as an official module requirement. The practical aim is a value that cannot be guessed from the channel name, schedule, town, or a simple sequence.
Store the source of truth in a controlled location. Restrict access to the key records and the encoder configuration that contains them. Avoid reusing a YouTube stream key as the Nginx publisher credential: they serve different connections and should be managed independently. When a person or encoder no longer needs access, revoke its credential; when a secret may have leaked, rotate it and update only the affected publisher.
Think about where credentials travel. A key may be present in an encoder's configuration, a service request, or an administrative note. Limit who can read those locations, use a secret-handling method suited to your tools, and check whether the application or web server logs request parameters by default. If the actual key is being recorded, change the logging configuration before routine operation.
The operational workload is part of the choice. A small station with one trusted operator may prefer a simple record and a written rotation procedure. A station with multiple volunteers benefits more from per-person keys and a reliable way to disable one account. For background on a continuous YouTube workflow, see how to keep an RTMP feed alive through brief network outages; continuity and access control solve different problems, but both need to be tested.
Add IP restrictions when appropriate
Address restrictions can narrow who may publish, especially when the publisher uses a fixed address on a controlled network. The community module's access directives support address-based publish and play rules; the directive reference documents allow and deny and notes that rule order matters. For example, the following illustrates allowing one source and denying other publishers:
application live {
live on;
allow publish 192.0.2.10;
deny publish all;
on_publish http://127.0.0.1:8080/authorize-publish;
}
192.0.2.10 is an example address, not an address to copy. Replace it with the actual source address and check that the directive is valid in the context and module version you deploy. The module directive reference is for a particular community project; match it to your own build.
An allowlist can cause its own outages if the publisher's public address changes. A mobile connection, changing ISP assignment, or network address translation can make the source appear different from the value you expected. In India, for example, a studio connection may be stable while a person trying to publish from a phone is not. Confirm the address as seen by your server, consider failover connectivity, and make a documented way to update the rule when the source changes.
Use IP filtering as an extra condition alongside credential validation, not instead of it. A known address can be shared by several devices or people, and an address can be spoofed or otherwise misrepresented in some network designs. An obscure stream name has the same limitation: it can reduce accidental discovery but it is not a substitute for checking a secret. The two controls answer different questions: the address rule narrows network origin, while the callback checks whether a credential is authorised.
If publishers connect from changing networks, it may be more practical to omit a narrow allowlist and rely on robust credential checks plus monitoring. You can still restrict administration and the authorization service to trusted networks where that fits the design. Avoid a rule so broad that it gives a false sense of security, and avoid a rule so narrow that it silently blocks the person responsible for restoring the channel.
Keep the wider delivery path in view
A secure publish decision does not settle every question about transport or viewing. The community RTMP listener should not be assumed to encrypt its connection merely because NGINX supports TLS in other contexts. The NGINX stream SSL reference concerns the separate stream module and does not establish native TLS for every community RTMP listener. If confidentiality between encoder and ingest server matters, validate a suitable TLS termination, proxy, VPN or tunnel arrangement for the exact deployment.
Likewise, if the feed is repackaged for HTTP delivery, review the playlist and segment path as its own boundary. A public HLS playlist can remain viewable even when publishing is gated. The right protection depends on the delivery architecture, so avoid dropping in a generic authorization snippet without checking how clients fetch the media and how any access credentials are passed.
Resource controls such as maximum stream or message limits can help constrain workload, but they are not authentication. Choose those values for the actual stream and installed module rather than copying a number from an example. The directive reference describes such controls alongside access rules; keep their purpose distinct in your configuration notes.
For a YouTube channel, the Nginx server is an intermediate publisher, not the destination account itself. Keep the encoder settings, ingest credentials and YouTube account controls separate, and document which credential belongs to each connection. If you are setting up a continuous station rather than managing a self-hosted ingest point, the guide to streaming a college radio station continuously on YouTube covers a different part of that workflow. For a prerecorded loop, the YouTube stream key setup guide may help distinguish the platform key from the credential you validate at your own RTMP server.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does a stream key alone secure an Nginx RTMP server?
No. A stream key is only useful as an access credential if the server or an authorization service checks it and rejects invalid values. A hidden stream name may deter casual guessing, but it is not validation.
What does on_publish do?
It calls an HTTP endpoint when a client attempts to publish, allowing that endpoint to decide whether the publish is accepted. Your service must implement the credential lookup, revocation checks and policy; the directive does not provide those functions by itself.
Should I restrict publishing by IP address as well?
It can be useful when a publisher's address is stable, such as a fixed studio connection. Changing addresses, mobile access and shared network gateways can make a narrow allowlist unreliable, so use it as an additional restriction rather than a replacement for key validation.
Does the publishing key protect viewers or HLS delivery?
Not automatically. Publishing and playback are separate permissions, and HTTP playlists or segments need controls suited to their own delivery path. Check the architecture and the relevant module documentation before assuming one credential protects all access.