Vultr Cloud Compute cost for a 24/7 YouTube stream depends on the selected instance and data-centre region, plus any outbound bandwidth beyond the plan allowance. Vultr documents a 2-vCPU, 4-GB RAM, 80-GB storage instance with 3 TB of bandwidth as a starting configuration for its OBS streaming workflow, but check the current regional price before calculating a monthly total.
The useful estimate is not a single headline figure: it is the current instance price, plus any applicable outbound-transfer overage, with optional services and taxes considered separately. A stream’s bitrate and actual time on air determine the transfer estimate; both the plan and location affect what Vultr charges.
Start with Vultr’s documented configuration
Vultr’s Create a Streaming Server with OBS and Ubuntu guide describes a starting setup with 2 vCPUs, 4 GB of RAM, 80 GB of storage and 3 TB of bandwidth. That is a published starting point for the guide’s workflow, not a promise that every scene, resolution or frame rate will run comfortably on it. You still need to test the workload you intend to broadcast.
The guide says that when the server has at least 2 vCPUs, you should use 720p resolution. It also notes that higher resolutions and frame rates need more processing power, and advises watching OBS CPU use. The guide warns that sustained CPU use above 90% may lead to dropped frames and buffering. These are configuration cautions, not a guarantee of how a particular stream will behave.
There is a distinction between selecting a plan that can carry the stream and selecting one that can render or encode it reliably. If you are encoding and compositing a demanding scene on the instance, test CPU load during representative content. If you are simply sending a prepared video file, your processing needs may differ, but the outbound data calculation still matters. Vultr’s guide provides one way to assess a hosted OBS workflow; it does not establish that one instance size suits every continuous channel.
Vultr classifies its standard Cloud Compute virtual machines as shared CPU. Its provisioning documentation distinguishes these from High Frequency and High Performance categories, which have different CPU or storage characteristics. Treat those as separate choices rather than assuming the streaming guide’s Cloud Compute starting configuration describes all Vultr products. Vultr also documents a separate Broadcaster Marketplace App based on an A16 GPU instance; that is a different hosted OBS route, not an interchangeable price or specification for standard Cloud Compute.
If your source is a looped file and you are deciding whether to use a cloud instance or leave a local machine running, the practical trade-offs are covered in the Windows PC loop-stream guide for India. This article focuses on estimating Vultr charges, not comparing every possible streaming workflow.
Check current pricing before adding it up
A monthly total cannot be responsibly quoted from the published configuration alone. Vultr directs customers to its pricing page for current hourly and monthly rates, and prices may differ by location. The exact current price for the 2-vCPU shared-CPU configuration should be checked for the region where you intend to create the instance. Do not substitute an old screenshot, a price remembered from another region, or the bandwidth-overage rate for the instance price.
Use Vultr’s official pricing guidance to find the current rates, then confirm the location-specific price using the current pricing page or account flow. Vultr separately explains that pricing can vary between data-centre locations. Check the intended region before treating any hourly or monthly amount as the base of your estimate.
Record the plan name, region, hourly rate, monthly rate shown, and included bandwidth at the point you check. The account’s actual deployment choice should match those details. If Vultr shows both hourly and monthly amounts, use the billing basis that fits your planned deployment and confirm how the instance will be billed if it runs for only part of a month. The important point is to obtain the rate for the selected plan and region, rather than importing a number from a different configuration.
Keep the estimate dated in your own notes. Prices and plan details can change, so a figure copied into a spreadsheet should say when and where it was checked. This is particularly useful if someone else manages the channel or approves the spend: they can see which region and configuration the calculation assumes and repeat the check before deployment.
Do not silently fold optional items into the instance price. Backups, snapshots, a Windows licence, taxes or other services may affect your bill if you select them, but they are not part of this estimate unless you actually add them. Check each one in the current Vultr account or pricing information rather than assuming it is included or free.
Estimate monthly outbound transfer
For a constant-bitrate stream, transfer is driven mainly by bitrate multiplied by the time you send it. A simple planning formula is:
Transfer in GB ≈ bitrate in Kbps × streaming seconds ÷ 8,000,000
This uses decimal gigabytes, where 1 GB is 1,000,000,000 bytes, and assumes the bitrate is a constant video-and-audio total. It is a calculation, not a measurement of your eventual bill. Actual traffic can differ if the output bitrate varies, the broadcast is interrupted, you send multiple streams, or other software on the instance also uses outbound data.
For a full 24-hour day, use 86,400 seconds in that formula. For a 30-day planning month, use 2,592,000 seconds. These are calendar arithmetic examples, not a claim that every month has the same length or that your stream will be live every second. If your schedule includes maintenance or daily off-air periods, use your expected streaming seconds instead of assuming uninterrupted operation.
Here is a comparison using representative settings from Vultr’s OBS guide. For an easy comparison, the examples take the lower and upper ends of two of its 1080p ranges and apply the 30-day planning period above. Values are decimal GB and are rounded to the nearest whole GB. They represent stream payload at the stated bitrate, not a measured network total.
| Example from Vultr’s guide | Bitrate used in calculation | Approximate transfer over 30 days at that bitrate |
|---|---|---|
| 1080p/30 FPS, lower end | 3,000 Kbps | 972 GB |
| 1080p/30 FPS, upper end | 6,500 Kbps | 2,106 GB |
| 1080p/60 FPS, lower end | 4,500 Kbps | 1,458 GB |
| 1080p/60 FPS, upper end | 9,500 Kbps | 3,078 GB |
Vultr’s guide gives 3,000–6,500 Kbps for 1080p/30 FPS and 4,500–9,500 Kbps for 1080p/60 FPS. Those are Vultr’s suggested bitrate ranges, not independent measurements or a recommendation that every channel should choose the upper end. A moving news loop, a static devotional image with audio, and a detailed ambience scene may call for different output choices. Test image quality and the stream’s stability, then use the bitrate you actually set in OBS for the cost estimate.
The table makes the basic trade-off visible: holding uptime constant, doubling the bitrate doubles the calculated transfer. Reducing the number of hours the channel is live reduces it in proportion as well. The 3 TB allowance in Vultr’s documented starting configuration is not a promise that every stream will remain within that quota; compare your own expected outbound use with the allocation shown for the current plan.
For a looped channel, make the source and schedule assumptions explicit. A single encoded output sent continuously is different from multiple concurrent outputs or a setup that sends other files and updates from the same instance. If you are planning a long catalogue of files, this guide to estimating storage for a 24/7 sleep-sound library helps separate storage capacity from network transfer. Storage is a separate line in the decision: a large media library does not itself tell you the stream’s outbound bitrate.
Understand the documented overage rate
Vultr counts outbound internet data towards bandwidth limits; inbound traffic is not metered in the same way. A live stream sent from your instance to YouTube is outbound traffic from Vultr’s perspective. If that usage exceeds the plan’s included quota, the excess may be billed as an overage.
Vultr’s documentation states that usage beyond the allocated bandwidth is billed at $0.01 per GB. That is the documented overage rate, not the price of the instance and not a flat monthly streaming charge. See Vultr’s bandwidth calculation documentation and its page on the bandwidth overage rate. Recheck those pages before acting in case the terms have changed.
To estimate an overage, subtract the plan’s included outbound allocation from your estimated or measured outbound use, then apply the documented rate only to the positive remainder. For example, if a plan’s current account details show an allocation of 3 TB and your measured usage is below that allocation, the estimate has no bandwidth overage under that simple calculation. If your use is above the allocation, calculate the excess using the unit convention Vultr applies. Do not treat the illustrative example as a statement about a current plan’s quota or bill.
Be careful about units. The calculation table above uses decimal GB, while a provider may present a quota in TB or use a billing convention that needs checking. Convert the allowance and your estimate to the same unit before subtracting. Where Vultr’s current page or account view defines how it counts the quota, follow that definition rather than assuming decimal and binary units are identical.
The rate by itself is not enough to predict a charge. First verify the plan’s included bandwidth and how Vultr counts it; next estimate or measure the outbound total; then determine whether there is excess. A stream can have a modest instance cost but still use enough data to cross a quota, or fit within the quota while needing a different instance for processing. Keep those questions distinct.
Put instance, region and stream together
A useful estimate has three main lines: the selected instance’s current rate, expected outbound transfer against its included allocation, and any overage if the allocation is exceeded. Start by choosing a region that makes sense for your operation and audience, then check its current plan details. There is no universal monthly number that can replace those choices.
The following worksheet keeps the assumptions visible. Fill it using current Vultr information for the actual region and configuration, and avoid mixing an hourly instance rate from one location with a bandwidth allocation from another plan.
| Estimate line | What to enter | Why it matters |
|---|---|---|
| Instance | Current hourly or monthly rate for the chosen Cloud Compute plan | This is the base compute charge; verify it for the selected region |
| Region | Intended Vultr data-centre location | Vultr says pricing can vary by location |
| Included transfer | Outbound quota shown for that plan | It determines how much use is covered before overage |
| Stream settings | Bitrate and expected live hours | These set the planning estimate for stream payload |
| Other outbound use | Any additional traffic from the instance | It may count towards the same outbound allowance |
| Overage | Excess above allocation multiplied by the documented rate | Include only if calculated or measured usage exceeds quota |
| Optional items | Backups, snapshots, licence or taxes, if selected | Keep them separate until confirmed for the deployment |
This approach is deliberately not a published total. Without the current price of the selected plan and region, a total would imply more certainty than the available evidence supports. The final number should be assembled from values you can verify at the time you provision the machine.
A lower bitrate can reduce transfer, but quality and motion may suffer if you reduce it too far. Higher frame rates and resolutions may use more processing capacity as well as more data. Vultr’s guide provides recommended bitrate ranges and cautions about CPU utilisation; use those as planning references, not guarantees. Run a representative test before relying on a configuration for an always-on channel.
If an instance’s encoding workload pushes CPU use high, compare the cost and fit of a more suitable compute category or Vultr’s separate Broadcaster Marketplace route rather than assuming the shared-CPU starting setup will handle it. The relevant choice depends on whether you need an always-on file loop, remote OBS controls, or active encoding and scene compositing. For an OBS setup with overlays, the live-chat overlay guide can help identify features that may add work to the streaming workflow. It does not change Vultr’s billing rules, but it can help you describe what the instance must do.
If managing an instance, keeping it updated and investigating restarts are the work you want to avoid, StreamNeo removes that specific operational burden by taking an uploaded video and running it as a YouTube live stream without keeping your own computer on. It is YouTube-only, so a workflow that needs a different platform or direct access to a configurable remote OBS environment may call for a different approach; compare requirements rather than assuming a file-looping tool replaces every cloud-compute use case.
Check usage after streaming
Once the stream is running, compare the transfer estimate with Vultr’s actual usage view. The estimate helps you choose a plan, but measured outbound use is a better guide to whether the stream, restarts, file transfers or other software are consuming the expected amount. Check the account’s bandwidth information regularly, particularly after changing bitrate, moving region, or adding another output.
Compare like with like: use a known reporting period, note the stream’s actual hours live and bitrate settings, and see whether the observed data roughly follows the estimate. A mismatch does not automatically mean the billing view is wrong. The output bitrate may vary, the stream may have been live for longer than assumed, or other outbound activity may contribute. Review the workload and the provider’s current usage definitions before making a plan change.
If you are operating from India, a local computer and a cloud instance have different operational costs and failure modes. A local PC may use electricity and depend on your home or business connection; a cloud instance has a recurring provider bill and requires you to manage its setup. The pre-recorded-stream options for Indian creators offer another point of comparison, but check each tool’s current capabilities and terms rather than assuming it works like Vultr Cloud Compute.
Keep a simple record of the date, region, instance, bitrate, scheduled hours, quota, and observed transfer. That is enough to revisit the estimate if you make a change. If actual use is near the included allowance, decide whether lowering bitrate, reducing on-air hours, or changing plan makes sense for the channel. If the stream is comfortably within the quota, the instance price and processing capacity may be the more important lines to review.
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 much bandwidth does a 24/7 YouTube stream use?
It depends on bitrate and how many hours the stream is actually live. At a constant bitrate, multiply Kbps by streaming seconds and divide by 8,000,000 for an approximate decimal GB figure. Use the output bitrate you have configured, then compare the estimate with the selected plan’s current outbound allowance.
Does Vultr charge extra for bandwidth overages?
Vultr documents an overage charge of $0.01 per GB above the plan’s allocated bandwidth. That is separate from the instance price, and only applies to usage beyond the allocation under Vultr’s billing terms. Confirm the current quota, usage and rate in Vultr’s official billing documentation before relying on an estimate.
What is the starting Cloud Compute configuration in Vultr’s streaming guide?
Vultr’s guide describes 2 vCPUs, 4 GB of RAM, 80 GB storage and 3 TB of bandwidth as a starting setup for its OBS workflow. It is not a guarantee that every resolution, scene or workload will run well, and the current price for the intended region must be checked separately.
Can I use the documented setup as a monthly cost total?
Not on its own. You need the current rate for the selected instance and location, plus your expected or measured outbound use and any applicable overage. Keep optional services and taxes separate unless your deployment actually adds them.