NGINX RTMP can accept a publisher stream under a configured application and relay it to YouTube Live. A 2 GB VPS label is not proof that the machine can encode 720p: forwarding an already encoded feed and transcoding it are different workloads.
The reliable approach is to match the publisher URL to the NGINX application, use YouTube’s current encoder targets and ingest details, then test the actual stream while watching resource use. Treat the configuration below as a structural example, not a verified drop-in file for every NGINX package.
Trace the stream from publisher to YouTube
Think of this as three separate connections. A publisher such as OBS sends an already encoded audio-video stream to your VPS. NGINX RTMP accepts it at a listening address and application name. The VPS then forwards that stream to the ingest URL and stream key supplied by YouTube Live Control Room.
The application is the named receiving path, not a YouTube channel or a video title. In the example later in this article, live is the application name. A publisher URL such as rtmp://your-vps.example/live/channel1 means the application is live and the stream name is channel1. The configured application must accept live publishing, and the module must be present and loaded for the NGINX instance you are using.
The arut/nginx-rtmp-module documentation describes RTMP live streaming and push/pull relay support. Its example uses port 1935, the conventional RTMP port in this kind of setup. That does not mean port 1935 is open on your firewall, that your VPS provider permits the traffic, or that your installed NGINX already has the module.
It helps to distinguish the publisher-to-VPS leg from the VPS-to-YouTube leg when troubleshooting. If YouTube never sees an incoming stream, first check whether the publisher can reach your VPS and whether its URL matches the application. If the publisher connects but YouTube remains offline, inspect the forwarding destination, key handling and outbound connection separately. For another perspective on the YouTube key and publisher side, see this guide to using a YouTube stream key in OBS.
Match the RTMP URL to the application block
The application segment is the part of the publisher URL that must correspond to the application block in NGINX. If the block says application live, the publisher address should contain /live/ before the stream name. Renaming one side without changing the other can leave you with a working-looking server configuration and a publisher that cannot publish to the expected path.
A minimal structural pattern looks like this:
rtmp {
server {
listen 1935;
chunk_size 4000;
application live {
live on;
# Add the relay directive or client configuration
# appropriate to your module and current YouTube URL.
}
}
}
This illustrates the relationship between the RTMP server and application; it is not a complete relay configuration. The module’s syntax and available directives depend on how it was built and installed. In particular, do not paste a real YouTube stream key into a public example, ticket or screenshot. Use the current URL and key from your own Live Control Room, keep them private, and follow the installed module’s documented method for supplying the destination.
NGINX packages are not interchangeable here. The arut project documentation describes building the module alongside NGINX source. F5’s NGINX RTMP module guide covers its dynamic module for NGINX Plus, including loading it in the main context and testing configuration before reload. Those instructions are specific to that edition and packaging. Check what your OS package actually includes rather than assuming that installing a package called NGINX also enabled RTMP.
The listening port must be reachable from the publisher, and the machine must also be able to make the outbound connection to YouTube. Restrict inbound access where practical to the publisher locations and protocols you intend to use; do not expose management access simply because the stream listener needs network access. If you are using a domain name, verify that it resolves to the correct VPS before testing the full path.
Choose YouTube’s 720p H.264 targets
YouTube’s current encoder guidance lists a minimum video bitrate of 3 Mbps and a recommended bitrate of 8 Mbps for 720p H.264 at both 30 and 60 frames per second. These are YouTube’s published ingest figures, not a guarantee that a particular publisher, VPS network or audience connection will deliver a clean stream. Start with the profile that matches your content and test it end to end.
| 720p H.264 profile | YouTube minimum video bitrate | YouTube recommended video bitrate | Keyframe guidance |
|---|---|---|---|
| 30 fps | 3 Mbps | 8 Mbps | 2 seconds recommended; no more than 4 seconds apart |
| 60 fps | 3 Mbps | 8 Mbps | 2 seconds recommended; no more than 4 seconds apart |
YouTube recommends constant bitrate (CBR) and keyframes every two seconds, with keyframes no more than four seconds apart. For audio, its guidance allows AAC or MP3; the page lists 128 Kbps for stereo audio. Set these values at the encoding publisher, not by assuming that NGINX will repair a mismatched stream. A relay forwards encoded media; it is not automatically an encoder or a quality-control filter.
Choose 30 fps for material whose motion does not need the extra temporal detail of 60 fps, such as a mostly static devotional image with music or a slow ambience scene. A 60 fps source may suit fast movement or gameplay, but it is only useful if the source and publishing chain can produce it consistently. A higher frame rate does not make a low-motion still image look better by itself, and can make encoding more demanding at the publisher.
Also consider the upstream connection from the publisher to the VPS. The selected video and audio bitrate must fit the available upload path with room for ordinary variation; a speed test at one moment does not demonstrate that a long stream will remain stable. For more on assessing the upload side, use this practical guide to YouTube podcast stream upload speed. Do not confuse the bitrate settings with a measurement of your own network.
Set YouTube ingest protocol and stream details
Open YouTube Live Control Room and obtain the current ingest URL and stream key for the broadcast. YouTube’s RTMPS help page explains how to reveal and copy them. Use the actual endpoint shown for your account and broadcast rather than relying on a URL copied from an old example. Keep the key secret: anyone who has it may be able to send a feed to the associated stream.
Prefer RTMPS when your forwarding method supports it. RTMPS is RTMP carried over TLS, which protects the connection in transit. Google’s RTMPS ingestion documentation specifies the rtmps protocol, a valid YouTube ingest server and application path, and port 443. The destination path matters as much as the protocol: a correct key paired with the wrong or stale ingest address can still fail.
In YouTube’s stream settings, make sure the stream is configured for the intended live format and that the chosen stream key corresponds to the endpoint you are using. Titles, visibility and other broadcast details affect the YouTube event, not the NGINX application name. Keep those concerns separate: the NGINX path identifies where the publisher arrives; YouTube’s stream details identify the broadcast destination.
If your NGINX RTMP build cannot itself make the desired secure relay, use a supported forwarding client or arrange the relay in a way consistent with the installed module and current YouTube endpoint. Do not assume every push directive or package supports every transport and TLS behaviour. Confirm the feature in that version’s documentation and test it with a private or scheduled stream before relying on it for a continuous channel.
Forward the encoded feed or transcode deliberately
For pass-through forwarding, the VPS receives a stream that the publisher has already encoded in the target format and relays those packets onward. NGINX is moving the stream through the configured route; it is not doing the video compression work. If the incoming feed already matches YouTube’s intended resolution, frame rate, codec and bitrate, avoiding an additional encode is generally the simpler workload to test.
Transcoding is different. It decodes and re-encodes media, for example to change resolution, frame rate, bitrate or codec. The module project documents FFmpeg-based transcoding as a capability, but that fact does not establish how much CPU or memory a particular encode needs on a particular VPS. Neither the 2 GB memory label nor YouTube’s bitrate table determines whether a given processor can sustain the job.
| Choice | What the VPS does | Main question to answer |
|---|---|---|
| Pass-through relay | Receives and forwards an already encoded feed | Does the source already match the YouTube target, and can the network carry it steadily? |
| Transcode on the VPS | Decodes and encodes the feed before forwarding | Can this exact VPS sustain the chosen conversion without resource pressure or dropped frames? |
Do not add transcoding merely because the feed passes through a VPS. If the source is wrong for the destination, first ask whether the publisher can encode the desired profile itself. That keeps the VPS focused on accepting and forwarding. If a transformation is genuinely needed, test the intended source, output settings and duration on the actual plan; do not infer a safe preset from the memory figure alone.
This distinction is especially important for a small business loop, lecture or music channel expected to run overnight. A still-image feed and a changing high-motion source may not put the same work on an encoder, and different conversion choices change the load again. StreamNeo removes the need to keep a personal computer on for a file-based 24/7 broadcast, but it is not an RTMP relay product for configuring your own VPS: it takes an uploaded video and runs a YouTube-only stream from the cloud.
Validate the configuration and test the VPS
Before reloading, run the configuration test for the NGINX edition and binary you actually use. The F5 instructions include nginx -t for their NGINX Plus dynamic-module workflow; on other installations, confirm the correct binary and configuration path rather than assuming that command tests the service you intend to run. A successful syntax check proves the file parses with the available directives. It does not establish that the firewall, DNS, outbound route, YouTube key or media settings are correct.
For a controlled first test, connect the publisher to the VPS application and inspect its connection logs. Confirm that the stream name arrives at the expected application and that the forwarding process is attempting the current YouTube ingest destination. Then check Live Control Room for an incoming signal and its status indicators. If the stream does not arrive, diagnose in order: publisher URL and name, NGINX listener and module, firewall reachability, relay destination and key, and finally YouTube’s displayed status.
Test with the actual intended resolution, frame rate, audio and bitrate. A low-bitrate test can confirm that paths connect, but it does not test the capacity of the final workload. If transcoding is planned, test the conversion on the same VPS plan with the intended input and output rather than extrapolating from pass-through. Leave the test running long enough to observe ordinary changes in CPU, memory, network throughput and stream health; a brief start-up check is not evidence of overnight stability.
A useful test record notes the time, input profile, whether the VPS transcodes, observed resource use, any publisher reconnects, and YouTube warnings or dropped-frame indicators. This record helps separate a configuration fault from a capacity issue. If the publisher loses its connection but the VPS has headroom, investigate the source connection. If resource pressure coincides with encoding, reduce the work or move encoding upstream before changing unrelated network settings.
Monitor stream health and resource use
During the test, watch both the broadcast and the machine. YouTube’s live health indicators can show whether the incoming feed is reaching the ingest service with problems, while the VPS’s own monitoring can show CPU, memory, disk pressure and network traffic. Neither view alone tells the whole story. A healthy process can still be forwarding a stream YouTube flags, and a clean YouTube ingest does not mean the VPS has spare capacity for another workload.
For a pass-through relay, recurring investigation usually centres on publisher reachability, network stability, reconnect behaviour and whether the relay destination remains current. For a transcode, add encoder utilisation and any signs that processing cannot keep pace with the incoming media. Do not set thresholds based on another operator’s VPS: test your own workload and pay attention to sustained pressure, not just a single peak.
A 24/7 channel also needs an operational plan for failures. Keep configuration changes small and reversible, document where the active config lives, protect the stream key, and know how to restart or roll back the service. If several channels share the same machine, test the combined workload rather than one stream in isolation. A single stream test cannot establish the capacity of a multi-stream deployment.
If you decide that maintaining an RTMP application, relay and machine monitoring is not the right operational trade-off, a hosted workflow may be simpler for a prerecorded channel. The guide to setting up an always-on YouTube stream with a hosted service explains that separate approach. Conversely, a VPS is useful when you need control over the publishing path or are learning the relay stack and are prepared to maintain it.
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 every 2 GB VPS support 720p YouTube streaming?
No. The memory label alone does not tell you the CPU, network conditions, package configuration or other workloads on the machine. Test the exact stream you intend to run, and distinguish forwarding an encoded feed from encoding it on the VPS.
Does NGINX RTMP encode the video for YouTube?
Not simply by accepting and relaying an RTMP stream. A pass-through configuration forwards media that the publisher has already encoded; transcoding requires a separate encoding function such as an FFmpeg-based workflow and must be tested for the actual machine.
Which part of the RTMP URL must match the NGINX configuration?
The application portion must match the name of the application block, while the trailing stream name identifies the publisher’s stream within that application. For example, /live/channel1 uses the live application and channel1 stream name.
Should I use RTMP or RTMPS to YouTube?
Use RTMPS when your forwarding method supports the current YouTube endpoint. YouTube recommends the encrypted protocol, and its ingestion guidance specifies the secure protocol and port 443; obtain the actual URL and key from Live Control Room.