Self-hosting vs a video hosting platform
Serving your own mp4 is simple, cheap and works until it doesn't. This is a clear account of what you are taking on when you self-host, and what a platform is really doing for you.
Self-hosting works for a few short, well-made videos on a quiet site. A hosting platform is the better choice when you need more. That can mean quality that adapts, uploads that resume, playback on every device, thumbnails or privacy controls. A platform also wins when many people watch at once and your own server would slow down.
Every web developer has done it at least once: export an mp4, drop it in the static folder, write a video tag, ship. It works. It keeps working right up until a page with a video on it gets popular. Or the file is replaced with a longer one, or someone opens it on a phone in a car park. Self-hosting is not wrong. It is a set of trade-offs that are invisible at small scale and painful at large scale.
This guide lays out those trade-offs plainly, on both sides. It covers what self-hosting does well and what you have to build or give up. It shows what a platform takes off your plate. It ends with a practical threshold for deciding when to switch. For the basics of how hosting works, start at the video hosting hub.
What self-hosting actually means
In the simplest form, self-hosting is a file on the same server as your pages and a <video> element pointing at it. The browser requests the file and starts playback as soon as it has the header and enough data. It seeks by sending range requests for byte ranges further into the file. MDN's video element documentation covers the tag. This is progressive download, and it has real virtues: no third party, no processing delay, no account, and the file is exactly what you exported.
A more ambitious form of self-hosting means running the pipeline yourself. You need FFmpeg to transcode into a rendition ladder and a packager to make HLS playlists. You need object storage for the segments, a CDN in front and a JavaScript player that can switch quality. That is entirely achievable, and FFmpeg's documentation is the place to start. But at that point you have built a video hosting platform with one customer.
What you get, what you build, what you forgo
Comparing the simple mp4 approach with a platform such as VideoBB.
| Capability | Single mp4 on your server | Hosting platform |
|---|---|---|
| Playback in every browser | Only if the file is H.264 in mp4 with AAC audio | Any accepted container is transcoded to a playable form |
| Adaptive quality | No; one bitrate for everyone | Rendition ladder with automatic switching |
| Large uploads | Limited by your server's request size and timeouts | Resumable uploads to 4 GB via tus |
| Seeking | Range requests; works if the index is at the front | Segment-based; instant |
| Thumbnails and scrub previews | Make them yourself | Generated automatically |
| Concurrent viewers | Bounded by the server's uplink | Served from CDN edge caches |
| Privacy | Whatever your web server enforces | Public, unlisted, private per video |
| Player | Browser default or a library you integrate | Embeddable player included |
The three walls you hit when self-hosting
The first wall is bandwidth. A web server on a typical hosting plan shares an uplink, and a single 1080p stream at 5 Mbps is a noticeable fraction of it. Twenty simultaneous viewers is 100 Mbps sustained. This is why a video that goes modestly viral takes the whole site down with it: the pages and the video compete for the same pipe. A CDN solves this, and it is the first piece of a platform most self-hosters end up adding. CDN for video delivery explains how.
The second wall: one bitrate for everyone
One file means one quality. Encode it high, and mobile viewers buffer. Encode it low, and desktop viewers see a soft image on a large screen. The only remedy is a rendition ladder and a player that switches between rungs, which is adaptive streaming. Adaptive bitrate streaming explained covers why this cannot be faked with a single file.
The third wall: compatibility and correctness
The mp4 must contain H.264 video and AAC audio to play everywhere. The moov atom must sit at the front of the file, or playback waits for the whole download. And the audio and video must be properly interleaved. An export from an editor usually gets this right. A file from a phone, a screen recorder or a conversion tool often does not. MP4 vs MKV vs AVI explains the containers, and the -movflags +faststart option in FFmpeg fixes the index position. If you would rather not use FFmpeg, the free video converter makes an H.264 and AAC mp4 with the index already at the front.
Effort and control
Where each approach asks for your time, and where it hands over control.
Self-hosting
- You encode, so you control every parameter
- You choose the player and its behaviour
- No dependency on a third party's uptime or policy
- You manage storage, backups and bandwidth bills
- You build or skip thumbnails, previews, privacy
- You debug playback failures across devices
Hosting platform
- Encoding parameters chosen by the platform
- Player provided; embed and go
- Depends on the platform continuing to exist
- Storage and delivery included in the plan
- Thumbnails, previews and privacy included
- Playback tested across devices by the platform
Cost, in money and in attention
Self-hosting looks free because the storage is already paid for. The hidden costs are bandwidth overage, which most hosting plans meter or throttle, and the time spent on encoding, player integration and debugging. A platform charges a subscription instead. VideoBB's Premium tier is $9.99 a month or $79 a year. In exchange, the whole pipeline stops being your job. The costs guide puts actual numbers on the storage and bandwidth side of that comparison so you can do the arithmetic for your own library.
A practical threshold
Self-host if all of these are true. Move to a platform if any of them is false.
- The library is a handful of videos, each under a few minutes and a few hundred megabytes.
- Every file is H.264 video and AAC audio in an mp4 with faststart applied, verified with ffprobe.
- Traffic is low enough that ten simultaneous streams would not trouble the server's uplink.
- Viewers are mostly on reliable connections, so a single bitrate is acceptable.
- You do not need private or unlisted videos, hover previews or automatic thumbnails.
- You are willing to be the person who is paged when a video will not play on someone's phone.
The middle path: host the video, own the page
The false choice is between running everything yourself and handing your site to a video platform. A dedicated host lets you keep the page, the URL, the design and the surrounding text while delegating only the storage and delivery. The embedded player sits inside your layout, and the page remains yours for search and for readers. How to embed video on a website walks through it. The embed guide covers VideoBB's player specifically. If you are an engineer who wants the pipeline behind an API rather than a dashboard, see the developer pages.
Frequently asked questions
Why does my self-hosted video take ages to start?
Almost always because the mp4's index (moov atom) is at the end of the file. The browser must then download everything before it can find the first frame. Re-mux with FFmpeg's -movflags +faststart, which moves the index to the front without re-encoding. A very high bitrate on a slow connection is the other common reason.
Can I self-host adaptive streaming?
Yes. FFmpeg can produce an HLS rendition ladder and playlists. You store the segments on a server or in object storage, put a CDN in front and use a JavaScript player that supports HLS. It is a real project with real maintenance, which is the trade-off this guide describes. For one site it is usually more work than it saves.
Is self-hosting better for privacy?
Only if you implement access control on the file, which most simple setups do not. A guessable URL to an mp4 is public. A hosting platform with per-video privacy settings, such as unlisted or private, is usually more private in practice than a static file behind nothing.
What about hosting video on a general CDN or object storage?
That fixes bandwidth and concurrency but not the single-bitrate problem, compatibility or thumbnails. It is a good intermediate step for progressive download at scale. If you also want adaptive quality you still need to transcode and package, which is where a video platform starts to make more sense.
Sources
- MDN: The Video Embed element — Browser behaviour of the video tag.
- MDN: HTTP range requests — How seeking works in progressive download.
- FFmpeg documentation — Transcoding, faststart and HLS packaging.
- RFC 8216: HTTP Live Streaming — What an adaptive stream consists of.
Related guides
What is video hosting?
A plain-English tour of what a video host does with your file after upload. It also shows the point where a video tag on your own server stops being enough.
Video hosting costs: storage and bandwidth
Video costs money in two places: keeping it and sending it. Both can be estimated from numbers you already have. This guide shows the arithmetic and where the surprises hide.
How to embed a video on a website
Copy one iframe, understand the six attributes it carries, and add the query parameters that control autoplay, mute, start time and looping.
CDN for video delivery
Video is the most cache-friendly traffic on the internet and the most punishing when caching fails. How content delivery networks serve segments, what to cache for how long, and where the costs hide.