A CPX12 is a reasonable low-resource starting hypothesis when a Hetzner Cloud VM only relays one feed that has already been encoded. It is not proof that the plan can encode a particular resolution or frame rate, and there is no official Hetzner benchmark that establishes such a limit.
The right server size depends first on whether the VM forwards an encoded stream or creates the encoded stream itself. Test the actual codec, resolution, frame rate, bitrate, number of feeds, network path and recovery process before treating any plan as suitable for an overnight or 24/7 channel.
Start by defining the workload
A relay receives a finished live feed and sends it to YouTube. The video has already been compressed, so the VM is mainly handling the streaming process, network traffic, connection management and any monitoring or restart logic around it. That is a different task from opening a video file, rendering frames, encoding them and then uploading the result.
For example, a devotional channel might have a pre-encoded feed produced elsewhere and use the VM only to forward it to YouTube. A local news loop might instead ask the VM to combine video clips, an overlay and audio, then encode the output continuously. Both are described casually as “livestreaming”, but their CPU requirements are not interchangeable.
Before choosing a plan, write down these answers:
- Is the source already encoded, or will the VM encode it?
- Which codec will be used, such as H.264?
- What resolution and frame rate will be sent?
- What video and audio bitrate will be used?
- Will there be one output or several simultaneous outputs?
- Will the VM also record, transcode, add graphics or run other applications?
- What should happen after a process, connection or VM restart?
If you are still deciding how to send a loop to YouTube, the practical distinction is also relevant to how to stream church sermons 24/7 with FFmpeg. FFmpeg can relay or encode depending on how it is configured, so its presence alone does not tell you how much CPU the job needs.
Do not use the target bitrate as a substitute for an encoder estimate. A bitrate describes the amount of data sent to YouTube. It does not describe the amount of CPU needed to create each frame, and it does not show whether a process will remain stable after hours of continuous work.
What CPX12 actually tells you
As listed in Hetzner’s July 2026 Cloud update for European locations, CPX12 has 1 vCPU, 2 GB of RAM and 40 GB of disk. The update announced availability in FSN1, HEL1 and NBG1. Hetzner describes this type of small plan for low-resource, single-purpose uses, but that description is not a video-encoding certification.
Those published specifications give you a starting point for a relay evaluation. They do not establish a supported resolution, frame rate, codec, number of streams or length of run. In particular, CPX12 should not be presented as proven adequate for 1080p, 720p, 30 frames per second, 60 frames per second or any other encoding target.
The disk figure also needs careful interpretation. A relay does not automatically need to store the video it is forwarding. Disk use could come from the operating system, application files, logs, temporary data or local recordings, but the available YouTube and Hetzner material does not establish a required disk size for a relay. Do not assume that all of the listed disk is needed by the live stream itself.
The same caution applies to memory. A simple relay may have modest memory needs, while a process that decodes media, maintains a large buffer, renders graphics and records locally has a different profile. Measure the complete application rather than assigning the entire requirement to the stream alone.
Hetzner’s current plan details, included traffic and prices can vary by location. Its published Cloud information should be checked for the selected region before you order or publish a cost comparison. Hetzner announced that updated prices for new Cloud orders and rescales apply from 15 June 2026, so an older plan table is not a reliable basis for a current decision. See the Hetzner Cloud update notes and the current product information for the region you intend to use.
When CPX12 is worth testing first
For one pre-encoded stream, CPX12 is worth testing when the VM has a narrow role: receive the feed, forward it to YouTube and recover if the connection or process is interrupted. This is an inference from the difference between relay and encoding work, together with the small published specification. It is not a Hetzner performance result.
A relay test should use the same source that you plan to run in production. If your final channel will carry a continuous bhajan video with a fixed audio track, test that feed rather than a silent placeholder. If the channel will contain changing scenes, captions or movement, include those conditions in the test. YouTube advises testing with representative audio and movement before starting a live stream.
During the test, observe the VM and YouTube separately. On the VM, record CPU use, memory use, network throughput, process restarts and any growing log or temporary files. In YouTube Studio, watch stream health, dropped frames, connection warnings and whether the incoming feed remains consistent.
A low average CPU reading is not enough by itself. A short burst during a reconnect, a log rotation or a source change can expose a weakness that is invisible in a brief idle run. Likewise, a process that stays alive but stops delivering usable media is not a successful relay.
Check recovery deliberately. Restart the streaming process, interrupt the source briefly if you can do so safely, and test what happens when the VM is restarted. YouTube states that a disruption in connectivity can mean a broken stream. Your operating plan therefore needs more than a server size: it needs monitoring, a restart method and a clear decision about how to respond when the broadcast is no longer healthy.
If the channel is built around a long playlist, do not assume that the player or process will recover in the same way as a live relay. The workflow in how to make a YouTube podcast live stream resume after a server restart is relevant because a 24/7 channel has to handle the restart case, not only the first launch.
If the VM must encode video
When the VM must encode, do not call CPX12 the best size. The available evidence does not prove that it can encode any particular resolution or frame rate, so the honest answer is to compare larger options under the real encoder workload.
Encoding means the VM must process frames continuously. The work changes with the codec, preset, resolution, frame rate, filters, overlays, audio processing and number of outputs. A single static image with a soundtrack is not the same workload as moving footage with animated text. Two channels at the same nominal resolution are not necessarily equivalent if one also renders graphics or produces several outputs.
YouTube’s official encoder guidance lists recommended H.264 ingest bitrates of 10 Mbps for 1080p at 30 frames per second and 17 Mbps for 1080p at 60 frames per second. These are settings for the feed arriving at YouTube, not measurements of the CPU required to create that feed. They should help you define the network and stream configuration, not select a VM by themselves. See YouTube’s live encoder settings and bitrates for the current guidance.
For an encoding test, fix the variables before comparing plans. Use the intended codec and encoder settings, the intended resolution and frame rate, the intended audio, and the same number of outputs. Run representative content for long enough to expose sustained CPU pressure and reconnection behaviour. A plan that succeeds with a short clip but falls behind during a continuous programme has not passed the production test.
If the encoder cannot maintain real-time output, the symptoms may include delayed frames, a growing queue, uneven motion, dropped frames or a process that consumes an increasing share of CPU. Changing the YouTube bitrate alone will not necessarily solve an encoder that cannot render frames quickly enough. You may need to change the encoder preset, output format, filters, number of outputs or VM size, but make one controlled change at a time.
The safest conclusion is therefore conditional: CPX12 can be evaluated for relay-only work, while encoding requires a measured comparison. Do not turn a small-plan specification into a resolution guarantee.
Shared and dedicated CPU options
Hetzner identifies its CCX instances as dedicated-vCPU plans. That makes them candidates when predictable CPU availability matters, especially for a continuous encoder workload. It still does not prove that a particular CCX plan can sustain your chosen codec, resolution, frame rate or number of outputs.
The larger CPX range provides another comparison path. These are shared-vCPU options, so a larger plan may provide more headroom for your process while still requiring a test under the actual workload. A dedicated-vCPU plan may be more suitable when variation in available CPU is a concern, but dedicated cores are not a substitute for checking the encoder’s measured demand.
Compare options across the whole job rather than counting vCPUs:
| Question | Why it matters |
|---|---|
| Relay or encode? | Encoding normally introduces sustained frame-processing work that a relay does not. |
| Shared or dedicated vCPU? | The CPU allocation model affects how you evaluate consistency, but neither model proves a video target. |
| Memory | The application, buffers, graphics and recording may need more than the relay itself. |
| Network path | The VM needs enough outbound capacity for the stream and YouTube’s recommended headroom. |
| Disk | Local recording, logs and temporary files change disk requirements; forwarding alone does not establish one. |
| Region and current allowance | Traffic limits and pricing depend on location and can change. |
| Recovery process | A 24/7 label does not create automatic recovery or high availability. |
For a single relay, starting with CPX12 may reduce unnecessary allocation while you collect evidence. For an encoder, compare at least one larger shared-vCPU plan with a dedicated-vCPU option that fits your budget and region, then measure. If the channel has multiple outputs, test them together rather than extrapolating from one stream.
You should also include the cost of operational complexity in the comparison. A cheaper VM that needs frequent manual intervention may be a poor fit for a small business owner who cannot watch it overnight. Conversely, a larger plan is not automatically better if the real problem is an unstable source, incorrect keyframe settings or insufficient network headroom.
Size the network separately from the CPU
YouTube recommends RTMPS, constant bitrate encoding and a two-second keyframe interval, with a maximum interval of four seconds. It also recommends leaving 20% upload-bandwidth headroom. These are stream delivery requirements and should be checked independently from CPU capacity.
For example, if your H.264 video setting is 10 Mbps for 1080p30, the VM’s available upload path must cover the total stream bitrate with the recommended headroom. If you use the 17 Mbps H.264 recommendation for 1080p60, the same principle applies at the higher rate. Include audio and any other outbound traffic in your planning rather than treating the video figure as the entire connection requirement.
The VM may be able to encode the video but still fail to deliver it consistently if the network path is congested or its allowance is unsuitable for the location. Conversely, a strong network does not make an under-sized encoder keep up with real-time frames. Keep CPU, memory, disk and network as separate checks.
YouTube’s streaming tips also explain why testing matters and warn that a connectivity disruption can break a stream. Treat stream health as an operational signal, not merely a dashboard to inspect after viewers report a problem.
If you are tuning an OBS-based workflow before moving it to a VM, the best OBS bitrate for a 24/7 YouTube stream can help separate bitrate decisions from the server-sizing question. The bitrate still needs to match your chosen content and YouTube’s current guidance, but it should not be mistaken for a CPU benchmark.
Test the complete 24/7 workflow
Create a test plan that answers whether the whole channel can run, not merely whether a command starts. Use the intended source, audio, overlays, encoder settings and output. If you will operate several feeds, run them together. If the production machine normally changes files or scenes, include those transitions.
Record at least these observations:
- CPU use over the sustained run, including peaks during transitions
- Memory use and whether it grows over time
- Outbound bitrate and any congestion or packet loss visible to you
- Encoder delay, dropped frames and process errors
- YouTube stream health and incoming bitrate
- Behaviour after a process restart and a VM restart
- Log, temporary-file and disk growth
- Whether the source reconnects cleanly after interruption
Do not claim success simply because viewers can watch for a few minutes. A 24/7 channel needs a repeatable procedure for starting, checking and recovering the broadcast. It also needs someone or something to notice when the stream is technically connected but no longer showing the intended content.
Keep a copy of the working configuration, but do not expose your stream key in scripts, screenshots or support messages. If you change the plan, region or encoder settings, repeat the relevant parts of the test. A rescale can alter the resource profile, while a new location can alter traffic and network assumptions.
For channels that change content while remaining live, the question is not only whether one file loops. It is whether the next item starts, the audio remains aligned, overlays appear correctly and a failed input does not leave a silent or frozen broadcast. A separate workflow such as keeping a YouTube podcast stream running while adding new episodes illustrates why content operations belong in the test plan.
What the available evidence cannot establish
The official material does not provide a benchmark mapping a specific Hetzner plan to a YouTube resolution or frame rate. It does not establish that CPX12 can encode a particular format, nor does it establish that a larger CPX or CCX plan will meet a target without testing. Avoid presenting a plan specification as a measured encoder result.
The sources also do not establish a universal disk requirement for relaying, a universal memory requirement for FFmpeg, or a universal network allowance that applies to every location. Prices, availability and included traffic can change. Check the current Hetzner plan and region when you make the decision, rather than relying on a copied table.
What the evidence does support is a practical sizing method. Separate relay from encode work. Use CPX12 as a low-resource relay hypothesis for one pre-encoded feed. For encoding, compare larger shared-vCPU and dedicated-vCPU candidates with the exact workload. Size the network using the intended bitrate and headroom, then test stream health and recovery.
That approach may lead to a larger VM, a different workflow or a decision not to encode on the Cloud instance at all. It is more useful than naming a universal “best” size, because the unresolved input is the workload itself.
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 CPX12 enough for one 24/7 YouTube stream?
It is reasonable to evaluate CPX12 first when one pre-encoded feed is only being relayed to YouTube. It is not proven adequate for video encoding, and the result still depends on the application, network path, monitoring and recovery process.
Can CPX12 encode 1080p30 or 1080p60?
The available official evidence does not establish that. YouTube’s 10 Mbps 1080p30 and 17 Mbps 1080p60 figures describe recommended H.264 ingest bitrates, not the CPU capacity of a Hetzner plan. Test the actual codec, settings and content instead of treating either figure as a server limit.
Should I choose CPX or CCX for encoding?
Compare a larger shared-vCPU CPX option with a dedicated-vCPU CCX option under the real encoder workload. CCX provides dedicated vCPUs according to Hetzner’s product information, but dedicated CPU alone does not prove a particular resolution or frame-rate result.
Does a 24/7 stream need a large disk?
Not necessarily. A relay does not automatically need to store the video, while local recording, logs, temporary files and other applications can increase disk use. Define those requirements separately and measure disk growth during a representative run.