Daniel sent us this one — he's been deep in the static-site-media rabbit hole, and now he wants to talk about video specifically. The question is: when you're deploying a site on something like Astro or Next or whatever, when does it make sense to stop treating video like just another asset and start using a purpose-built video platform? And if you do, who are the players, what do they cost, and what's the actual pivot point?
This is one of those topics where the surface-level question is straightforward, but the moment you dig in, you realize the entire architecture of the modern web is shaped around this exact problem. Video is not just a big image. That's the thing people need to understand first. An image is a single file, you serve it once, the browser downloads it, you're done. Video is a completely different beast.
Because of the streaming part.
Because of the streaming part, and because of the encoding part, and because of the delivery part. Let me start with the thing most people don't think about. When you upload a video to your site as a static MP4 file, you're giving every single user the exact same file. Someone on gigabit fiber in Seoul gets the same four-K sixty-frames-per-second file as someone on a spotty three-G connection in rural Montana. That's absurd. The person on three-G is going to buffer for thirty seconds before they see a single frame, and they'll probably just leave.
The person in Seoul is getting a worse experience than they could, because if the file is compressed for the three-G user, it looks terrible on their eight-K monitor.
So the fundamental value proposition of a video platform is adaptive bitrate streaming, or ABR. The platform takes your source file and transcodes it into multiple renditions at different resolutions and bitrates — say, two-forty-p at very low bitrate, three-sixty-p, seven-twenty-p, ten-eighty-p, all the way up to four-K. Then it chops each rendition into tiny segments, usually two to ten seconds each. When a user hits play, the player dynamically switches between renditions based on their available bandwidth and screen size. If their connection dips, it drops to a lower quality seamlessly. If it improves, it ramps back up. The viewer never sees a buffering spinner.
Which is what YouTube does.
Which is what YouTube does, what Netflix does, what every serious video platform does. And you cannot do this by just dropping an MP4 in a bucket. The browser's built-in video element doesn't do adaptive bitrate. It plays one file, start to finish, at one quality. If you want ABR, you need a player that supports HLS or MPEG-DASH, which are the two main streaming protocols. And that player needs multiple renditions to switch between, which means you need a transcoding pipeline.
The first pivot point is: do you need adaptive bitrate streaming? If your video is a thirty-second hero loop on a landing page, maybe not. One well-compressed MP4 might be fine. If it's a two-hour lecture, absolutely yes.
And this is where the cost conversation starts getting interesting, because transcoding is computationally expensive. It's not something you want to do on your build server. You could set up your own pipeline with FFmpeg and a queue worker, but now you're maintaining infrastructure, dealing with failure states, managing storage for all those renditions. It's the kind of thing that sounds fun for about an afternoon and then becomes a persistent source of mild dread.
Like adopting a feral cat.
So the major players in this space — and I'm going to focus on the ones that integrate well with serverless and Jamstack deployments — are Mux, Cloudflare Stream, and Bunny Stream from Bunny.There are others, but these three are the ones you'll see most often in the Vercel marketplace and similar ecosystems.
Let's go through them. Mux first — I feel like they're the name that comes up most when people talk about video APIs.
Mux is essentially the Stripe of video. They're a developer-first API company. You send them a video, they handle everything: transcoding, storage, delivery via their CDN, and they give you a player you can embed. Their pricing is usage-based. For on-demand video, you pay for ingestion — how many minutes of source video you upload — and then for delivery — how many minutes your users actually watch. As of their current pricing, ingestion is about five cents per minute of source video. Streaming delivery is about one dollar and ten cents per thousand minutes watched. Storage is separate, roughly a dollar twenty per thousand minutes of stored content per month.
If I upload a ten-minute video and a thousand people watch the whole thing, what am I looking at?
Ingestion: fifty cents for that ten-minute source file. Delivery: ten minutes times a thousand views is ten thousand minutes watched, so that's about eleven dollars. Storage is negligible for one video — pennies. Total: roughly eleven fifty. If those thousand people only watch an average of two minutes each, your delivery cost drops to about two dollars twenty. That's the beauty of usage-based pricing — you pay for what your audience actually consumes.
The video quality is good?
Mux uses per-title encoding, which means they analyze each video individually and optimize the encoding ladder for that specific content. A talking-head video with a static background gets a very different encoding profile than an action sequence with lots of motion. They also do just-in-time transcoding, so if nobody ever requests the four-K rendition of your video, they might not even generate it. It's very efficient.
Okay, what about Cloudflare Stream? They're the obvious competitor if you're already in the Cloudflare ecosystem.
Cloudflare Stream is interesting because they price differently. They charge by storage and by minutes viewed, but there's no separate ingestion fee. Storage is five dollars per thousand minutes of stored video per month. Streaming is one dollar per thousand minutes delivered. So compared to Mux, the streaming cost is similar — Mux is a dollar ten, Cloudflare is a dollar — but Cloudflare charges meaningfully more for storage. Five dollars per thousand minutes versus Mux's dollar twenty.
The math favors Cloudflare if your videos get watched a lot relative to how much you store, and Mux if you have a large library that doesn't get many views per video.
That's exactly the trade-off. Cloudflare Stream also benefits enormously from being on Cloudflare's network. If you're already using Cloudflare for your DNS and CDN, Stream integrates natively. Your video delivery rides on the same edge network that serves the rest of your site. Latency is extremely low. And they have some nice features — signed URLs for access control, automatic captions via Whisper, and a built-in player.
Then Bunny Stream.
Bunny Stream is the dark horse here, and honestly, it's the one that surprises people on price. net operates their own global CDN with something like a hundred and fourteen points of presence. Their pricing is dramatically lower. Storage is one cent per gigabyte per month — not per minute, per gigabyte. Delivery is ten cents per gigabyte for the first five hundred terabytes. For video, a gigabyte is roughly an hour of ten-eighty-p content, give or take depending on encoding. So you're looking at fractions of a penny per view for typical video lengths.
That's an order of magnitude cheaper.
It's not even the same ballpark. Bunny Stream also does adaptive bitrate, also gives you a player, also handles transcoding. The trade-off is that their feature set is narrower. They don't have the deep analytics that Mux offers. Their API is simpler, which is fine for basic use cases but might be limiting if you need fine-grained control. And their transcoding pipeline, while perfectly competent, doesn't do the per-title optimization that Mux does. You'll get good quality, but Mux will squeeze more quality out of the same bitrate.
Bunny is the glockenspiel of corporate approachability — it does the thing, it's charmingly cheap, nobody's mad at it.
That's a perfect description. Bunny Stream is what you use when you need solid video delivery without any fuss and you don't want to think about the bill. Mux is what you use when video is central to your product and you need analytics, quality optimization, and a rich API surface. Cloudflare Stream is what you use when you're already all-in on Cloudflare and want everything under one roof.
Let's talk about the pivot point. When does someone actually need to move from "I'll just serve an MP4 from my static site" to one of these platforms? What's the trigger?
I think there are three triggers. The first is user experience, which we already touched on. If your video is longer than about thirty seconds, and especially if it's longer than a couple of minutes, you want adaptive bitrate. The second is bandwidth cost. If you're hosting video files on your own origin server or in a generic blob store and serving them directly, every view pulls the full file. If you have a hundred-megabyte video and it gets ten thousand views, that's a terabyte of egress. Depending on your hosting provider, that could be expensive. Cloud providers charge anywhere from five to twelve cents per gigabyte for egress. A terabyte at ten cents is a hundred dollars. Bunny Stream would charge you ten dollars for the same delivery.
The platform can actually be cheaper than the DIY approach once you hit any kind of scale.
Especially when you factor in the time you'd spend building and maintaining your own solution. The third trigger is features. Things like automatic captions, analytics dashboards that show you where viewers drop off, thumbnail generation, GIF creation — these are table stakes for video platforms and significant engineering projects if you build them yourself.
The player itself. The HTML5 video element is fine for a demo, but it looks different in every browser. Chrome has one set of controls, Safari has another, Firefox has a third. None of them feel polished.
Mux Player, Cloudflare's player, Bunny's player — they all give you a consistent, customizable experience across browsers. They handle keyboard shortcuts, they handle mobile, they handle things like clicking to go fullscreen in a way that actually works. And they're typically just a few lines of code to embed. It's not nothing.
The pivot point, practically speaking, is: you're building a site, you need video, and any of the following is true — the video is longer than a minute, you expect more than a few hundred views a month, you want it to not look like a high school computer lab project, or you value your sanity.
That's the short version. The slightly longer version is that there's a spectrum. At the simplest end, you can put an MP4 in your repo and call it a day. This works for tiny hero videos, animated backgrounds, things that are essentially decorative. At the next level, you put your MP4 in blob storage — S3, R2, whatever — and serve it with a CDN in front. This handles the bandwidth cost problem but still doesn't give you adaptive bitrate. At the top level, you use a video platform.
There's an intermediate step that I think is worth mentioning, which is: you can pre-transcode your video into multiple renditions yourself using FFmpeg, store them in a bucket, and use an open-source player like Video.js or Plyr that supports HLS. You're getting adaptive bitrate without paying a platform.
And for some use cases, that's a perfectly reasonable choice. If you're running a media company with a dedicated engineering team, you might even prefer it because you have full control. But for the audience we're talking about — people deploying static sites, small teams, solo developers — the operational overhead of maintaining that pipeline usually isn't worth the savings. You have to monitor it, you have to deal with storage management, you have to handle CDN configuration. The platforms abstract all of that away.
What about audio? The prompt mentioned audio as a comparison point.
Audio is genuinely simpler. A podcast episode is typically a single MP3 file, maybe sixty to a hundred megabytes. Most people are listening on connections that can handle a straight download without issue. You can serve audio from blob storage with a CDN and it'll work fine. There are audio-specific platforms — like Transistor or Simplecast for podcast hosting — but they're more about RSS feed management, analytics, and distribution to Apple and Spotify than about streaming technology. The adaptive bitrate problem doesn't really exist for audio in the same way. HLS does support audio-only streams, and Apple's podcast platform uses it for streaming, but for most use cases, a single MP3 behind a CDN is perfectly adequate.
Audio is basically where images were five years ago — the infrastructure is mature enough that you don't need a specialized platform unless you're doing something unusual.
Which brings us back to video. Let me give some concrete numbers for the pivot point, because I think that's what people actually want. Say you have a site with five videos, each about five minutes long, encoded at ten-eighty-p. Each video is roughly two hundred megabytes. You get about five thousand views per month across all videos, with an average watch time of two minutes per view.
Ten thousand minutes watched per month.
On Mux, your ingestion cost for the initial upload is about a dollar twenty-five total — five videos times five minutes times five cents. Your monthly delivery cost is about eleven dollars. Storage is negligible, less than fifty cents. Total monthly: roughly twelve dollars.
Versus the DIY approach.
If you put those same videos in S3 and serve them through CloudFront, you're paying about two point three cents per gigabyte for storage and about eight and a half cents per gigabyte for egress in the US. Five videos at two hundred megs each is one gigabyte stored, so storage is basically free. But egress: ten thousand minutes watched at roughly forty megabytes per minute of video data — and this is approximate because the bitrate varies — but call it four hundred gigabytes of egress per month. At eight and a half cents per gig, that's thirty-four dollars.
Mux is cheaper than rolling your own on AWS.
In this scenario, yes. And that's before you factor in the time you spent setting up CloudFront, configuring CORS, dealing with cache invalidation, and building any kind of player UI. Bunny Stream would be even cheaper — roughly a dollar fifty for the same delivery volume.
That's almost comical. A dollar fifty versus thirty-four dollars.
Bunny's pricing is disruptive. They've built their own CDN and they pass the savings on. The caveat is that they're a smaller company — based in Slovenia, actually — and their feature set reflects that. If you need advanced analytics, if you need webhook integrations for your CMS, if you need per-viewer heatmaps, Mux is going to be the better choice. But if you just need to put a video on a page and have it work, Bunny is incredibly compelling.
I want to go back to something you mentioned earlier — the per-title encoding that Mux does. What does that actually mean in practice? Why does a talking-head video encode differently than an action scene?
This is fascinating. Traditional encoding uses a fixed ladder — you decide in advance that you'll have renditions at two-forty-p, three-sixty-p, seven-twenty-p, ten-eighty-p, each at a specific bitrate. The problem is that different content has different complexity. A static shot of someone talking at a desk has very little motion. Most of the frame doesn't change from one second to the next. You can encode that at a much lower bitrate than an action movie with explosions and fast cuts, and it'll look identical to the viewer.
Because the encoder can just say "this block of pixels is the same as last frame, don't bother re-sending it.
Modern video codecs like H.264 and H.265 and AV1 work by encoding the differences between frames, not each frame independently. If there's no motion, there's almost nothing to encode. So a talking-head video at ten-eighty-p might look perfect at two megabits per second, while a soccer match needs eight megabits per second to avoid turning into a blocky mess. Per-title encoding analyzes the actual content of your video and builds a custom encoding ladder that allocates bits where they're needed.
Mux does this automatically.
Mux does it automatically. Cloudflare Stream does something similar, though they're less public about the details. Bunny Stream uses a more traditional fixed ladder approach, which is part of why they're cheaper — less computation per video.
If you're doing, say, a course platform where most of your content is talking-head lectures, Mux's per-title encoding could meaningfully reduce your delivery costs because each minute watched uses less data.
And it also improves the viewer experience because the quality adapts more intelligently. Nobody's lecture needs to be delivered at fifteen megabits per second. But a fixed ladder might serve it at a higher bitrate than necessary simply because that's what the ladder says for ten-eighty-p.
Let's talk about the Vercel marketplace angle, because the prompt specifically mentioned that. How do these platforms actually integrate with the deployment workflow?
Vercel's marketplace is essentially a curated list of integrations that work well with their platform. Mux has a first-class integration — you can add it from the dashboard, it provisions an account, and you get environment variables injected into your project automatically. Cloudflare Stream doesn't have a direct Vercel integration in the same way, but it works perfectly fine — you just use their API. Bunny Stream is similar. The integration is mostly about convenience, not about technical compatibility. Any of these platforms work with any hosting provider because they're all API-driven.
The real workflow question is: how do you get your videos into the platform? If you're using a static site CMS, you're probably uploading content through some kind of admin interface.
This is where the API-first approach really shines. With Mux, you typically do direct uploads — your frontend gets a signed upload URL from Mux's API, the user's browser uploads the video directly to Mux's servers, and Mux processes it. The video never touches your own server. Your CMS just stores the Mux asset ID and playback ID. When you render the page, you use those IDs to embed the player. It's clean, it's fast, and it scales infinitely because the upload bandwidth is on Mux, not on your infrastructure.
For a site built with something like Astro, this is all happening at build time or client-side?
Client-side for the upload. The embedding is done at build time if you're using a static approach, or at request time if you're using server-side rendering. But the key insight is that the video platform is a completely separate service. Your static site generator doesn't know or care about the video. It just outputs a player embed code. All the heavy lifting happens elsewhere.
Which is the entire Jamstack philosophy, even if nobody calls it Jamstack anymore.
The name may have faded, but the architecture won. Separation of concerns between your content layer and your delivery layer, with APIs gluing everything together. Video platforms are a perfect example of why this approach works. You don't want your static site build process touching video transcoding. That way lies madness and forty-five-minute build times.
I've seen people try to do video in their Git repo. It's not pretty.
Git is not designed for large binary files. Git LFS exists, but it's a band-aid. Every clone pulls the entire history. If you've ever tried to clone a repo with a few hundred megabytes of video assets, you know exactly how painful it is. And then your CI pipeline has to process those files on every build. It's the wrong tool for the job.
To summarize the decision framework: if you're adding video to a site, the default should be a video platform. The exception is when the video is very short, very low-traffic, and quality doesn't matter much — in which case, a simple MP4 in blob storage with a CDN is fine.
I'd add one more dimension, which is: what happens when things go wrong? If your video doesn't play, who do you call? With a platform, you file a support ticket and they investigate. With a DIY solution, you're debugging your FFmpeg pipeline at two in the morning because a user reported that the audio is out of sync on Safari for iOS seventeen point four.
There's a specific kind of despair that comes from cross-browser video bugs.
I've lived that despair. It's not worth the twelve dollars a month you're saving.
Let's talk about the privacy angle, because the prompt mentioned it. Embedding YouTube videos on your site means Google is tracking your visitors. Even with the privacy-enhanced mode, there's still some data leakage. And you get the YouTube branding, the related videos at the end, the general feeling that you're borrowing someone else's platform.
YouTube embeds are the sweatpants of web video. They're comfortable, they're easy, everyone uses them at home, but you wouldn't wear them to a business meeting. A video platform lets you serve video on your own domain, with your own branding, no third-party cookies, no algorithmic recommendations pulling your visitors away to watch compilations of cats falling off tables.
Unless your site is about cats falling off tables, in which case that's actually a feature.
But for most professional use cases — corporate sites, course platforms, SaaS marketing pages — owning the video experience is important. It signals competence. It says "we thought about this.
From a technical perspective, using a platform means your video delivery is optimized in ways that YouTube's embed player isn't for your specific use case. YouTube is optimized for YouTube's goals, which include maximizing watch time across the platform. A platform like Mux is optimized for your goals, which are probably "play this specific video smoothly and then let the user get on with their life.
The other thing about YouTube embeds is that you have no control over the encoding. YouTube re-encodes everything to their specifications, and while they're very good at it, you can't tune it for your content. With your own video platform, you control the source quality, and the platform optimizes around that.
What about live streaming? We've been talking about on-demand video, but the prompt mentioned streaming complexity. Do these platforms handle live?
Mux does live streaming, yes. Cloudflare Stream has a live offering as well. Bunny Stream is on-demand only as of now, though they've hinted at live support. Live streaming is a whole other level of complexity because you're dealing with real-time encoding, low-latency delivery, and the fact that you can't pre-process anything. The viewer is watching as the event happens, so your encoding pipeline has to work in near real-time. Latency becomes critical.
The cost model is different.
Live streaming is priced by the hour of input, not by minutes watched. Mux charges around thirty-five cents per hour of live input for basic live, and more for reduced-latency modes. Cloudflare Stream charges about a dollar per hour of live input. The delivery costs are on top of that. It adds up quickly if you're doing frequent live events.
For the use case we're discussing — video on a static site — live is probably not the primary concern.
Most people embedding video on a marketing site or a blog or a course platform are dealing with pre-recorded content. Live is a different beast entirely, and honestly, if you're doing live streaming at scale, you're probably not hosting it on your Astro site. You're using a dedicated live platform or you're on Twitch or YouTube.
Let's circle back to costs one more time, because I think people get nervous about usage-based pricing. There's a fear that a video going viral could mean a surprise thousand-dollar bill.
This is a legitimate concern. Mux and Cloudflare both let you set spending limits, so you can cap your monthly costs. Bunny is so cheap that a viral video is unlikely to break the bank — ten thousand views of a five-minute video at ten-eighty-p would cost you maybe a dollar fifty in delivery. But yes, with usage-based pricing, you need to be aware of what you're spending. The flip side is that fixed-price plans usually overcharge you for your actual usage. Most sites serve very little video traffic. If you're paying a flat fifty dollars a month for a video hosting plan and you're serving a hundred views, you're overpaying dramatically.
The usage-based model actually benefits small sites.
The median website with embedded video probably serves a few hundred views a month. On Mux, that's literally cents. On a fixed-price plan, it's twenty to fifty dollars. The fear of a surprise bill is real, but for the vast majority of users, usage-based pricing is a better deal.
You can mitigate the risk with caps and monitoring.
Set a budget alert. Set a hard cap if your platform supports it. Check your dashboard once a month. It's not a set-it-and-forget-it situation, but it's also not the financial time bomb that some people imagine.
What about the self-hosting diehards? The people who say "I want to own my infrastructure, I don't want to depend on a third-party service that could change its pricing or shut down.
I have sympathy for that position. Vendor lock-in is real. If you build your entire video workflow around Mux's API and Mux doubles their prices or gets acquired and shut down, you have a migration problem. The counterargument is that video is hard to do well. The engineering effort required to match what these platforms offer is substantial. For most projects, the risk of vendor problems is outweighed by the certainty of spending weeks building and maintaining a video pipeline.
The migration path isn't that bad. You have your source files. You upload them to a different platform. You change the embed code. It's not like you're locked into a proprietary database format.
Video files are portable. The platform-specific part is the transcoding and delivery, not the asset itself. You can always take your original MP4 and move it somewhere else. The switching cost is mostly operational — updating your CMS, changing your embed code, re-uploading your library.
For someone who's convinced, what's the actual implementation look like? Say I'm building an Astro site, I want to add a video page, I've chosen Mux. Walk me through it.
You'd install the Mux Node SDK, add your API keys as environment variables, and create an upload endpoint. When a user uploads a video in your CMS, your frontend calls that endpoint, gets a signed upload URL, and uploads directly to Mux. Mux returns an asset ID. You store that ID in your content. When you render the page, you use the Mux player component — or just a simple iframe embed — with the playback ID. The player handles everything else: adaptive bitrate, quality switching, keyboard shortcuts, fullscreen. It's maybe twenty lines of code total.
The same pattern works for Cloudflare Stream or Bunny.
API key, upload, store the ID, embed the player. The differences are in the details — which player you use, what the API endpoints look like, what features are available — but the architecture is the same across all three.
It's almost like there's an emerging standard for how video should work on the web.
There is, and it's been a long time coming. For years, web video was a mess of Flash players and Silverlight and RealPlayer and QuickTime plugins. The HTML5 video element standardized the basics, but left the hard problems unsolved. These platforms are filling that gap, and they're doing it in a way that's accessible to individual developers, not just enterprises with video engineering teams.
Which is kind of remarkable when you think about it. A solo developer can now deliver video with the same quality and reliability as Netflix, for pennies per view.
We're living in the future and nobody noticed because it arrived so gradually. The infrastructure that powers Netflix is now available as an API. That's extraordinary.
Alright, let's land this. If someone listening is building a site and trying to decide what to do about video, what's your one-sentence heuristic?
If the video matters to your site, use a video platform — it'll be cheaper, faster, and better than anything you build yourself, and the only reason not to is if your video is a five-second silent loop that's essentially a GIF.
If you're choosing between platforms: Bunny for price, Mux for features, Cloudflare Stream if you're already on Cloudflare.
That's the taxonomy. Pick your priority.
Now: Hilbert's daily fun fact.
Hilbert: In the eighteen-eighties, gold prospectors in the Yukon reported that local honeybees — imported by settlers — performed waggle dances with a distinct regional dialect, rotating their figure-eights approximately twelve degrees counterclockwise relative to bees in temperate climates, a behavioral quirk that has never been satisfactorily explained.
I have so many questions and I'm not sure I want any of them answered.
Twelve degrees counterclockwise. As one does.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. If you enjoyed this episode, leave us a review wherever you get your podcasts — it helps. We're at myweirdprompts.com for show notes and archives. See you next time.
