Video Hosting Cost for a Video Sharing Site, Item by Item

The monthly video bill on a video sharing site comes from four drivers: storage, delivery, processing and live. Each one has a unit you can measure and a price you can get from a provider's quote. This guide gives you the formulas and an empty worksheet, so you can fill in your own numbers instead of trusting anyone else's.

It goes deeper on video than the general list of hidden running costs of a creator platform, which covers hosting, payment fees, moderation and the rest at a high level. Every number below that looks like a price is an invented example, labeled as such. We do not quote cloud prices, because they change and differ by contract. If you are looking at a white-label YouTube clone or a YouTube clone script, read this next to the software price, which is a separate and one-time item.

The four things that cost money

There are smaller lines too: database, servers for the application, search, requests to storage and monitoring. They tend to be modest next to video, and they are covered in the general guide above.

A GB-month is one gigabyte stored for one month. Storage is billed as an average over the period, so a file kept for half a month costs half as much. Egress is the data that leaves a provider's network toward viewers, and many providers bill it per GB. A transcode minute is one minute of source video processed into one or more renditions.

Storage grows with catalog

Storage is the most predictable line, because you can see the catalog.

storage GB = catalog hours x 3,600 seconds x sum of the rendition bitrates in Mbps / 8 / 1,000

That converts hours and megabits to gigabytes. The simpler way to hold it in your head: each rendition of a one-hour video at 2 Mbps takes about 0.9 GB (2 Mbps times 3,600 seconds is 7,200 megabits, which is 900 megabytes). The catalog is the sum across every rendition you keep, plus the original source file if you archive it.

Why renditions multiply it

Adaptive streaming needs several versions of each video, as explained in our guide to what video transcoding and adaptive bitrate are. Every version you keep adds to storage. A four-rung ladder does not cost four times the top rung, because lower rungs are smaller, but it adds up.

Take an invented one-hour video with these rungs: 0.8, 2, 4 and 6 Mbps. Gigabytes per rung are about 0.36, 0.9, 1.8 and 2.7, a total of roughly 5.8 GB for the playable set. If you also keep a 20 GB source file, the video occupies about 26 GB, and the source dominates. That is why retention of the original is a real decision, not a default.

Storage tiers

Object storage providers sell different classes for different access patterns. Amazon's documentation for S3, for example, describes classes for frequently accessed data, for infrequently accessed data, and for archives that need a restore step before you can read them, with minimum storage durations and retrieval fees on the cooler tiers. The concept applies across providers: hot storage costs more per GB-month but is quick and cheap to read, and cold storage costs less per GB-month but charges to read and may take minutes or hours to restore. Put current playable renditions in hot storage, and consider cooler tiers for old sources you rarely touch. Check each provider's current terms, because minimums and fees change.

Delivery grows with watching

Delivery is the line that surprises people, because it follows what viewers do, not what you store.

delivery GB = viewer-hours x 3,600 x average delivered bitrate in Mbps / 8 / 1,000 x (1 minus cache savings share)

Or in the short version: each viewer-hour at 2 Mbps moves about 0.9 GB. A thousand viewer-hours at that bitrate is about 900 GB. Whatever your provider charges per GB, multiply by this volume.

What changes the number

• Average delivered bitrate. This is not your top rung. Adaptive players on phones usually settle on middle rungs, so measure the real average from your player logs after launch. Before launch, estimate it from your audience's devices.
• Peaks. Delivery bills accumulate over time, but capacity and some contracts are about the peak. A single popular video can create a spike, and some plans charge differently above a committed level.
• Ads. Video ads are also video delivered to the viewer. If you serve them from your own infrastructure, they add to delivery volume. Ad networks that host the creative themselves move that cost off your bill.
• Cache hit ratio. A content delivery network keeps copies of popular segments close to viewers. The MDN guide to HTTP caching explains that managed shared caches such as CDNs store responses for reuse by many users, and IETF RFC 9111 defines shared caches the same way. Each request served from the cache is a request your origin storage does not serve, which usually lowers the delivery cost, though the CDN has its own price list.
• Segment lifetime. Video segments never change after they are written, so they can carry long cache lifetimes. The MDN guide describes versioned URLs and the immutable directive for content that never changes, which is the pattern for segments. Playlists for live streams change often and need short lifetimes.

Reading the requests line

Requests are easy to ignore and sometimes surprising. Adaptive streaming cuts each video into short segments, as described in IETF RFC 8216, and the player asks for each one separately. A one-hour video with 4-second segments is 900 requests per rendition watched, per viewer. Short segments help quality switching and cost more requests. Ask each provider whether requests are billed, at what rate, and whether cache hits count.

Delivery worksheet

Processing grows with uploads

Processing is the cost of converting uploads into playable renditions. It is a one-time cost per video, paid when the video is uploaded, not each time it is watched.

processing cost = uploaded minutes x renditions x price per transcode minute

Managed services typically price by output minutes at a given resolution, so a ladder with a high-resolution rung costs more than one without. If you run your own workers, the cost is compute time: minutes of processing per minute of video, times the hourly price of the machines. Codec choice matters. The MDN codec guide describes AV1 as compressing far better than H.264, but newer codecs take longer to encode, so a smaller delivered file is paid for with more processing. The trade is worth making for videos that will be watched many times.

Things that add processing

• Thumbnails and preview strips, which are cheap per video but count at volume.
• Captions generated by speech-to-text, usually priced per audio minute by the provider.
• Re-encoding when you add a codec or change the ladder, which repeats the cost for the existing catalog.
• Failed or abandoned uploads that still consume processing before they are rejected.

Live costs track concurrent viewers

Live streaming on a video site such as the model on our YouTube clone features page, with live streams, donations and super chats, adds a fourth driver. Live has no cache help for the newest segments, because every viewer needs the segment that was just written, and the playlist keeps changing.

• Ingest. The creator's stream arrives at your servers or a provider's. This is usually priced per minute or per hour of incoming stream.
• Live transcoding. Real-time conversion into a ladder is more expensive per minute than a file upload, because it must keep up with the clock.
• Delivery to viewers. The same GB-per-viewer-hour formula as above, with more peak risk, because a popular stream gathers its audience in the same few minutes.
• Recording. If the live stream is saved as a video on demand, it becomes a stored video with its own storage cost.

live cost = stream hours x ingest and transcode rate + concurrent viewers x hours x 3.6 x average Mbps / 8 x delivery price per GB

The second term is the part that explodes. An invented example: one stream lasts 2 hours with 1,000 concurrent viewers at an average of 2 Mbps. Each viewer-hour is about 0.9 GB, so the stream delivers around 1,800 GB. Run that same stream with 10,000 viewers and delivery is 18,000 GB, ten times the volume with the same creator effort. Live revenue from donations and super chats needs to be set against that peak. Our guide to how virtual gifts work in live streaming covers the income side.

A worked template

Here is a complete monthly worksheet. Every figure marked "example" is invented to show the arithmetic. The unit prices are left blank on purpose.

From those inputs:

• Storage volume is C x G, so 6,000 x 5.8 = 34,800 GB, or about 35 TB of playable renditions, before any source files.
• Viewer-hours are V x H, so 50,000 x 6 = 300,000 viewer-hours.
• Delivery volume is viewer-hours x B x 0.45, since one Mbps for one hour is 0.45 GB. That gives 300,000 x 1.5 x 0.45 = about 202,500 GB, or roughly 200 TB, before cache savings.
• Processing volume is U x 60 minutes x R, so 400 x 60 x 4 = 96,000 rendition minutes.

Multiply each volume by the unit price from your quote and sum the four lines. Then repeat for a low and a viral scenario. Note the shape: in this example the delivery volume is almost six times the storage volume, and it will keep scaling with watching while storage scales with uploads. That is typical, though your ratios will differ.

Three scenarios side by side

Using the same invented inputs, change one thing at a time. A low case with 10,000 viewers at 4 hours each is 40,000 viewer-hours, and at 1.5 Mbps that is about 27,000 GB delivered. The expected case above is about 202,500 GB. A viral case where the same 50,000 viewers each watch 12 hours, because one series takes off, doubles the delivery volume to about 405,000 GB without a single extra upload. Storage in that month barely moves. This is why delivery needs alerts and a ceiling you have agreed in advance, and why you should ask providers what happens to the price when volume jumps within one billing period.

Levers that reduce the bill

The admin side of the product matters here. The YouTube-style platform we sell lets admins approve videos and read real-time reports on revenue, engagement, ad performance and storage usage, which is the data you need to apply these levers. You still set the policy: who may upload, how long, and how much.

Make revenue follow cost

A video site is healthy when income per viewer-hour is above cost per viewer-hour. Compute both:

cost per viewer-hour = monthly video bill / viewer-hours

revenue per viewer-hour = monthly video revenue / viewer-hours

Say your invented bill is 6,000 for 300,000 viewer-hours. Cost per viewer-hour is 0.02. If ads earn 0.01 per viewer-hour, every extra hour loses money, and growth makes it worse. If memberships and super chats add another 0.02, the site covers its video cost. This is arithmetic with invented numbers, not a benchmark.

Revenue has to follow the same curve as cost. Subscriptions and memberships scale per viewer, so they track audience size. Ads scale with impressions but need scale before they pay, as our ads and sponsorship guide explains. If you also pay creators a share, set that against the same figures, using the thinking in how video platforms pay creators. The operator side of the money flow, including commission rates for creators and advertisers, is laid out on the YouTube clone business model page.

What the platform price covers

The software price is one payment for the platform, source code, 60 days of technical support and 1 year of updates, with a live launch in 6 working days and custom work taking 2 to 8 weeks. It does not include your cloud, storage, delivery or live usage, which you pay directly to providers. We do not state our price in articles, so use the published figure on the pricing page, and read YouTube clone development cost for what the price covers versus what you pay a cloud provider.

What to do before launch

1. Write the worksheet with your inputs and three scenarios.
2. Get written quotes from two providers for storage, delivery and processing at your expected and at ten times that volume.
3. Set caps on upload size, length and resolution, and a retention rule, before the first creator is invited.
4. Set usage alerts on delivery and live first, then on storage and processing.
5. Choose where revenue per viewer-hour will come from, and check it against cost per viewer-hour.
6. Review the figures monthly, and re-read provider terms each quarter.

Do this before the first marketing push, not after the first large bill. If you want help sizing the video side for your plan, contact us, and compare the delivery decisions in scaling video delivery with the numbers you just built.