A 24/7 YouTube stream on EC2 uses FFmpeg to send a media source to YouTube Live and systemd to supervise the FFmpeg process. EC2 supplies the Linux host, but a restart policy only helps when that process exits while the instance and its network remain usable; it does not guarantee an uninterrupted broadcast.
The practical work is preparing the channel and source, choosing an ingest profile the source and host can sustain, protecting the stream key, and deciding how you will detect faults that do not stop the process. Treat the setup below as an operating model to adapt and test, not as a deployment recipe proven on your account or instance.
Prepare YouTube Live and retrieve the ingest details
Your channel must be enabled for live streaming and verified before you can start. YouTube says first-time enablement may take up to 24 hours, so do not leave channel activation until the planned launch. Check the current YouTube live-streaming requirements and Live Control Room before building around a go-live time.
Create or select a stream in Live Control Room and note the ingest URL and stream key. The URL tells the encoder where to send the feed; the key identifies the channel’s publishing credential. Treat the key like a password. YouTube recommends RTMPS, the encrypted form of RTMP, but make sure you select the RTMPS endpoint shown for your stream rather than assuming a familiar RTMP address is interchangeable. See YouTube’s encoder settings and bitrate guidance and its explanation of RTMPS.
The stream is not ready just because you have copied those values. Confirm the stream’s privacy setting, title, category and other channel details, then use a private or unlisted test where appropriate. In Live Control Room, check that YouTube receives video and audio and that stream health is acceptable. A successful connection from FFmpeg does not prove that viewers see the intended picture, hear clean audio or receive a stable feed.
If you are unfamiliar with how the credential behaves, first read this guide to testing a YouTube stream key from an Ubuntu VPS. A test should use a key you control and should not expose it in a screenshot, public log or shared terminal history. If you suspect disclosure, an authorised channel owner or manager can reset the key in YouTube and update the encoder configuration.
Choose and prepare a Linux EC2 host
The basic path is local media on a Linux EC2 instance, FFmpeg reading that media, and an outbound connection from FFmpeg to YouTube’s ingest endpoint. For a fixed video loop, the media file must remain available and readable for the life of the service. Check disk space, file ownership and the source format before you enable an automatic restart; a supervisor cannot repair a missing or damaged input.
Choose an instance based on the work FFmpeg must do, not simply on the fact that it is a stream. Copying compatible audio and video consumes less processing than decoding, resizing and encoding them again. Transcoding, filters, high resolutions and multiple simultaneous outputs increase CPU demand and can change which instance size is adequate. Verify the actual workload with a controlled test rather than assuming a size from another channel will suit yours.
Plan the network path as well as the instance. The encoder initiates an outbound connection to YouTube, so a one-way live-streaming setup normally does not need an inbound RTMP port opened to the EC2 host. Keep inbound rules minimal: restrict SSH access to your administrator’s address range, or use an appropriate managed access method. AWS describes security groups as stateful, but you still need to verify outbound rules, DNS, subnet routing and any network ACL or host firewall rules. See AWS security group guidance.
Do not confuse “I can connect to the instance” with “the instance can publish to YouTube”. Establish the outbound path and name resolution before debugging FFmpeg. If your access method or networking policy changes later, include those dependencies in the operating notes so a restart after a maintenance change does not become an avoidable outage.
Configure FFmpeg for the source and YouTube
FFmpeg reads the selected input and writes an encoded or copied output to YouTube. Its command-line option order matters: most options apply to the next input or output, so an option placed in the wrong part of a command may not affect the stream you intended. Read the FFmpeg documentation for the installed build and verify that it supports the codecs and output protocol you plan to use.
Choose between stream copy and transcoding deliberately. Stream copy avoids decode and re-encode, which can reduce CPU work and avoid generational quality loss, but only works when the source codecs and properties fit YouTube’s ingest requirements. Transcoding is needed when you must change codec, size, frame rate, bitrate or apply a filter; it adds processing load and may introduce quality loss. The comparison is practical, not ideological:
| Approach | When it fits | Main trade-off |
|---|---|---|
| Stream copy | The file’s audio and video already suit the intended ingest profile | Lower CPU use, but little ability to fix incompatible properties |
| Transcode | The source needs resizing, filtering or a compatible output profile | More CPU and configuration work, with output quality dependent on settings |
YouTube currently lists RTMP and RTMPS ingest, H.264, H.265 and AV1 video, constant bitrate (CBR), and frame rates up to 60 fps for conventional SDR streaming. Its guidance recommends a two-second keyframe interval and says it should not exceed four seconds. Bitrate should be selected from the row for the codec, resolution and frame rate you actually use; do not copy a number simply because it appears in an example command. For H.264, YouTube’s current table recommends 5 Mbps for 1080p at 30 fps and 17 Mbps for 1080p at 60 fps; it also lists 8 Mbps for 720p at both 30 and 60 fps. Its table gives 128 Kbps stereo audio and a 44.1 kHz stereo sample rate. These are recommendations from YouTube’s page as accessed on 3 October 2026, not promises about quality or a substitute for selecting the correct table row.
A continuous feed also needs intentional source behaviour. A single file can end, have a short black gap or contain audio that is absent or too quiet. If you need to rotate multiple videos, a playlist approach has its own file-path and transition details; the article on automatic video changes in a 24/7 stream is relevant to that separate problem. Test the exact media and command in a private or unlisted session and watch the preview, including transitions and audio, before relying on it overnight.
Protect the stream key
Never put a real stream key in a public tutorial, a source repository, a world-readable service file or a command that may remain in shell history. A key allows publishing to your channel, so treat accidental exposure as credential compromise. YouTube provides a way for an authorised channel owner or manager to reset a compromised key; after a reset, update the protected configuration used by the service.
A systemd unit often needs to refer to the key somehow, but copying it directly into an ExecStart= line is not a sound default. The unit may be readable to administrators or visible through diagnostic tooling, and a key embedded in a script can be copied with that script. Use a restricted configuration or credential mechanism supported by the operating system and systemd version you actually run. Ensure only the service account and authorised administrators can read it, and avoid printing the resolved command or secret in logs.
Keep permissions and ownership as part of deployment, not as a later tidy-up. If the file is unreadable to the service account, FFmpeg may fail immediately and systemd may restart it repeatedly. Conversely, making it readable to every local user trades a small operational convenience for broader credential exposure. Document who can rotate the key and how to update it without publishing the secret to a ticket or chat.
Create a systemd service for FFmpeg
Run FFmpeg as the service’s foreground process. systemd can then track it as the main process, collect its output in the journal and apply a restart policy when it exits. Detaching FFmpeg into a shell background job obscures that relationship: the shell may exit while the encoder remains, or the service manager may be supervising the wrong process.
A unit file should express the service’s role rather than hide the command in an unmanaged login session. In broad terms, it needs a description, network ordering appropriate to the distribution, a least-privilege service user, an ExecStart= that invokes FFmpeg in the foreground, and an install target so an administrator can enable it at boot. The systemd manual describes Type=exec as tracking successful execution setup and recommends it for long-running services; check the systemd service documentation and your distribution’s unit conventions before choosing directives.
Keep the command readable enough to review: identify the input, relevant video and audio handling, any bitrate or keyframe parameters, and the output endpoint. Do not paste a real key into a public article or shared example. The specific unit syntax and credential delivery mechanism depend on the host’s systemd and operating-system versions, so validate those details locally. A plausible-looking unit is not evidence that the process starts correctly or that YouTube accepts its output.
After saving a unit, reload systemd’s configuration, start the service deliberately and inspect its status and journal. Run a controlled test that stops the process and confirms the expected recovery behaviour. Then inspect Live Control Room again. This checks several different links in the chain: systemd launching FFmpeg, FFmpeg reading the source, network delivery and YouTube receiving a usable signal.
Configure restart behaviour and reboot handling
A policy such as Restart=on-failure asks systemd to restart the service after an abnormal process exit. A measured RestartSec= delay can stop rapid retries from becoming a tight loop when the source path is wrong or the key has been reset. Choose and validate values for the workload rather than treating any particular delay as universally correct. If the service repeatedly fails, systemctl status and the journal help distinguish an execution error from a process that starts and then exits.
Enable the unit for the appropriate boot target if you want it to start after the EC2 operating system boots. That handles a normal instance reboot only to the extent that the instance comes back, the filesystem is present, networking becomes available and the service’s dependencies are satisfied. A reboot does not prove that FFmpeg reconnects successfully or that YouTube accepts the feed. Check the live preview after maintenance rather than assuming that an active systemd unit means an active viewer-facing stream.
The limit is important: systemd restarts a failed process, not every failed condition. It cannot fix an expired credential, a deleted source file, insufficient CPU, blocked egress, an account restriction, a stuck process that has not exited, a failed EC2 host or a regional event. A restart directive addresses one failure class while systemd and the host are still operating. It is not host redundancy, network failover or YouTube-side recovery.
Monitor process, host and stream status
Use at least three views of health. First, check process state with systemctl status and review the journal for repeated exits or FFmpeg errors. Second, watch host indicators that can explain a degraded encoder, such as CPU pressure, memory pressure, disk exhaustion and network availability. Third, confirm the stream itself in YouTube Live Control Room, where an apparently running process can still be sending invalid, frozen, silent or otherwise unhealthy media.
A process can remain alive while the broadcast is effectively broken. For example, a loop may keep running after its file becomes inaccessible or produce a picture while the audio mapping is wrong. A systemd restart policy does not react to every semantic problem in a live feed. You need an alert or a regular human check that compares service state with YouTube’s stream-health information, and a clear person responsible for responding when those checks disagree.
Test recovery with controlled failures before depending on the arrangement: stop FFmpeg and confirm the supervisor’s response; then test an ordinary reboot and verify the stream afterwards. Do not test by deliberately breaking the production key or network during an unattended broadcast. YouTube recommends preflight testing and monitoring stream health; follow the current encoder guidance and retain an operating note that says what a normal service state and a normal YouTube preview look like.
If you need viewers to see a continuing broadcast through a host or network failure, plan independent monitoring and a failover design. That design must itself be tested, including how two publishers avoid conflicting output and how the backup obtains the right source and credentials. A single EC2 instance supervised by systemd is a simpler arrangement, but it has a single host failure point.
Plan costs and failure limits
An always-running instance incurs ongoing EC2 compute usage while it is running. Storage and outbound data transfer can also affect the bill, depending on the region, instance, operating system, disk and amount of video sent. There is no useful flat monthly figure without those assumptions, and a bitrate choice affects transfer volume as well as the stream profile. Use AWS’s current EC2 pricing information and calculator for the region and configuration you are considering; account for the eligibility and geographic limits of any published transfer allowance.
Estimate the media workload before choosing a host. If a compatible source can be copied, CPU needs may be different from a stream that is decoded, filtered and re-encoded continuously. Do not size from an instance label alone: observe the chosen command during a representative test, then allow for the load and operational margin your actual workload needs. Revisit the estimate if you change resolution, frame rate, encoding settings or source processing.
Availability also has a cost. A single host is easier to understand than a redundant design, but it remains exposed to instance, region, network, source and account failures. A second path, independent alerting or a person on call can reduce some risks, but each introduces configuration and testing work and does not guarantee continuous delivery. Decide which interruption you can tolerate and what recovery time is practical before adding complexity.
Also separate “live for a long time” from “archived for later viewing”. YouTube’s encoder setup guidance says streams under 12 hours are automatically archived; that statement does not establish what will happen to an individual stream running longer than 12 hours. If an archive matters, design and validate a separate recording or segmentation approach and check YouTube’s current limits. For a broader view of the cloud-host trade-offs, see how an Oracle Cloud VM’s cost is assessed for a nonstop prerecorded stream; compare the cost inputs rather than assuming another provider’s bill predicts EC2 pricing.
If managing a Linux host, key permissions and process recovery is more work than you want for a fixed prerecorded channel, a managed workflow can remove the need to keep your own computer on and supervise that process. StreamNeo takes an uploaded video and runs it as a YouTube live stream after you provide the stream key; it does not remove the need to check the channel, file and stream health, 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
How do I keep FFmpeg running after I disconnect?
Run FFmpeg as the foreground process of a systemd service rather than starting it in an interactive SSH session or detaching it into a shell job. Once the unit is started, disconnecting from SSH does not itself stop the system service. Confirm the unit remains active and that YouTube receives a healthy stream; those are different checks.
How do I restart FFmpeg if it crashes?
Configure an appropriate systemd restart policy, such as Restart=on-failure, and a delay that avoids an immediate retry loop. Then use systemctl status and the journal to find why it exited. Restarting a process cannot correct a bad input, invalid key or unavailable network by itself.
Will my YouTube livestream stay live after an EC2 reboot?
The service can be enabled to start at boot, but that only asks systemd to launch FFmpeg once the host and its dependencies are available. You still need to confirm that the source is present, outbound networking works, credentials remain valid and YouTube accepts the feed. Check Live Control Room after a reboot rather than treating a running unit as proof of a live broadcast.
Does systemd make one EC2 instance highly available?
No. systemd can supervise a process on a functioning host, but it does not provide another host if the instance fails, repair a region or network outage, or detect every stream-quality problem. For stronger availability, build and test independent monitoring and failover, while recognising that no single restart setting guarantees uninterrupted streaming.