Restreamer can run in Docker on an Ubuntu VPS and publish a configured input to YouTube Live. A restart policy and persistent configuration help with recovery, but neither guarantees an uninterrupted stream or a complete YouTube archive.
The path is input feed → Restreamer on your VPS → YouTube Live. First decide what feed you will send: a camera or encoder, an existing stream, or another supported source. The setup below covers the host and YouTube connection; the exact input steps depend on that source.
What to prepare before you deploy
Choose a 64-bit Ubuntu VPS whose provider permits Docker. Restreamer’s official Linux installation documentation lists Ubuntu and a 64-bit Intel or AMD CPU among its requirements. It does not prescribe a universal VPS size, and the work the machine must do depends on whether it relays a compatible feed or has to process it. Check the official Linux installation guide for current requirements before provisioning.
Think through the stream path before opening ports. If another encoder sends a live feed, it needs a reliable route to the VPS. If the input is a file or playlist, confirm that the deployed Restreamer release and your chosen input method support the way you intend to play it. Do not assume that “24/7” means a file will loop, restart cleanly or survive a source interruption without configuring and testing those behaviours.
Estimate outbound bandwidth from the stream bitrate and how long it will run. A steady 5 Mbps feed, for example, needs at least that much sustained upstream capacity before network overhead and headroom; the data allowance also accumulates continuously. YouTube recommends allowing 20% headroom over the stream bitrate. That is a planning recommendation, not evidence that a VPS can sustain it. For a more detailed way to estimate transfer needs, see the cloud-hosted stream bandwidth guide.
If Restreamer will transcode, CPU capacity matters more than if it can pass through a compatible input. If you intend to record locally, include storage and backup capacity in your plan. The available documentation does not establish a single safe minimum for CPU, memory, disk or network: size for your source, output profile and host environment, then test under realistic conditions.
Keep the management interface private or protected, and make a recovery plan before the first long run. You will need access to the VPS, a way to check the YouTube preview and stream health, and a secure place to keep the YouTube stream key. Record the exact image and configuration you deployed so you can restore or reproduce the setup if needed.
Install Docker on Ubuntu
Use Docker’s current Ubuntu installation instructions rather than an old command copied from a tutorial. Package names and supported Ubuntu releases can change. Follow the Docker Engine installation guide for Ubuntu, then verify that Docker is installed and can run a test container before adding Restreamer.
A VPS control panel or cloud-init script may offer Docker installation, but check what it installs and how it receives updates. Avoid adding a third-party repository simply because an older guide uses it. The goal is a supported Docker Engine installation on your chosen Ubuntu version, not a particular one-line install command.
After installation, confirm that your account can administer Docker and that the daemon starts again after a host reboot. Docker access is powerful: anyone who can control the daemon may be able to control containers and access host resources. Limit shell access to trusted administrators, secure SSH access, and keep the system and Docker packages updated using the provider’s normal maintenance process.
The commands you use to launch Restreamer should come from the current project documentation, not an assumed tag or copied example. Images and configuration options can evolve. The Restreamer project repository and its installation documentation are the appropriate places to verify the current image name, available options and supported release.
Launch Restreamer with persistent directories
A container’s writable layer is not the right place for configuration you expect to retain. Mount host directories for Restreamer’s configuration and data so that those files remain available when the container is replaced. The project’s example uses /opt/restreamer/config and /opt/restreamer/data as bind-mounted paths; check the current documentation for the expected paths and permissions for the release you deploy.
Create the directories on the VPS, restrict their ownership and permissions to the account that needs them, and keep them out of public web roots. Back up the configuration directory, and decide whether any data directory contents need a separate backup or retention plan. A persistent volume is not a backup: deletion, disk failure, a mistaken update or a compromised host can still remove or expose its contents.
The project examples include a Docker restart policy such as --restart=always. This tells Docker to try to start the container again after certain exits or daemon restarts. It does not repair a bad configuration, restore an inaccessible input, fix a full disk, or reconnect successfully to YouTube in every case. Use the restart behaviour documented for the version you deploy, and test it rather than treating it as an uptime commitment.
Follow the launch command in the current Restreamer guide, adapting only the host paths and ports you have decided to use. Avoid running an unpinned or unexplained command from an unofficial source. Note the image version, mounts, restart setting and port mappings you actually used. That record is useful when checking an update or rebuilding the VPS.
For a source made from pre-recorded video, the input and output profile still matter after the container starts. A playlist or concatenated file can have codec or transition issues that Docker cannot solve; review the FFmpeg concat troubleshooting guide if you are assembling a source from multiple clips.
Open only the required ports
A port mapping in Docker does not mean it should be reachable from every address on the public internet. The Restreamer project examples map ports for the web interface and for RTMP- and SRT-related traffic, but which ports you need depends on whether you use those functions. Verify the current port list against the documentation for your release; do not copy every example mapping without a reason.
Use the VPS firewall and any provider-level firewall together. Allow the web interface only from your own address or through an access-controlled HTTPS reverse proxy where practical. If a source sends RTMP or SRT to the VPS, allow only the relevant traffic and, where feasible, the source’s known addresses. YouTube publishing is an outbound connection from Restreamer, so the YouTube key does not require you to expose an inbound RTMP port to the world.
Restreamer’s older RTMP-ingest guide warns that an exposed, unprotected ingest port can allow others to push streams to your host. Its token instructions may not match current releases, so check the deployed version before relying on a particular syntax. If you do not need public RTMP ingest, leave that path closed. If you do, configure the current supported authentication and test that an unauthorised client cannot publish.
Secure the administrative interface separately from the YouTube connection. RTMPS protects the outbound connection to YouTube; it does not automatically encrypt or restrict access to Restreamer’s own web UI or an open input port. Use a strong, unique administrator password, HTTPS for a public-facing interface, and access restrictions. Do not put credentials in screenshots, shell history, public logs or a repository.
Configure a YouTube publication
In YouTube Live Control Room, create or select the live event and retrieve its current RTMPS server URL and stream key. YouTube recommends RTMPS, which is RTMP carried over TLS/SSL; use the URL YouTube gives you rather than guessing an endpoint. Read YouTube’s encoder stream settings and RTMPS guidance for the current instructions.
In Restreamer, configure the actual input first, then add a publication service for YouTube using the supplied URL and key. Labels and screens can differ between releases, so follow the UI and project documentation for your version. The key authorises publishing to the channel or event associated with it. Treat it like a password: do not share it with a source operator who does not need it, and reset it through YouTube Studio if it is exposed.
The output must be compatible with YouTube’s ingestion requirements and with the incoming source. YouTube’s guidance recommends H.264 video, CBR and a two-second keyframe interval (not more than four seconds) for its general encoder settings. For 1080p at 30 frames per second using H.264, YouTube recommends a 5 Mbps video bitrate. These are ingestion recommendations, not a guarantee of output quality or proof that the VPS can encode the stream at that rate.
Audio is part of the output profile too. YouTube’s RTMP/RTMPS guidance lists AAC or MP3 audio. Check that the source includes the audio you expect and that the publication profile sends it at a compatible setting. For a pre-recorded continuous channel, a bitrate that is too high can exhaust network capacity; one that is too low can make the picture visibly soft. The CBR versus VBR comparison explains the trade-off for a pre-recorded source.
Start and verify the live stream
Start with a controlled test, not an overnight unattended run. Confirm that the input appears in Restreamer, that its audio and video are correct, and that the publication reports a connection to YouTube. In YouTube Live Control Room, check the preview and stream health before making the event public or relying on it for viewers. A green status at one moment only confirms the path at that moment.
Test the path end to end from the same source and output profile you plan to use. Watch for dropped frames, audio/video mismatch, a frozen source, or repeated reconnects. Compare actual outbound use with the bitrate and headroom you planned for; check both the operating system and the VPS provider’s transfer reporting. If the connection is marginal, reduce the bitrate or choose a host with appropriate sustained transfer and network capacity rather than assuming a restart will cure it.
For a channel that plays a sequence of videos, verify transitions, loop behaviour and what happens when the final item ends. A playlist feature or input may not behave the same way as a separate encoder feeding a live source. The guide to using a YouTube playlist as a livestream source can help clarify that distinction, although it describes a source workflow rather than a guarantee about Restreamer’s playlist handling.
Also test a deliberate recovery: restart the container during a maintenance window and verify whether the configured source reconnects and the YouTube event resumes as you intend. Then test a host reboot if safe to do so. A container returning to a running state is not enough; the source, publication and YouTube event all need to be healthy. If your channel depends on continuous availability, have someone or an external monitoring service check it and define what action to take when an alert arrives.
Plan for recovery and long-running archives
A long-running stream has several separate failure points: the source can stop, the container can exit, the VPS can lose network access, the provider can schedule maintenance, or YouTube can interrupt the ingest. Docker’s restart policy addresses only a narrow part of that chain. It does not provide a backup source, failover host, monitoring response or service-level availability commitment.
Write down a recovery sequence that another trusted person can follow: check the input, inspect container status and logs without exposing secrets, check VPS resource and network health, confirm the YouTube event state, then restart or reconnect only where appropriate. Back up the configuration securely and test restoring it. If the stream is business-critical, consider a separate source or failover arrangement, but test how it behaves with your event and account before depending on it.
Do not infer archive completeness from an apparently healthy live stream. YouTube Help says streams under 12 hours are automatically archived. That statement does not establish that a continuous stream longer than 12 hours will produce a complete archive, nor does it establish that longer streams are never archived. Check the current YouTube live-stream archive guidance before planning around a recording.
If you need a complete record, arrange a separate recording and segmentation plan that you have actually tested. Decide where recordings are stored, how segments are named and checked, how much storage is available, and how you will notice a recorder failure. A VPS that relays a stream is not automatically a verified recorder, and a local recording can still stop if storage fills or the process fails. Keep a copy outside the VPS if the material matters.
A simpler operating model may be preferable if you do not want to maintain Docker, firewall rules, backups and recovery checks yourself. StreamNeo removes the specific need to leave your own computer running to send an uploaded video continuously: you upload the file and provide your YouTube stream key, while it runs the broadcast from the cloud. It is YouTube-only, and you still need to check the content, key and channel settings yourself.
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
Can Restreamer run continuously after I close my laptop?
Yes, if Restreamer and its input run on the VPS, your laptop does not need to remain on for that VPS process to continue. That does not guarantee the VPS, source or YouTube connection will remain healthy, so monitor the stream and test recovery.
Which ports should I open?
Open only the ports required for the features you actually use, and verify the current mappings in the Restreamer documentation for your version. Restrict the web interface and any ingest port; an exposed RTMP input can be abused if it lacks effective access controls.
Does the restart policy guarantee a 24/7 stream?
No. It can ask Docker to restart a container, but it cannot fix a bad input, a full disk, an upstream network outage or a YouTube-side interruption. Test container and host recovery and arrange monitoring appropriate to the channel.
Will YouTube keep a complete archive of a continuous stream?
The cited YouTube guidance confirms automatic archiving for streams under 12 hours; it does not confirm a complete archive for a continuous 24-hour broadcast. If a full recording matters, verify current YouTube guidance and maintain a separately tested recording plan.