For a 24/7 YouTube loop, compare the outbound traffic allowance and billing for the exact Vultr or Hetzner plan and location you intend to use, then test your actual FFmpeg workload. Neither provider’s headline traffic figure applies universally across all plans and regions, and neither tells you by itself whether the server can encode your stream smoothly.
Start with your intended video bitrate and monthly runtime. Then check the provider’s current terms for that particular server family, region, public IP and any excess traffic; the documentation figures below are useful comparison points, not guarantees of current terms.
Compare the exact plan and location
A continuous stream sends data out of the server to YouTube for as long as it is running. That makes outbound transfer a sensible first comparison, but only after you have selected a specific plan and location. A large allowance on a European Hetzner plan is not a like-for-like comparison with a US plan or a Vultr instance in a different data centre.
The cited provider documentation describes different ways of expressing those allowances. Vultr documents a monthly per-account bandwidth allocation, together with instance bandwidth that accrues hourly. Hetzner’s traffic table lists amounts by Cloud Server family and region: it shows 20 TB for EU CX, CPX and CAX Cloud Servers, while its US and Singapore allowances vary by plan. Treat those as documentation values, not universal entitlements. Check the relevant live product page and billing terms before you create a server.
| Comparison point | Vultr Cloud Compute | Hetzner Cloud | What to verify for your choice |
|---|---|---|---|
| Traffic allowance | The cited Vultr documentation describes 2 TB of free bandwidth per account each month, plus instance bandwidth accrued hourly. | The cited traffic table lists 20 TB for EU CX, CPX and CAX; US and Singapore allowances differ by plan. | Confirm which amount applies to your plan, account, family and location now. |
| Traffic direction | The cited usage policy counts outbound transfers; inbound traffic is not metered under that policy. | Hetzner’s cited Cloud FAQ describes outgoing traffic as billable and incoming and internal traffic as free. | For a one-way encoder feed, model outbound traffic, while checking how your current plan defines it. |
| Excess traffic | The cited Vultr page lists $0.01 per GB beyond allocated quota. | Hetzner’s cited FAQ describes over-usage billing in 100 MB blocks; check the current product terms and price list for the rate. | Estimate expected transfer and find the current excess-traffic charge before relying on an allowance. |
| Other costs | Regional pricing can vary, and the full total depends on the selected instance and services. | Server charges, public IPs and optional services can affect the total. | Compare the running monthly total, not only the headline server price. |
The figures in this table come from provider documentation with different update histories. Hetzner’s cited traffic page was last changed in 2024 and its Cloud overview in 2022; the cited Vultr billing pages were updated in December 2025. They are not matched current quotes. Check the provider’s current terms for your precise combination before treating any figure as a budget.
Location matters for more than the allowance. Consider where you will upload source files from, whether the server’s region works for your intended YouTube ingest route, and whether the connection is stable enough for the feed. If you need to understand the remote-server workflow before choosing, the guide to looping a YouTube livestream with FFmpeg and a remote Linux server can help frame the setup.
Understand Vultr bandwidth allocation
Vultr’s cited documentation describes two parts to its bandwidth allocation: 2 TB of free bandwidth per account each month, and instance bandwidth that accrues hourly. The practical implication is that you should not assume one account-level headline is the complete allowance for a particular running instance. Check the current allocation displayed for the instance and how it is combined with the account allocation.
The cited Vultr overage page lists a charge of $0.01 per GB for bandwidth beyond the applicable quota. Do not turn that into a universal cost estimate without checking the current policy and how Vultr measures the usage for your account. A small difference in the bitrate you configure, an additional simultaneous stream, or a second output can change the amount sent over a month.
Vultr says the cited policy counts outbound transfers while inbound traffic is not metered. For a typical FFmpeg-to-YouTube feed, your ongoing stream is outbound from the VPS, so that is the direction to estimate. File uploads are inbound, but a workflow that also sends copies to storage or another destination can have additional outbound traffic. Make a simple traffic list for the services you actually plan to run.
Regional pricing can differ. A server that appears inexpensive in one location may not be the cheapest equivalent in another, and the location may affect whether the route and allowance suit your use. Before purchase, note the exact data centre, instance type, operating system, public IPv4 or IPv6 choice, and any backup service. Revisit the price and bandwidth terms together rather than comparing just the plan name.
Vultr’s hourly allocation model also means the length of time the instance exists can matter, depending on the applicable plan terms. If you are testing several configurations, understand what continues to accrue during the test and what happens when you stop or delete an instance. A powered-off machine is not necessarily the same as a deleted one for billing purposes; use the provider’s current billing documentation for the exact rule.
Understand Hetzner regional allowances
Hetzner’s Cloud traffic table is organised by product family and location, rather than promising one provider-wide allowance. In the cited documentation, EU CX, CPX and CAX Cloud Servers are listed with 20 TB of included traffic. US and Singapore amounts vary by plan. Those distinctions make it important to check the row for your exact server family and region rather than repeating “Hetzner includes 20 TB” as if it applied everywhere.
Hetzner’s cited Cloud FAQ describes outgoing traffic as billable and incoming and internal traffic as free. That makes a single outbound YouTube feed relatively straightforward to model: calculate its monthly transfer and compare it with the allowance for the selected plan. If you run a backup feed concurrently, stream to another platform, or move outputs elsewhere, include each separate outbound flow.
The same FAQ describes over-usage billing in 100 MB blocks, but a block size is not a price. Consult the current traffic page, price list and plan details for the excess rate and for any conditions on traffic use. The traffic table’s update date is not evidence that every current product keeps the same terms; treat the table as documentation to verify against the offer you can actually order.
Hetzner’s Cloud FAQ says Cloud Servers have hourly pricing subject to monthly caps, and that charges continue while a server exists even if it is switched off. The precise amount depends on the server and selected services, so include expected run time and deletion behaviour in your comparison. If you are using a server for a trial encode, make a note to remove it when the test is finished if you do not intend to keep it.
Public addressing can change the total. Hetzner’s Cloud overview says public IPs are not included in server prices and identifies an additional IPv4 charge; verify the current charge and whether your selected configuration needs that address. Do not assume an IPv6-only configuration is suitable without checking the applications and network path you will use. Compare the complete monthly cost for the selected setup, including any backups, snapshots or other services, rather than the compute line alone.
Estimate transfer from stream bitrate
“How much bandwidth does an FFmpeg YouTube loop use?” is answered first by the output bitrate and runtime, not by the file size of the source video. If FFmpeg loops a video and sends a constant-bitrate stream, the outgoing data accumulates continuously. A rough decimal estimate is: bitrate in megabits per second multiplied by 0.45 gives gigabytes per hour; multiply that by 24 and then by the number of days you expect the stream to run. Treat the result as a planning estimate, not a precise invoice forecast.
For context, YouTube’s current encoder guide recommends 14 Mbps for H.264 1080p30 and 8 Mbps for H.264 720p30. Using the rough calculation, those are about 6.3 GB and 3.6 GB per hour respectively. At continuous operation for a 30-day planning month, they would be about 4.5 TB and 2.6 TB. Actual traffic can differ because of the encoder configuration, protocol overhead, runtime, variable bitrate behaviour and provider metering rules. Use the row for your actual codec and frame rate in YouTube’s encoder settings and bitrate guide, rather than copying a 1080p example for every stream.
If a backup feed is live at the same time, count it separately. Two concurrent feeds at the same bitrate send roughly twice the data of one feed. A failover that is genuinely idle until the primary drops should not be modelled as though both feeds are running continuously, but check how your setup behaves during tests and handovers. Also include any separate output that sends the same programme to another destination.
This transfer estimate lets you test an allowance without confusing it with compute capacity. A 720p stream that fits within a traffic allocation may still be too demanding for a small CPU if the server is encoding from scratch. Conversely, a server capable of encoding your chosen format does not make an allowance sufficient. Compare transfer and compute as separate questions.
YouTube also advises leaving upload headroom: its streaming tips say the total bitrate should not exceed the available upload bandwidth and recommend leaving room. That guidance concerns the connection delivering the feed, not a promise that a particular VPS has adequate network performance. Follow the current YouTube streaming tips and test the actual route and settings before relying on a long-running broadcast.
Include price and public IP costs
“Which VPS is cheapest for streaming to YouTube?” has no reliable answer until the comparison includes the exact region, plan, allowance and extras. Current matched-plan prices and FFmpeg performance were not established in the research for this article, so it would be misleading to name a winner on price. Open both providers’ current price pages for the intended locations and record the monthly cap or expected full-month charge, the traffic terms and any public IP charge.
For Vultr, account for the selected instance’s price and the applicable bandwidth allocation, then check the current charge if your projected transfer exceeds it. Regional variation matters, and a short test can have different costs from a full month depending on hourly billing and the services left in place. For Hetzner, include the server’s hourly rate and monthly cap, applicable traffic terms, and the public IP you need. Its cited overview says public IPs are outside the server price, so a bare compute quote may understate the total.
Use the same assumptions in both columns: a month of continuous operation, the same video bitrate, the same number of concurrent feeds, the same public addressing requirement, and the same backup choices. If one setup includes a service the other does not, show it as a separate line rather than hiding it in a vague “monthly cost”. Add a possible overage scenario based on your calculated transfer, but do not assume you will use every included gigabyte.
Also account for how you will operate the server. A machine that is inexpensive on paper can require time to configure FFmpeg, set up monitoring and respond to a stopped process. If you prefer a managed route that removes the need to keep your own computer running or recover a dropped broadcast manually, StreamNeo turns an uploaded video into a YouTube live stream that runs independently of your computer and is monitored and restarted if it drops. That addresses the ongoing process-management burden, but it does not remove the need to prepare suitable content or check YouTube’s requirements.
Test the FFmpeg workload
Can you run FFmpeg on a VPS? In general, a VPS can run FFmpeg, but the plan name does not tell you whether it can perform your particular job at the required output settings. Relaying an already encoded file is materially different from decoding and transcoding it, generating animated graphics, mixing audio, or producing several resolutions at once. CPU allocation, codec, resolution, frame rate and filters all matter.
No directly comparable FFmpeg benchmark for Vultr and Hetzner was established for this comparison. Avoid assuming that one provider is faster because of a brand, a product family or a specification alone. Test the actual command on the candidate server using the video, audio, output codec, frame rate and destination settings you plan to use. If you expect to run a devotional playlist or a set of clips, include the transitions and audio handling in the test rather than testing only a single uncomplicated file. The article on streaming multiple video files to YouTube Live with one FFmpeg command is relevant if your loop uses a playlist.
Observe whether FFmpeg keeps up with real time, whether CPU use remains stable, whether audio stays in sync, and whether the outgoing feed continues without repeated reconnects. A test should run long enough to expose problems that do not appear immediately, but no short test can guarantee a future stream will never fail. Repeat it after changing the codec, resolution, filters or instance size. Keep a record of the exact command and settings so that a comparison is reproducible.
YouTube recommends RTMPS for the feed, constant bitrate and a two-second keyframe interval, not over four seconds. It also recommends testing and previewing in Live Control Room, and monitoring audio and video quality. These are YouTube’s encoder recommendations, not proof that a VPS can sustain a particular encode. Check YouTube’s live encoder setup guidance and use the current settings that match your codec and frame rate.
Finally, confirm the channel can go live before building the rest of the workflow around it. YouTube says the channel needs verification and must not have live-streaming restrictions in the prior 90 days; enabling a first live stream can take up to 24 hours. Its setup guidance includes an example for continuous prerecorded streams, but that is not a blanket approval of every loop or content choice. Check current platform rules and the rights for the material you intend to play. If you are running songs, the guide to checking copyright claims before an Indian music stream covers a practical part of that preparation.
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’s 20 TB traffic allowance available on every Cloud Server?
No. The cited Hetzner traffic table lists 20 TB for EU CX, CPX and CAX Cloud Servers, while US and Singapore allowances vary by plan. Verify the current allowance for the exact family and location you intend to order.
Does Vultr include 2 TB for every individual server?
The cited Vultr documentation describes 2 TB of free bandwidth per account each month, plus instance bandwidth accrued hourly. Check the current account and instance allocation rules rather than assuming the account figure is a separate allowance for every server.
Is a VPS with enough traffic automatically powerful enough for FFmpeg?
No. Traffic allowance and compute capacity are separate constraints. Test whether FFmpeg can handle your exact encode or relay, codec, resolution, frame rate and filters at real-time speed.
Should I choose a provider based on the lowest headline price?
Not without including the selected region, traffic allowance and excess rate, public IP, backups and expected time in service. Compare current provider terms against your calculated stream transfer, then test the workload before committing to a long-running setup.