Yes, a Hetzner CAX ARM server can run FFmpeg for a 24/7 YouTube stream, provided you install an Arm64-compatible operating system, FFmpeg build and libraries. Whether a particular CAX size can encode your chosen video in real time is a separate question: test the exact workload rather than treating architecture compatibility as a performance guarantee.
There is also a separate cost calculation. Estimate outbound traffic from your actual streaming bitrate and runtime, then compare it with the allowance and overage rule for the specific product and region; bitrate alone cannot tell you the exact monthly charge.
How Hetzner counts traffic
For a continuous stream, the relevant quantity is data sent from the server to YouTube. A video encoder sends a sustained outbound feed, so its bitrate provides a useful way to estimate how much traffic the stream may consume over a month. It is an estimate of the stream component, not a complete prediction of the invoice.
Keep that distinction in mind when reading a plan page. The included traffic allowance, any charge for traffic above it, the region, and other server use can all affect the result. A server that sends one fixed stream is easier to estimate than a server that also serves downloads, websites or other users, but neither case turns a bitrate calculation into a bill quote.
A useful planning sequence is: identify the product and region, record its current included traffic and overage terms, calculate the stream's approximate monthly volume, then leave room for non-stream traffic and variation. Do not begin by assuming a universal Hetzner allowance. Check the relevant product details and billing terms directly before choosing a plan.
The distinction between a virtual machine and a hosted desktop may also matter for how you operate the channel, though it does not change the arithmetic of the video feed. If you are still deciding what sort of remote machine to use, the discussion of a cloud PC versus a VPS for a nonstop YouTube channel can help frame that choice.
Find the allowance for your product and region
Hetzner offers more than one cloud product family, and product details may vary with region and change over time. Find the current page for the exact service you intend to create. Record the included monthly traffic, the rules for traffic beyond that amount, and the region you selected. If the billing wording is unclear, check the official terms rather than filling in the gaps from an old forum post or a calculator for another product.
A compact planning sheet can prevent a common mistake: using a figure remembered from a different server, location or date. Keep the source and date alongside the allowance, and repeat the check when you change region or product. This is especially useful if you are comparing estimates several months apart, because a plan page is not a permanent promise of unchanged terms.
| Record | What to write down | Why it matters |
|---|---|---|
| Product | Exact cloud family and size | A figure for another product may not apply |
| Region | The location selected in the console | Availability and terms can differ |
| Included traffic | The current allowance, with source and date | This is the baseline for comparison |
| Overage rule | How excess traffic is charged, if applicable | The bill depends on the actual rule, not just a threshold |
| Other traffic | Any non-stream transfers to or from the server | The video is not necessarily the whole month's use |
The Hetzner cost-optimised cloud page describes the current product range and is a useful starting point, but check the selected product's live details and billing terms before relying on an allowance. Do not transplant an included-traffic figure from an older article or another region into your estimate without confirming it.
Hetzner's cost-optimised range is described for low-to-medium traffic workloads that can handle variable CPU performance. That description is relevant to the encoding question as well as traffic: you need to validate sustained performance, not assume that a low-cost shared-vCPU machine behaves like a dedicated encoder. Hetzner's current page should be consulted for product characteristics; no tier can be declared sufficient for your specific FFmpeg command from the name alone.
Estimate monthly stream volume from bitrate and hours
A bitrate estimate is straightforward if you keep units consistent. A megabit is not a megabyte: divide megabits by eight to convert bits into bytes, then multiply by the number of seconds the stream runs. For practical planning, a useful approximation is that each 1 Mbps sustained for a 30-day month sends about 324 GB in decimal units. This follows from the unit conversion and 30 days of runtime; it is not a Hetzner allowance or a bill prediction.
For example, a 10 Mbps feed running continuously for a 30-day month is approximately 3,240 GB of stream data in decimal units. If the stream is not on for the full month, use its actual planned hours instead. One way to calculate is:
bitrate in Mbps × 1,000,000 ÷ 8 × streaming seconds = bytes sent
Then convert bytes into the unit used by the provider's traffic accounting. Providers may display GB or another unit, and the exact accounting convention matters near an allowance boundary. Keep the raw calculation and the provider's unit definition together rather than rounding early.
Use the outgoing bitrate of the encoded feed, not the source file size, as the starting point. A looped video file can be relatively small on disk but produce a substantial continuous stream, because it is encoded and sent again throughout the month. Audio, protocol overhead, variable-rate behaviour and other server traffic mean the actual accounting may not exactly match a simplified video-bitrate calculation.
For a range rather than a single estimate, calculate at the intended bitrate and a plausible higher operating figure, and also use the actual number of hours you expect the broadcast to be live. The higher case is a planning buffer, not a claim that the stream will always use that much. Revisit it if you change resolution, frame rate, encoder settings or schedule.
Apply the overage billing rule
Once you have the estimate, compare it with the included traffic for your precise product and region. If the estimate is below the allowance, that still does not prove the final total will be below it: include other usage and the possibility that the stream runs longer or at a higher bitrate. If it is above, apply the published overage rule to the excess only as that rule defines it.
Do not calculate an exact charge by multiplying an estimated stream volume by a remembered rate. First confirm whether the plan charges for excess traffic, how excess is measured, what unit is used, and whether the displayed price applies to the chosen region and current billing period. Every price or plan term can change; when citing one, attribute it to the vendor and date it, for example, “as listed on Hetzner's site in September 2026”. This article does not give a universal allowance or bill because the necessary plan and usage details vary.
A conservative budget can be more useful than a false-precision figure. Put the base stream estimate beside a higher-use scenario, then note the actual allowance and overage rule that you verified. If the upper scenario would be uncomfortable, lower the bitrate only if that still meets your picture and platform requirements, choose a different product after checking its terms, or consider a workflow that does not require you to operate a continuously sending encoder yourself.
That last option is not a claim that one approach is always cheaper. Your own local power, connectivity, time spent recovering faults, and acceptable picture quality also have costs. Compare the full operating arrangement you can actually sustain, not only one line on a cloud price table.
Understand 75% and 100% usage notices
A usage notice at 75% or 100% of an included amount is an alert about measured usage, not a throttle or a traffic cap. It should prompt you to inspect current usage and your remaining allowance, not lead you to assume that the stream will slow down or stop at that threshold. Read the provider's current explanation of notices and billing to understand what the message indicates for your account.
If a notice arrives earlier than expected, check the measurement period, the selected server and region, and whether other transfers are occurring. Compare the observed usage with the hours streamed and the configured output bitrate. A mismatch can be a clue that the stream profile changed, another process is sending data, or the usage period is not the one you assumed.
Treat the notice as an operational checkpoint. Recalculate using observed usage rather than relying only on the original estimate. If the channel must remain live, decide in advance what you will do if the estimated month-end total approaches the allowance or the expected bill becomes unacceptable. Do not wait until an alert to discover that nobody knows where to find the plan terms.
Use YouTube bitrate guidance with headroom
Your traffic estimate is only meaningful if you have chosen an output bitrate that makes sense for the picture. YouTube's live encoder settings guidance gives recommendations by codec, resolution and frame rate. For H.264, it lists 10 Mbps for 1080p at 30 frames per second and 17 Mbps for 1080p at 60 frames per second. Those are platform-side ingest recommendations, not evidence that a particular CAX server can encode the profile in real time.
The same guidance recommends constant bitrate (CBR), a two-second keyframe interval, and says not to exceed four seconds. It supports RTMP and RTMPS and recommends RTMPS. Check that your FFmpeg build, output format and chosen codecs support the settings you intend to use. If you need to change the ingest protocol, follow a tested process such as this guide to switching an encoder from RTMP to RTMPS without changing the stream key.
Choose the actual profile first, then use its bitrate in the monthly traffic calculation. Reducing bitrate to reduce traffic has a picture-quality trade-off, and the platform's listed minimum is not automatically a good target for every scene. A static devotional image with speech or music may behave differently in viewers' eyes from a detailed moving scene, even when the nominal resolution is the same. Test a representative section and judge the result on the devices your audience uses.
Allow network headroom as well. Your internet path needs to sustain the outgoing feed without being fully saturated by other activity, and the server should not be so busy encoding that it falls behind. For a persistent channel, monitor the actual stream health and the encoder's progress rather than assuming the configured bitrate tells the whole story.
Check Arm64 compatibility and sustained encoding
Hetzner's CAX family uses Ampere Altra Arm64 CPUs. Hetzner describes native Arm64 application support, but an application still has to be built for the machine's architecture. Select an Arm64 operating system and install an AArch64-compatible FFmpeg package or build with compatible libraries. Confirm the installed binary's architecture before configuring the live process.
Do not copy an install command solely because it appears on a Hetzner FFmpeg page. The example static download identified in the reviewed material is an amd64 build, which is a different architecture from CAX. The Hetzner server FAQ on Arm64-compatible ISO images illustrates why the operating system image must match the machine; it is not an FFmpeg installation recipe. Check the instructions for the specific OS and package source you use.
Compatibility is only the first test. Hetzner identifies CAX as shared-vCPU instances and describes the cost-optimised range as suited to workloads that can handle variable CPU performance. The researched official material does not provide a CAX-specific FFmpeg benchmark or certify a continuous stream at a particular resolution, frame rate, codec, preset or filter chain. Do not infer real-time performance from a vCPU count alone.
Run the exact input and command you plan to use on the intended instance. Observe whether FFmpeg consistently processes faster than real time, whether CPU use leaves room for variation, and whether the video and audio stay in sync over a sustained run. Include any scaling, overlays, denoising or other filters that will be in the real channel: a simple transcode test does not validate a heavier production command.
Then test recovery, not only the happy path. Check what happens when the network interrupts, YouTube ingest disconnects or the process exits. Use a process supervisor such as systemd or another suitable service manager, configure a sensible restart policy, and keep logs and resource monitoring available. These are operational choices you make; they are not guarantees of uninterrupted streaming from the provider.
If you would rather not keep a machine and FFmpeg process under your care, StreamNeo turns an uploaded file into a YouTube live stream, which removes the specific work of maintaining a continuously running encoder on your own server. It is YouTube-only, so it is not a substitute if you need a general-purpose machine or a different destination.
Compare estimates with actual usage
After going live, compare the plan with what the provider reports for the same billing period. Note the stream's start and stop times, configured bitrate, selected product and region, and any substantial non-stream traffic. That makes the next estimate more useful and helps explain why actual usage differs from the video-only calculation.
If the actual total is higher, investigate before changing the server size. Check whether the broadcast was running longer than planned, the output bitrate was raised, multiple streams were sent, or another application moved data. If it is lower, do not assume every month will match: a change in schedule or profile can shift the total. Keep a short record of the settings that were in use when you compare numbers.
For performance, also distinguish a network problem from an encoding problem. YouTube's guidance asks broadcasters to test beforehand with representative audio and motion and to monitor stream health and messages during the event. A preflight can reveal a bad key, an unsupported output setting, or unstable encoding before the channel depends on it. You can use the same discipline whether your source is a generated loop, a music programme or a longer video; this guide to running a 24/7 YouTube stream with OBS on Windows covers a different operating setup but shares the need to test the complete path.
A useful acceptance test has two separate results. First, the stream reaches YouTube with the intended settings and remains healthy during a representative sustained run. Second, observed traffic reconciles reasonably with the bitrate-and-hours estimate and the plan's accounting period. Passing one does not prove the other: a stable stream can exceed a traffic budget, while a cheap traffic estimate says nothing about encoder headroom.
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 FFmpeg work on Hetzner CAX ARM servers?
Yes, if the operating system, FFmpeg binary and required libraries are compatible with Arm64. A download or container built for amd64 is not automatically usable on CAX, so verify the architecture of each component before deployment.
Can a CAX instance definitely encode my 24/7 stream?
The available official material does not establish that a particular CAX size sustains a specified FFmpeg workload. Test your exact command and representative content on the intended instance, including recovery and resource headroom, before relying on it continuously.
How much traffic does a 24/7 stream use?
Calculate from the actual outgoing bitrate and the hours streamed, converting megabits to bytes and using the provider's accounting units. A monthly estimate for the stream is not an exact bill: product, region, allowance, overage terms and other usage all matter.
Do 75% and 100% notices stop or slow a stream?
Treat them as usage alerts, not throttles or caps. Check the current provider documentation and your account's measured usage to understand the notice, then compare it with your plan and remaining budget.