If you are choosing between Hetzner Cloud and a dedicated server for a nonstop YouTube video stream, first decide whether the machine will only relay an already encoded feed or also encode video. Then compare the exact region’s traffic allowance, CPU behaviour, sustained network path and recovery plan; neither a traffic allowance nor an uplink specification guarantees an uninterrupted broadcast.
A relay-only workload can be modest and steady, while live encoding adds a continuous CPU or hardware-encoder workload that needs testing on the actual configuration. Cloud capacity is easier to resize, whereas a dedicated server may suit sustained workloads and, under Hetzner’s standard root-server policy, offers a different traffic arrangement. The right choice depends on your feed and the terms of the precise plan, not on the label alone.
Decide whether the server relays or encodes
A relay receives a feed that has already been encoded and forwards it to YouTube. For example, a computer in your studio might encode a devotional playlist and send it to a remote server, which maintains the outbound connection to YouTube. In that arrangement, the server’s main work is moving packets and keeping the relay process alive. CPU demand is usually less central than it would be for encoding, though the actual software, input format and number of feeds still matter.
An encoding server reads source video and audio, then compresses them into the format and bitrate you send to YouTube. A continuous 1080p feed, a more demanding codec, or several simultaneous outputs can change the CPU load substantially. There is no universal CPU threshold for a particular resolution: measure your encoder with your own media and settings rather than assuming that a plan name predicts performance.
Hetzner describes its shared CX, CPX and CAX cloud resources as having baseline CPU performance with temporary bursts. That can be appropriate for a light relay or a workload whose demand varies, but sustained encoding is a different test from a short successful start-up. Hetzner describes CCX as providing dedicated CPU resources and continuous, predictable high CPU performance. It is worth evaluating when you need more predictable CPU without leasing a whole physical machine. Check Hetzner’s cloud server documentation for current product distinctions.
Do not confuse an uninterrupted encoder process with a healthy YouTube broadcast. The source file can stall, the relay can lose its input, the route can change, YouTube ingest can have a problem, or the stream key or settings can be wrong. YouTube advises testing before starting and checking stream health, so treat the host as one part of an operating plan, not as a continuity guarantee. If the source is a playlist, planning scheduled playlist changes with systemd timers is relevant to the playback side, but it does not replace monitoring the stream itself.
Compare Hetzner Cloud traffic by region and plan
Traffic allowances are tied to the region and plan. Hetzner’s published documentation lists 20 TB included for EU CX, CPX and CAX cloud servers; US and Singapore allowances vary by plan, and CCX allowances also vary by plan and region. Do not carry the EU figure over to another data centre or assume that all cloud families share the same allowance. Before ordering, open the current traffic terms for the exact plan and location you intend to use.
Cloud overage is billable. Hetzner’s cloud billing documentation says traffic beyond the included amount is billed in 100 MB blocks. Notices at 75% and 100% of the allowance are notifications, not caps: reaching the allowance does not by itself mean your stream is automatically stopped, and it does not mean additional usage is free. The practical consequence is that a stream with a stable bitrate can create a predictable bill, provided you estimate usage and account for traffic beyond the included amount.
A cloud instance can be a useful fit when you want to select a region, start with a smaller configuration, or change the instance as the workload becomes clearer. But flexibility does not remove the need to review the traffic line on the plan. A regional allowance that covers your expected use on paper can still leave little room for test streams, alternate feeds or other outbound traffic on the same account.
Keep separate notes for compute and traffic. A plan may have enough CPU for a relay but an allowance that is inconvenient for a high-bitrate feed. Conversely, an allowance can be ample while shared CPU performance is unsuitable for continuous encoding. Make a small comparison table with the location, instance family, current monthly charge, included traffic, overage rule and whether CPU is shared or dedicated. Update it from the vendor’s live pages before committing; the published figures and prices can change.
Compare OVHcloud Public Cloud allowances
OVHcloud Public Cloud is a separate product category from both Hetzner Cloud and OVHcloud VPS. Public Cloud compute resources and their traffic conditions should be assessed using the relevant Public Cloud product and location terms. Do not use an allowance described for Public Cloud as though it automatically applies to an OVHcloud VPS, or vice versa.
For a fair comparison, identify the Public Cloud region and instance you would actually deploy, then confirm the current outbound traffic allowance and what happens when it is exceeded. Compare that with the Hetzner plan in its intended region, not with a different geography chosen only because its allowance looks more generous. The same discipline applies to currency and billing period: compare the actual monthly commitment and any variable traffic charges using the provider’s current terms.
Public Cloud may be worth evaluating if its chosen location or configuration fits your route and workload. The decision still requires a realistic traffic estimate and a test of the stream path. Do not infer that an allowance means the service can carry a given sustained bitrate at all times; a quota is a billing term, while network capacity and route performance are separate questions.
For encoding, compare compute characteristics as well as the traffic line. Test the chosen instance under the intended codec, frame rate and bitrate. For relay-only use, a smaller compute shape may be adequate, but a long-running process and consistent route still need supervision. An attractive hourly or monthly figure without a check of sustained use, transfer terms and recovery effort does not tell you the operating cost of a nonstop channel.
Keep OVHcloud VPS terms separate
OVHcloud VPS is another distinct product, with its own plan descriptions and conditions. If you are considering it, use the current VPS page and contract terms rather than borrowing a Public Cloud traffic figure. The name “cloud” in a general conversation is not a reliable guide to which service’s allowance or performance description applies.
A VPS can appeal when you want a virtual machine with a simpler fixed configuration. It may also be a reasonable place to run a relay if the actual connection and service limits fit your feed. For encoding, the relevant questions remain: what CPU resources are available in sustained use, how does the provider describe them, and does your real encoder perform reliably at the chosen settings? Verify those details for the individual VPS offer; do not assume they match Public Cloud or Hetzner CCX.
Make the product category explicit in your worksheet. Write “OVHcloud VPS” or “OVHcloud Public Cloud” in the heading, along with the exact plan, region and date you checked. This small habit prevents a common comparison error: placing a VPS allowance beside a Public Cloud price or feature and treating them as one package. Where a vendor page is unclear, ask the provider to confirm the specific plan terms before relying on them for a channel that runs overnight.
Estimate the feed’s monthly data needs
A useful first estimate starts with the bitrate you actually send, not the video file’s size or the resolution label. Multiply the outgoing bitrate by the hours the channel is live, then convert bits to bytes. At a steady 10 Mbps, the stream sends about 1.25 MB each second before protocol overhead. Across a 30-day month of continuous operation, that is roughly 3.24 TB in decimal units. This is an estimate, not a promised usage figure; audio, transport overhead, reconnects and other outbound services add to it.
YouTube’s encoder guidance gives recommended H.264 examples of 10 Mbps for 1080p30, 12 Mbps for 1080p60 and 6 Mbps for 720p60. Those are examples from YouTube’s settings guidance, not mandatory settings for every channel or codec. Check the current YouTube encoder settings and choose a bitrate suited to your content, encoder and connection. A static devotional image with music may not need the same visual settings as a moving local news loop.
For rough planning, use this relationship: monthly decimal terabytes are approximately bitrate in Mbps multiplied by 0.324 for a 30-day continuous stream. Thus a 6 Mbps feed is around 1.94 TB per month; 10 Mbps is around 3.24 TB; and 12 Mbps is around 3.89 TB. These values assume an unvarying stream for the entire month and omit overhead, so allow margin rather than selecting a plan at the calculated edge. If you stream fewer than 24 hours each day, multiply by the fraction of the day you are live.
A relay generally sends one outbound copy to YouTube regardless of how many viewers watch, because YouTube distributes the stream to viewers. The relay’s transfer estimate is therefore based on its feed to YouTube, not the audience’s total viewing hours. A server that distributes multiple destinations or performs additional tasks can have a different transfer profile, so include all outbound feeds and services in the estimate.
YouTube recommends leaving bandwidth room rather than filling the available upload capacity. Its networking guidance recommends about 20% headroom, which is particularly relevant when you are sending from a local encoder to a server or directly to YouTube. This is about usable capacity on the sending path; it is not a traffic allowance, and it does not reduce the monthly bytes your stream sends. For a practical checklist on your originating connection, see YouTube live settings for a slow internet connection.
Check bandwidth and route for the selected region
A published port speed describes a link characteristic, not the speed your particular stream will sustain to YouTube’s ingest. The route depends on where the server is, how traffic is routed at that time, and where the selected YouTube ingest point is reached. A region nearer to you is not automatically the best region for the outbound route, especially if the purpose of the server is to feed YouTube rather than serve local viewers.
Test from the exact region and configuration you plan to keep. Send a private or otherwise non-public test feed using the intended bitrate and watch the YouTube Live Control Room’s preview and stream health. Look for dropped frames, unstable upload throughput, audio interruptions and reconnects over a meaningful observation period. A short test can reveal basic settings problems, but it cannot prove that a route will remain unchanged or that a service will never be interrupted.
Hetzner states that standard dedicated root servers have a dedicated 1 Gbit/s uplink by default and unlimited traffic under its published policy. The 10 Gbit/s uplink option has a different policy: 20 TB is included and additional traffic is charged. These are not interchangeable descriptions. Confirm the specific model and uplink on the current product page, and read the current traffic policy before relying on the word “unlimited”. Hetzner lists the AX42 with a 1 Gbit/s port and minimum network availability of 99.9% on its AX42 product page; that product-page figure is not a guarantee that a YouTube stream will never break.
If you host an FFmpeg relay yourself, process supervision and recovery matter too. A process can exit because of a bad input file, an expired key, a network reset or a software error. Configure logging and restart behaviour, then rehearse what happens when the input disappears and returns. The practical lessons in keeping an FFmpeg YouTube stream running with systemd on Hetzner can help with the process-management side, but a restart policy cannot solve every source, route or ingest failure.
Choose based on workload and cost
A decision table can narrow the options, but use it as a screening tool. Traffic and price terms change, and the server class that appears economical may be poor value if it requires time-consuming recovery or a second machine to meet your operational needs.
| Your priority | Option to evaluate | What to verify |
|---|---|---|
| A light relay, flexible sizing or a preferred cloud region | Hetzner Cloud shared plan | Region-specific traffic, overage charges, CPU baseline and measured relay stability |
| More predictable CPU without a physical server | Hetzner CCX | Exact regional traffic allowance, current price and encoding or relay performance under your load |
| Sustained workload with a large traffic requirement | Hetzner standard dedicated root server | The model, location, 1 Gbit/s default uplink and current unlimited-traffic policy |
| A 10 Gbit/s dedicated-server port | Hetzner 10 Gbit/s option | The separate included allowance and overage terms, rather than assuming standard-root-server traffic terms |
| A non-Hetzner location or configuration | OVHcloud Public Cloud or VPS, assessed separately | Product category, region, current allowance, sustained resources and route to ingest |
For each candidate, add up the monthly server charge, expected traffic charge, storage or backup costs, and the value of your own maintenance time. Do not invent a break-even point from incomplete data: the research does not establish a universal cost at which cloud becomes more expensive than dedicated. Check the current prices for your precise configurations, and remember that a dedicated machine may offer useful capacity you do not need while a cloud plan may incur overage at your steady bitrate.
If you encode, the deciding test is whether the chosen CPU or other available encoding resource handles the exact stream continuously with room for other tasks. If you relay, pay closer attention to route stability, traffic terms, and simple recovery after an interrupted input. Where running and monitoring a machine yourself is the part most likely to fail overnight, StreamNeo removes that specific server-maintenance burden by turning an uploaded video into a YouTube live stream that can continue with your computer switched off. It is YouTube-only, so it is not a fit if your channel needs another destination or a custom server workload.
Whichever route you choose, test the whole chain before treating it as ready: media playback, audio, encoder output, stream key, route, YouTube preview, alerts and recovery. YouTube recommends testing the encoder and stream in advance and monitoring stream health; it also describes checking the preview and testing failover in its live-streaming tips. A provider’s network or traffic terms are planning inputs, not proof of continuous delivery.
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
Is Hetzner Cloud suitable for a 24/7 YouTube stream?
It can be, depending on whether it relays or encodes, the selected plan and region, and whether the CPU and route hold up under your actual workload. Check the region-specific traffic allowance and test the stream rather than treating cloud availability or bandwidth terms as an uptime promise.
Is a dedicated server better for a nonstop stream?
Not automatically. Hetzner’s standard dedicated root-server traffic policy differs from its cloud allowances, while dedicated hardware may be more capacity than a relay needs. Compare the precise model, location, uplink and workload, and include the effort required to monitor and recover it.
Does a 1 Gbit/s uplink mean the stream cannot drop?
No. It describes the dedicated server’s uplink, not a guarantee about the full route to YouTube or the encoder, source media and ingest. Test the intended path and prepare to detect and recover from interruptions.
Should I use Hetzner Cloud or OVHcloud for encoding?
There is no universal answer from the product labels alone. Compare the exact instance or VPS terms, CPU characteristics, region, traffic charges and current price, then benchmark the intended encoder settings. Keep OVHcloud Public Cloud and OVHcloud VPS terms separate.