A Vultr host used for YouTube streaming should accept only the inbound connections its actual role requires. For most setups, SSH is an inbound administration connection, while the encoder sends YouTube RTMPS outbound; that does not mean your host needs a public RTMP listener.
This guide uses Ubuntu and UFW for its command examples, and distinguishes a host that encodes video from one that relays a stream. First identify what runs on your instance, then make changes with a recovery route available. The rules below are examples to adapt, not a universal port list.
Identify the server role before changing ports
A “YouTube streaming server” can mean several different things. You might run OBS or another encoder on the Vultr instance and have it send a finished feed to YouTube. You might instead encode on a computer at home and use the Vultr host as a relay. Or the instance might run a control panel or another supporting service. Each arrangement has a different inbound exposure.
Write down three things before editing a firewall: which machine encodes; what software listens for inbound connections on the Vultr host; and who needs to connect to each listener. If you cannot name a process that needs an inbound port, do not open one just in case. YouTube’s instructions for sending a stream explain the encoder-to-YouTube connection, not a requirement to accept RTMP on your own server. For context on an encoder-based workflow, see our guide to streaming podcast episodes from a Mac mini.
For a host that runs an encoder, the usual network picture is an administrator connecting inward over SSH and the encoder making an outbound connection to YouTube. For a relay, a separate encoder may send media inward to the relay; that listener’s port and access policy depend on the relay software and the chosen protocol. If the relay then forwards to YouTube, that is a separate outbound connection. A service such as a web control panel adds its own listeners and should be treated separately from the video path.
This distinction affects both security and troubleshooting. Allowing inbound SSH does not allow an outbound video connection to YouTube, and allowing outbound RTMPS does not make SSH reachable. They are different directions and usually different rules. An OBS-on-Ubuntu guide from Vultr is an example of one possible arrangement, not evidence that every YouTube stream should be encoded on a cloud host.
Prepare the Ubuntu host and recovery route
Before changing access controls, confirm the operating system and make sure you can recover the instance if your current SSH session stops working. Keep Vultr’s console access available and, if practical, retain an existing session while opening a second one to test your changes. Vultr’s Ubuntu firewall quickstart demonstrates UFW, but UFW is an Ubuntu example, not the firewall interface for every distribution.
Apply available security updates using the package manager appropriate to your Ubuntu release, and review whether a reboot is needed. Do not start firewall work while the host is in an unknown state: know the SSH port in use, know whether UFW is active, and inspect existing rules first. A pre-existing rule or a non-default SSH port can make a copied command misleading.
Run:
sudo ufw status verbose
sudo ss -tulpn
The first command reports UFW’s policy and rules. The second helps identify listening TCP and UDP sockets and the processes associated with them; it is a prompt to investigate, not a firewall configuration. A listener bound only to localhost is not necessarily exposed publicly, while one bound to all interfaces may be reachable if the network and firewall permit it. Confirm what each process does before deciding whether it belongs on the public network.
Treat the provider console and the host firewall as separate layers. A host-level UFW rule is maintained in Ubuntu; a provider-side network firewall, if you use one, is configured outside the guest. They can complement one another, but the rule locations and recovery paths differ. Do not assume that a rule visible in one place automatically exists in the other. Keep a record of the current rules and the specific changes you make.
Create and install an SSH key
SSH keys use a key pair: the private key stays on your workstation, and the matching public key is placed on the Vultr account or instance. Generate a key on the computer from which you will administer the host. For example, on a system with OpenSSH installed:
ssh-keygen -t ed25519 -C "vultr-admin"
Follow the prompts and protect the private key with a passphrase. The command creates a private key and a public key, commonly ending in .pub; share or install only the public key. Never paste the private key into a web form, ticket, shared document, or server configuration. If your organisation requires a different key type, follow its policy and the current Vultr and OpenSSH documentation.
The cleanest time to add your public key is when you deploy the instance, using Vultr’s deployment workflow. Vultr’s guide to connecting to a Cloud Compute instance with SSH describes key-based access. Pay attention to its warning about adding a key after deployment through the console: that operation can reinstall the instance and cause data loss. Do not use that route on a running host without understanding its consequences and preparing a backup and recovery plan.
If the instance already exists, do not assume there is a safe one-click way to attach a key through the provider console. Use the documented method appropriate to the current image and access state, such as installing the public key into the correct account’s authorized_keys while you still have working access. Check file ownership and permissions, and keep the existing access session open until a new key-authenticated login succeeds. If you cannot establish a safe method, consult Vultr’s current recovery guidance rather than risking a reinstall or lockout.
Test key access explicitly from your workstation, substituting the actual username, address and key path:
ssh -i ~/.ssh/id_ed25519 [email protected]
The example address is reserved for documentation and is not a server to connect to. Once the key works, review the SSH daemon’s password and root-login settings carefully before tightening them. Keep a verified administrative account and recovery method; a typo or an assumption about the image’s default user can otherwise leave you without ordinary access.
Restrict inbound SSH access carefully
SSH is an administrative service and should be reachable only by people who need it. A basic Ubuntu UFW rule for the default SSH port is:
sudo ufw allow OpenSSH
If your SSH daemon uses another port, allow that actual port and protocol instead. Check the SSH configuration and current listening socket before applying a rule. Do not enable UFW until you have allowed the port you will use and checked that the rule is in place. Vultr’s quickstart follows this important order: allow SSH, then enable the firewall.
Where your public source address is stable and you can reliably reach the host from it, narrow the rule to that trusted address. For example, if SSH listens on its default port, a UFW rule can be scoped as follows:
sudo ufw allow from 198.51.100.25 to any port 22 proto tcp
Replace the documentation-only address with your real trusted public address. If SSH uses a different port, change the rule accordingly. Vultr’s UFW guidance on restricting SSH to trusted IPs describes this approach. A fixed-address allowlist reduces which sources can attempt a connection, but a changing home connection, mobile network or travel can make it unusable. Have console recovery ready before narrowing access, and consider whether you need a second trusted address for a legitimate backup route.
If you move SSH to a non-default port, treat that only as a way to reduce routine automated connection attempts, not as a substitute for keys, updates or source restrictions. Add the new firewall rule before changing or restarting the daemon, test the new port in a separate session, and only then remove the old allowance. Keep one known-good session open throughout. The same caution applies if you change authentication settings: change one control at a time and test before closing your route back in.
Set inbound rules for the services you actually run
For the Ubuntu/UFW example, the intended policy is to deny unsolicited inbound connections by default, allow outbound connections by default, and add only explicit inbound exceptions. Before enabling or changing rules remotely, ensure the SSH rule above matches your real access path. If your existing policy differs, inspect it and plan the transition rather than blindly copying a sequence.
A typical policy baseline is:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw status verbose
Review the result before enabling UFW for the first time. If you have a known SSH port or a source-limited rule, preserve that exact allowance rather than adding a broader one without reason. Then enable UFW when your recovery route is ready:
sudo ufw enable
sudo ufw status verbose
If the firewall is already active, edit and reload rules with care, and check the status after each change. You can consult Vultr’s troubleshooting guidance if a rule interrupts access; its advice includes using console recovery when SSH is no longer reachable.
The service exceptions depend on the topology. A relay may need an inbound listener for a separately configured encoder to send media to it. Determine the protocol, port, source addresses and authentication settings from the relay’s own documentation, and restrict sources if the workflow permits. A host serving a web interface may need web ports, but only if that interface is deliberately public. An encoder that connects outbound to YouTube does not, by that fact alone, need a public inbound RTMP port. Avoid opening a wide range “for streaming” without identifying the corresponding service.
| Choice | What it changes | Practical trade-off |
|---|---|---|
| Host firewall only | Rules are applied in Ubuntu with UFW in this example. | Easy to inspect from the instance; a mistaken rule can interrupt SSH, so keep console recovery available. |
| Provider/network firewall as well | Rules are managed outside the guest, if you choose to use that layer. | Can provide a separate boundary, but you must understand its own rule scope and recovery process. Do not assume it replaces host rules. |
| SSH allowed from any address | Any source can attempt to reach the SSH listener, subject to authentication. | Convenient when your source address changes; it exposes the login service more broadly. |
| SSH restricted to trusted IPs | Only the chosen source address or range can reach the listener through that rule. | Narrows exposure but can lock you out when travelling or when your ISP changes your address. |
| Local encoder to YouTube | The encoder sends RTMPS outward; no media listener on Vultr is implied. | Fewer inbound services on the host, but the encoder machine and its internet connection must remain available. |
| Vultr-hosted relay | An encoder may send media inward to a relay, which then forwards it. | Adds a listener and another component to maintain; the required port and source scope depend on the relay design. |
Use the table to ask what your architecture needs, not to infer a universal set of open ports. The least-exposure rule is simple: a firewall exception should map to a named service, a documented port and a known set of clients. If a stream can run without an inbound listener on the host, leave that listener closed. For a broader look at the difference between processing and forwarding video, see how live video transcoding works.
Keep the YouTube RTMPS connection outbound
YouTube recommends RTMPS for the encoder-to-YouTube leg. YouTube Help explains that RTMPS is RTMP protected with TLS/SSL and instructs streamers to copy the RTMPS URL and stream key from Live Control Room into an RTMPS-capable encoder. Use the exact connection details YouTube provides for your stream, rather than guessing an endpoint or reusing an old key.
With the default Ubuntu UFW policy above, outbound traffic is allowed. That is a broad default, not a statement that every network or organisation will permit every destination. If you have a restrictive outbound policy at the host or provider layer, make sure the encoder can establish the documented RTMPS connection. YouTube’s setup guidance identifies port 443 as a troubleshooting option when SSL connection troubleshooting requires it. Port 443 in this context is for the encoder’s outbound connection; it is not a reason to open an inbound RTMP listener on the Vultr host.
Keep the stream key as carefully as a password. YouTube says stream keys are like the stream’s password and address. Do not put one in a screenshot, public repository, shared command history or a configuration file that other users can read. Use the encoder’s credential-handling options where available, and check logs or support bundles before sharing them. If you think a key has been exposed, reset it in Live Control Room and update the encoder that uses it.
Outbound reachability and stream quality are separate questions. A firewall can allow the connection while the encoder is configured incorrectly or the host’s available upload capacity is insufficient. Test the stream before relying on it and watch YouTube’s stream health indicators. Our guide to keeping a YouTube stream from going offline covers continuity planning beyond firewall access.
Verify access without exposing extra ports
After a change, verify from the same network and account you expect to use in production. Open a fresh terminal and establish a new SSH connection with the intended key and port while leaving the original session available. If you restricted SSH to a source address, test from that address. A successful existing session alone does not prove that a new login will work.
On the host, inspect the rules again with sudo ufw status verbose and compare them against your list of named services. Confirm that the intended process is listening on each service port, and that no unplanned listener appeared after installing or configuring software. If a relay or panel is part of the design, test it from its intended client rather than opening it to all addresses just to make a test convenient. Remove temporary broad rules as soon as a planned test is complete.
For the YouTube leg, start a private or otherwise appropriate test stream using the encoder’s RTMPS settings and check that the connection reaches YouTube. If it fails, distinguish a DNS or outbound network problem from an authentication issue, a wrong key, or an encoder configuration issue. Do not solve a failed outbound connection by exposing inbound ports: first verify the URL and key in Live Control Room, the encoder settings, and any outbound restrictions.
Keep a short change record with the prior rule, new rule, reason, test result and recovery method. This is useful when a stream fails later or another administrator takes over. It also makes it easier to remove a port that was opened for a temporary migration and forgotten. A small, current ruleset is easier to reason about than a collection of exceptions added during separate incidents.
For an always-on channel, the operational burden is not just keeping one connection open: the encoding computer, network and credentials all matter. When the recurring problem is that a local machine must stay switched on to keep a file-based channel running, StreamNeo removes that particular burden by taking an uploaded video and running it as a YouTube stream without your computer remaining on. It does not change what ports your Vultr host needs, and it is YouTube-only.
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
Do I need to open an inbound RTMP port for YouTube Live?
Not merely because you are sending a stream to YouTube. In the common encoder-to-YouTube arrangement, the encoder initiates an outbound RTMPS connection; open an inbound media port only if your particular relay or ingest design runs a listener that needs it.
Which ports should I allow for YouTube live streaming?
There is no universal inbound port list for every topology. Allow SSH on the port you actually administer through, and add a service port only when the software on the Vultr host requires it; RTMPS is generally the encoder’s outbound connection to YouTube, with port 443 an option in the documented SSL troubleshooting context.
Can I add an SSH key to a Vultr instance after deployment?
You can install a public key through an appropriate method when you still have access, but do not casually use a provider-console action that may reinstall the instance. Vultr warns that applying a key through its console after deployment can cause data loss; read its current instructions and prepare a backup and recovery route first.
What should I do if my YouTube stream key may have leaked?
Treat it as a compromised password: reset the key in YouTube Live Control Room and update the encoder with the replacement. Check whether the old key appeared in screenshots, shared files or logs, and avoid posting the new one in places other people can read.