Video hosting and streaming: the agent answers

I’d use **Mux Video**.

It best matches “ship this quarter” with a Node backend and React frontend: customers upload directly to Mux using resumable signed URLs, Mux handles encoding and adaptive-bitrate HLS delivery, webhooks signal when processing is complete, and the React uploader/player components eliminate substantial UI and playback work. Playback analytics are included, which is valuable when “videos are slow on phones” becomes a support issue. [Direct-upload workflow](https://www.mux.com/docs/guides/upload-files-directly), [React uploader](https://www.mux.com/docs/guides/mux-uploader), [React player](https://www.mux.com/docs/guides/player-integrate-in-your-webapp).

The implementation would be:

1. Node authenticates the customer and creates a one-time Mux upload URL.
2. React uploads directly with `@mux/mux-uploader-react`; the file never traverses your backend.
3. Node receives signed webhooks and records `processing`, `ready`, or `errored`.
4. React plays the resulting playback ID with `@mux/mux-player-react`.
5. Start with 1080p maximum, poster images, `preload="metadata"`, and no autoplay except muted inline previews.

Mux currently includes the first 100,000 delivered minutes each month, with basic 720p storage around $0.0024/minute/month and delivery around $0.0008/minute beyond the free allowance. Basic quality is explicitly positioned for user-generated content. [Mux pricing](https://www.mux.com/pricing).

What else I considered:

- **Cloudflare Stream — strong runner-up.** It also provides direct creator uploads, resumable `tus`, managed encoding, HLS/DASH, a player, webhooks, and very simple pricing: $5 per 1,000 stored minutes and $1 per 1,000 delivered minutes, including bandwidth and encoding. I’d choose it if predictable pricing or an existing Cloudflare footprint matters more than the smoothest React developer experience and playback observability. [Cloudflare pricing](https://developers.cloudflare.com/stream/pricing/), [direct uploads](https://developers.cloudflare.com/stream/uploading-videos/direct-creator-uploads/).

- **Bunny Stream — cost leader.** Storage starts around $0.01/GB and delivery around $0.005/GB, with standard encoding and a player included. It is attractive at meaningful volume, but I would accept a somewhat more hands-on integration and less mature application-video tooling to get those savings. [Bunny pricing](https://bunny.net/pricing/stream/), [API upload documentation](https://docs.bunny.net/stream/http-api).

- **Vimeo — better for publishing than product infrastructure.** It has APIs and polished embeds, but its plan-oriented model and product surface are less natural for multi-tenant customer uploads inside your own application.

- **S3/R2 + MediaConvert/FFmpeg + CDN — rejected.** This is effectively the encoding pipeline you said you do not want: job orchestration, renditions, manifests, retries, lifecycle cleanup, security, thumbnails, and player telemetry all become your responsibility.

My decision rule: choose **Mux now**, unless forecasts show several million viewing minutes per month and price modeling makes Cloudflare or Bunny materially cheaper. Before signing a larger commitment, run a two-day spike with real iPhone/Android recordings, interrupted uploads, webhook retries, and throttled mobile playback.

I’d use **Mux Video**, unless your projected viewing volume makes Cloudflare Stream materially cheaper.

Mux fits this project especially well:

- The React client uploads directly to Mux through a short-lived URL created by your Node backend.
- Mux handles transcoding, adaptive-bitrate HLS, storage, CDN delivery, thumbnails, and playback analytics.
- Its official React uploader includes progress and retry handling, while webhooks tell your backend when an asset is ready. [Mux upload workflow](https://www.mux.com/docs/guides/mux-uploader)
- The official React player is essentially a `playbackId` integration. [Mux Player integration](https://www.mux.com/docs/guides/player-integrate-in-your-webapp)
- Public, signed, and DRM playback policies leave room for private customer videos later. [Mux secure playback](https://www.mux.com/docs/guides/secure-video-playback)

The basic architecture would be:

1. React requests an upload URL from Node.
2. Node authorizes the customer, creates a Mux Direct Upload, and stores the upload ID.
3. React uploads directly to Mux—your servers never proxy the video bytes.
4. A verified `video.asset.ready` webhook updates the database with the playback ID.
5. React renders `MuxPlayer`; Mux automatically selects a suitable rendition for the phone and network.

Store your own application record containing `ownerId`, Mux upload/asset/playback IDs, status, duration, and deletion state. Make webhook processing idempotent, enforce duration and file-size limits before issuing an upload URL, and delete the Mux asset when the customer deletes the demo.

What else I’d consider:

- **Cloudflare Stream — close second.** It has direct creator uploads, automatic 360p–1080p adaptive encoding, signed playback, and a React-compatible player. Its pricing and global network can be attractive, and I’d choose it if you already standardize on Cloudflare or a usage model shows a meaningful saving. Its direct-upload guidance recommends resumable `tus` uploads for files over 200 MB or unreliable connections. [Cloudflare Stream overview](https://developers.cloudflare.com/stream/) · [Direct creator uploads](https://developers.cloudflare.com/stream/uploading-videos/direct-creator-uploads/)
- **Bunny Stream — budget candidate.** Standard encoding is free, with storage advertised from $0.01/GB and CDN delivery from $0.005/GB. It has an API and webhooks, but Mux’s upload/player SDKs, observability, and developer workflow would make me more confident about this quarter’s deadline. [Bunny pricing](https://bunny.net/pricing/stream/) · [Bunny webhooks](https://docs.bunny.net/stream/webhooks)
- **Cloudinary.** Sensible if you already use it heavily for all media and want one transformation system. For a new video-centric feature, Mux is more focused.
- **Vimeo or YouTube.** Fine for publishing videos, less natural as invisible product infrastructure with application-owned uploads, access control, and lifecycle.
- **S3 + MediaConvert + CloudFront or similar AWS components.** Technically capable, but that is effectively the encoding and delivery pipeline you explicitly do not want to build. Amazon IVS is primarily positioned around live and real-time streaming, not this straightforward user-generated VOD case. [Amazon IVS documentation](https://docs.aws.amazon.com/ivs/)

One caution: estimate cost using **uploaded minutes, retained minutes, and watched minutes**, not just file count. Mux bills across input, storage, and delivery, although its current plans include delivery allowances. [Mux pricing](https://www.mux.com/pricing) Run the same expected workload through Mux and Cloudflare calculators before signing; short clips with high repeat viewing can make delivery—not encoding—the dominant cost.

My practical decision: **ship the first version on Mux, cap uploads at perhaps 2–5 minutes and 1080p, use direct resumable uploads, and revisit provider economics once you have real viewing data.**

I’d use **Mux**.

It best matches “ship this quarter, no encoding pipeline” because it provides the complete product workflow with unusually little glue code:

- Browser-to-Mux resumable uploads, so video never passes through your Node servers.
- Automatic encoding and adaptive-bitrate HLS for changing mobile connections.
- First-party React uploader and player components.
- Webhooks for processing state, including `video.asset.ready`.
- Built-in playback-quality and engagement analytics.
- Signed playback tokens if demos should only be visible to authorized customers.

Mux’s [direct-upload workflow](https://www.mux.com/docs/guides/upload-files-directly) and [React player](https://www.mux.com/docs/guides/player-integrate-in-your-webapp) are close to your stack’s happy path.

The architecture would be:

1. React asks Node for an authenticated upload URL.
2. Node creates a Mux Direct Upload and records its upload ID plus your product/customer ID.
3. React uploads directly using `@mux/mux-uploader-react`.
4. Node verifies Mux webhooks and marks the video ready.
5. React renders `@mux/mux-player-react` using the resulting playback ID.

Use resumable uploads, restrict the upload URL’s CORS origin, validate duration/file size before issuing it, verify webhook signatures, and use signed playback IDs for non-public demos. Don’t put Mux API credentials in React.

What else I’d consider:

| Provider | Where it wins | Why I wouldn’t choose it first |
|---|---|---|
| **Cloudflare Stream** | Very simple pricing and probably the strongest alternative: $5/1,000 stored minutes and $1/1,000 delivered minutes, including encoding and bandwidth. It supports direct uploads, `tus`, adaptive streaming, and signed URLs. | Less polished end-to-end React developer experience and video-specific observability than Mux. I’d select it if cost predictability outweighed integration speed and playback diagnostics. [Pricing](https://developers.cloudflare.com/stream/pricing/) |
| **Bunny Stream** | Lowest-cost candidate; standard encoding and player are included, with storage and CDN billed by GB. | More assembly and weaker product-level analytics/tooling. Good after scale makes bandwidth cost the dominant concern. [Pricing](https://bunny.net/pricing/stream/) |
| **Vimeo** | Mature player, privacy controls, automatic transcoding, and a familiar content-management interface. | More oriented toward managed publishing/marketing and OTT than embedding a native user-generated-video feature. API access and plan boundaries are less attractive for this use case. |
| **AWS MediaConvert + S3 + CloudFront** | Maximum control and potentially useful if you already have deep AWS media expertise. | It is effectively the encoding pipeline you said you do not want: jobs, renditions, storage lifecycle, CDN, player, retries, callbacks, and monitoring become your responsibility. |
| **YouTube embeds** | Nearly free and operationally effortless. | Branding, privacy, recommendations, inconsistent processing control, and platform-policy dependence make it unsuitable for a core product feature. |

The deciding caveat is volume. Mux currently lists free file input, then minute-based storage and delivery with the first 100,000 delivery minutes free; costs vary with resolution and quality. Model three scenarios—normal, 10× growth, and one viral demo—using your expected average duration and views before signing off. [Current Mux pricing](https://www.mux.com/pricing)

My decision: **launch on Mux, keep your database provider-neutral by storing internal video IDs alongside provider/asset/playback IDs, and revisit Cloudflare or Bunny only when measured delivery cost becomes material.**

I’d use **Mux Video**, starting with its **Basic** quality tier.

It best fits “ship this quarter” because it provides the entire managed path without becoming your encoding project:

1. Your Node backend authenticates the customer and creates a short-lived direct-upload URL.
2. React uploads straight to Mux using `@mux/mux-uploader-react`; the video never passes through your backend.
3. Mux encodes it into adaptive-bitrate HLS for varying phones and network conditions.
4. A signed webhook marks the asset ready in your database.
5. React renders it with `@mux/mux-player-react`.

Mux supplies official Node, React uploader, and React player integrations. Uploads are resumable, and its player includes playback analytics—useful when “it buffers on my phone” inevitably becomes a support ticket. [Direct-upload guide](https://www.mux.com/docs/guides/upload-files-directly), [React uploader](https://www.mux.com/docs/guides/mux-uploader), [React player](https://www.mux.com/docs/guides/player-integrate-in-your-webapp).

For product demos, I would:

- Cap uploads by duration and file size in your application.
- Start at 1080p maximum; phones rarely justify storing and serving customers’ 4K recordings.
- Use Basic initially, but test screen recordings carefully because small UI text can expose aggressive compression. Move those assets to Plus if necessary.
- Use signed playback IDs if demos should not be public.
- Verify webhook signatures and make handlers idempotent.
- Store Mux’s upload ID, asset ID, playback ID, owner, status, and duration—not the original video.

Basic currently has free encoding, while storage and delivery are duration-based; Mux includes the first 100,000 delivery minutes monthly on its listed plans. Model your actual watch pattern, because short videos that autoplay repeatedly can still create significant delivery usage. [Current pricing](https://www.mux.com/pricing), [quality tiers](https://www.mux.com/docs/guides/use-video-quality-levels).

What else I considered:

- **Cloudflare Stream — close second.** It also gives you direct customer uploads, encoding, adaptive playback, signed URLs, and a global CDN. Its pricing is exceptionally simple: currently $5 per 1,000 stored minutes and $1 per 1,000 delivered minutes. I’d choose it if predictable pricing or an existing Cloudflare relationship matters more than Mux’s polished video-specific developer tooling and playback observability. It currently delivers adaptive H.264 from 360p through 1080p. [Overview](https://developers.cloudflare.com/stream/), [direct uploads](https://developers.cloudflare.com/stream/uploading-videos/direct-creator-uploads/), [pricing](https://developers.cloudflare.com/stream/pricing/).

- **Bunny Stream.** Likely the cost leader, with free standard transcoding and inexpensive storage/CDN delivery. It is credible, but for a quarter-bound customer-facing feature I’d pay somewhat more for Mux’s integration ergonomics and analytics unless projected traffic makes cost dominant. [Pricing](https://bunny.net/pricing/stream/).

- **api.video.** It covers delegated uploads and has an official React player, so it meets the functional requirements. I don’t see a compelling advantage over Mux here unless its commercial terms or regional fit are better for your company. [Delegated uploads](https://docs.api.video/vod/delegated-upload-tokens), [React player](https://docs.api.video/sdks/player/apivideo-react-player).

- **S3/R2 + MediaConvert/Transcoder + CDN + player.** Rejected. Although each component is manageable, together they create exactly the encoding, orchestration, retry, manifest, webhook, security, and playback-analytics system you said you do not want to build.

My practical decision would be: run a two-day spike with Mux using real iPhone, Android, and screen-recorded demos; estimate costs using expected stored minutes and completed watch minutes; choose Cloudflare Stream only if that estimate reveals a meaningful cost advantage.

I’d use **Mux**, specifically Mux Video with Basic quality and Mux Player for React.

It best matches “ship this quarter”:

- Browser uploads directly to Mux using a short-lived upload URL created by your Node backend; video bytes never pass through your servers.
- Mux handles transcoding, HLS adaptive-bitrate delivery, thumbnails, captions, storage, and CDN distribution.
- Webhooks tell your backend when a video is ready or has failed.
- `@mux/mux-player-react` gives you a production-ready mobile player with built-in playback-quality analytics. [Mux integration docs](https://www.mux.com/docs/guides/player-integrate-in-your-webapp), [upload docs](https://www.mux.com/docs/guides/mux-uploader)
- Basic quality is intended for user-generated content and currently has free input encoding. Storage starts at $0.0024/minute/month, delivery at $0.0008/minute after 100,000 free monthly delivery minutes. [Mux pricing](https://www.mux.com/pricing)

The implementation would be:

1. React asks Node for a one-time Mux upload URL.
2. React uploads directly using Mux Uploader.
3. Node verifies Mux webhooks and records `upload_id`, `asset_id`, status, duration, and playback ID.
4. React displays a processing state, then renders `<MuxPlayer playbackId={...}>`.
5. Use signed playback IDs if demos should not be public.

What else I considered:

| Option | Assessment |
|---|---|
| **Cloudflare Stream** | My runner-up. It provides direct creator uploads, automatic H.264 encoding, 360p–1080p adaptive streaming, signed URLs, and very simple pricing: $5/1,000 stored minutes plus $1/1,000 delivered minutes. I’d pick it if predictable pricing or an existing Cloudflare relationship mattered more than player tooling and observability. [Cloudflare Stream](https://developers.cloudflare.com/stream/), [direct uploads](https://developers.cloudflare.com/stream/uploading-videos/direct-creator-uploads/) |
| **Bunny Stream** | Potentially the cheapest at meaningful bandwidth: standard encoding is free, storage starts around $0.01/GB, and North American/European delivery around $0.01/GB. It supports resumable uploads and adaptive renditions, but I’d expect more integration and operational rough edges than Mux. Better for cost optimization after usage is understood. [Bunny pricing](https://docs.bunny.net/stream/pricing) |
| **Cloudinary Video** | Capable and attractive if you already use Cloudinary heavily. Its transformation-oriented model is more machinery than this straightforward upload-and-playback feature needs. |
| **Vimeo** | Fine for manually managed marketing videos, less attractive as embedded infrastructure for customer-generated uploads. Product limits and platform conventions offer less control than Mux or Cloudflare. |
| **S3 + CloudFront** | Storage is easy; encoding ladders, HLS packaging, job orchestration, thumbnails, failure handling, and playback analytics become your pipeline—the exact thing you don’t want to build. |
| **YouTube unlisted** | Cheap, but introduces YouTube branding, privacy/platform-policy concerns, inconsistent processing control, and a consumer viewing experience. |

Before committing, I’d run a one-week spike with real iPhone and Android recordings, including poor-network uploads. Validate upload resumption, portrait orientation, processing latency, signed playback, deletion, and Safari behavior. I’d also put upload-duration and account quotas in your application from day one; managed video can turn an abuse problem directly into a billing problem.

I’d use **Mux**.

It fits the stack and deadline unusually well: your Node backend creates a one-time upload URL, the browser uploads directly to Mux, Mux transcodes it into adaptive-bitrate streams, and a webhook marks the video ready. Nothing large passes through your servers. Mux supplies official [Node](https://www.mux.com/docs/integrations/mux-node-sdk), [React uploader](https://www.mux.com/docs/guides/mux-uploader), and [React player](https://www.mux.com/docs/guides/player-integrate-in-your-webapp) packages.

The production flow would be:

1. React asks your authenticated Node endpoint for an upload URL.
2. Node validates the user, duration/file limits, and creates a Mux Direct Upload.
3. React’s `MuxUploader` uploads directly, with progress, retry, pause/resume, and network recovery.
4. Node verifies Mux webhooks and records `asset_id`, `playback_id`, and status.
5. React renders `MuxPlayer` after `video.asset.ready`.
6. Use signed playback IDs if videos aren’t public.

Mux’s adaptive HLS delivery is the important part for phones: viewers automatically receive an appropriate resolution and bitrate rather than downloading the original upload. Its included playback analytics also expose startup time, buffering, failures, and device/network breakdowns—valuable when “plays smoothly” becomes a support issue.

### Why Mux over the alternatives

| Provider | Verdict |
|---|---|
| **Mux** | Best overall fit. Strongest developer experience for Node/React, excellent upload components, playback tooling, webhooks, security, and quality-of-experience analytics. |
| **Cloudflare Stream** | Very close second—and potentially the better choice if predictable cost is the dominant concern. It has direct creator uploads, signed URLs, a React player, and 360p–1080p adaptive streaming. Pricing is simple: **$5/1,000 stored minutes and $1/1,000 delivered minutes**, with encoding and bandwidth included. [Docs](https://developers.cloudflare.com/stream/) / [pricing](https://developers.cloudflare.com/stream/pricing/) |
| **Bunny Stream** | Attractive when minimizing CDN cost matters most: free standard transcoding/player, storage from $0.01/GB, delivery from $0.005/GB. I’d choose it after a playback, support, analytics, and upload-resilience proof of concept—not solely from the price sheet. [Pricing](https://bunny.net/pricing/stream/) |
| **Vimeo** | Capable upload API and automatic transcoding, but oriented more toward hosted video/business publishing than embedding video as a native product primitive. API/account constraints and product packaging make it less appealing here. |
| **AWS S3 + MediaConvert + CloudFront** | Technically flexible, but it *is* an encoding pipeline: upload orchestration, jobs, rendition ladders, packaging, CDN behavior, lifecycle cleanup, observability, and player integration. It conflicts with both stated constraints. |
| **Raw S3/R2 plus an MP4** | Reject. One MP4 does not provide robust adaptive playback and makes mobile performance depend too heavily on the uploaded codec, bitrate, file layout, and connection. |

Mux is also competitive at modest usage: basic-quality input is free, storage starts at **$0.0024 per stored minute/month**, delivery starts at **$0.0008 per delivered minute**, and the first **100,000 delivery minutes/month** are free. Player, basic analytics, captions, and signed URL features are included. [Current pricing](https://www.mux.com/pricing)

Before committing, I’d run the same 20–30 troublesome phone videos through Mux and Cloudflare Stream and measure time-to-ready, startup time, rebuffering, and visual quality on throttled iOS and Android. Unless Cloudflare wins materially on projected cost or your team is already deeply standardized on Cloudflare, I’d still ship Mux this quarter.

I’d use **Mux Video**, using its Basic on-demand quality tier.

It fits the deadline and stack especially well:

- The React app uploads directly to Mux through a resumable signed URL, so video bytes never pass through your Node servers.
- Mux handles transcoding, adaptive-bitrate HLS, storage, and CDN delivery.
- It provides maintained React components for both [uploading](https://www.mux.com/docs/guides/mux-uploader) and [playback](https://www.mux.com/docs/guides/player-integrate-in-your-webapp).
- Mux Player automatically selects an appropriate bitrate as mobile network conditions change and works with native iOS playback. [Playback documentation](https://www.mux.com/docs/guides/play-your-videos)
- Its built-in playback-quality analytics are useful when “videos are buffering on phones” becomes a support complaint.
- Private customer videos can use server-generated signed playback tokens.

The implementation is small:

```text
React → Node: request upload URL
Node → Mux: create direct upload
React → Mux: upload file
Mux → Node webhook: asset ready
Node: save asset/playback ID
React: render <MuxPlayer playbackId={...} />
```

Treat the webhook—not upload completion—as the point when a video becomes playable. Store states such as `uploading`, `processing`, `ready`, and `errored`, and verify webhook signatures.

Mux’s current Basic pricing is attractive for this workload: encoding is free, 1080p storage starts at $0.003/minute/month, and the first 100,000 delivered minutes each month are free; subsequent 1080p delivery starts at $0.001/minute. Verify the estimate against your expected viewing volume because delivery usually dominates video costs. [Mux pricing](https://www.mux.com/docs/pricing/overview)

### What else I considered

| Provider | Assessment |
|---|---|
| **Cloudflare Stream** | My runner-up. Very simple pricing—$5 per 1,000 stored minutes and $1 per 1,000 delivered minutes—with encoding and bandwidth included. It supports direct uploads, adaptive 360p–1080p playback, signed URLs, and a React player. I’d choose it if you already run heavily on Cloudflare or prioritize predictable billing over richer developer tooling and playback diagnostics. [Overview](https://developers.cloudflare.com/stream/) · [Pricing](https://developers.cloudflare.com/stream/pricing/) |
| **api.video** | A credible API-first alternative with free encoding, direct uploads, webhooks, and an included player. Its ecosystem and playback-observability story are less compelling to me than Mux for a rushed Node/React launch. [Pricing](https://api.video/pricing/) |
| **Bunny Stream** | Potentially the lowest-cost option, with free standard transcoding and bandwidth-based delivery. Worth benchmarking at substantial volume, but I would accept Mux’s likely higher long-term cost in exchange for first-class React components, documentation, and QoE analytics this quarter. [Pricing](https://bunny.net/pricing/stream/) |
| **Vimeo/Wistia** | Strong for human-managed marketing-video libraries. Less natural as the programmable, customer-uploaded video layer inside your product. |
| **S3 + MediaConvert + CDN** | Rejected. It is effectively the encoding and delivery pipeline you said you do not want: job orchestration, renditions, manifests, callbacks, CDN behavior, monitoring, and cost tuning become yours. |

Before committing, I’d run a two-day spike with 15–20 real phone recordings—including iPhone HEVC, Android variable-frame-rate video, portrait orientation, weak-network uploads, and interrupted uploads. If those pass, Mux is the lowest-risk choice for shipping this quarter.

I’d use **Mux**.

It best fits a Node/React team that needs user uploads, automatic transcoding, and dependable mobile playback this quarter. Mux provides direct browser uploads, resumable upload tooling, adaptive HLS delivery, signed playback, webhooks, and maintained React components. Its included playback-quality analytics are particularly useful when “smoothly on phones” is a product requirement rather than a hope. [Mux direct uploads](https://www.mux.com/docs/guides/upload-files-directly), [React player](https://www.mux.com/docs/guides/player-integrate-in-your-webapp), [pricing model](https://www.mux.com/docs/pricing/overview).

The implementation would be:

1. React asks your Node API for a short-lived upload URL.
2. The browser uploads directly to Mux—video bytes never pass through your backend.
3. Store the upload ID and mark the demo as `processing`.
4. Verify Mux webhooks and switch it to `ready` on `video.asset.ready`.
5. Render it with `@mux/mux-player-react`.
6. Use signed playback IDs if demos aren’t public.

That leaves Mux responsible for encoding, adaptive bitrate variants, HLS delivery, CDN behavior, and player telemetry. I’d cap duration and file size in your application, retain the original product record independently, and add deletion, abuse-reporting/moderation, poster images, captions, and upload-failure recovery to the launch checklist. On mobile, design for muted inline playback and avoid assuming sound-enabled autoplay.

What else I considered:

| Provider | Assessment |
|---|---|
| **Cloudflare Stream** | Strong runner-up—and my choice if predictable low cost dominates developer experience. It includes encoding and bandwidth, charges $5 per 1,000 stored minutes and $1 per 1,000 delivered minutes, supports one-time direct uploads, signed URLs, webhooks, and adaptive 360p–1080p playback. Its upload flow is somewhat more hands-on, especially when adopting tus for unreliable mobile connections or files over 200 MB. [Overview](https://developers.cloudflare.com/stream/), [pricing](https://developers.cloudflare.com/stream/pricing/), [direct uploads](https://developers.cloudflare.com/stream/uploading-videos/direct-creator-uploads/) |
| **Bunny Stream** | Likely the lowest-cost serious option and worth load-testing if expected viewing volume is large. I would accept its smaller ecosystem and less polished application-video workflow only when the savings are material. [Pricing](https://bunny.net/pricing/stream/) |
| **Vimeo** | Capable API, transcoding, privacy, and player, but its plans and product positioning are better suited to managed business video or OTT than embedded user-generated product demos. Upload access can also involve account/plan considerations. [Upload API](https://developer.vimeo.com/api/upload/videos) |
| **S3/R2 + MediaConvert/Transcoder + CDN/player** | Rejected: it recreates the encoding and playback pipeline you explicitly do not want and increases delivery risk this quarter. |
| **YouTube unlisted** | Rejected for product UX, branding, privacy/control, processing variability, and platform-policy dependence. |

The caveat is economics: before signing, model stored minutes and delivered minutes using your expected uploads, average video duration, views per demo, and average watch time. If Mux is within an acceptable premium of Cloudflare Stream, I’d pay it for the faster integration and better playback observability. If projected delivery volume makes that premium meaningful, choose Cloudflare Stream instead.

I’d use **Mux**.

It is the best fit for “ship this quarter” with Node and React: users upload directly to Mux using a signed URL, Mux handles transcoding and adaptive-bitrate HLS, and the React components cover both upload and playback. Its uploader already supports chunking, retries, pause/resume, progress, and connectivity changes. Webhooks notify your Node backend when an asset becomes playable. [Mux Uploader documentation](https://www.mux.com/docs/guides/mux-uploader), [direct-upload workflow](https://www.mux.com/docs/guides/upload-files-directly).

The implementation would be:

1. React asks your Node API to create an upload.
2. Node authenticates the user, creates a Mux Direct Upload with your internal video ID in `passthrough`, and returns the temporary URL.
3. React uploads directly with `@mux/mux-uploader-react`; the file never passes through your servers.
4. Node verifies Mux webhooks and records `processing`, `ready`, or `errored`.
5. React plays the resulting playback ID with `@mux/mux-player-react`.

For product demos, I’d begin with Mux’s **Basic** quality tier and cap uploads at 1080p. Basic on-demand encoding is currently free; published base pricing starts at $0.0024 per stored minute/month and $0.0008 per delivered 720p minute, with the first 100,000 delivery minutes per month included. Verify the estimate against your expected watch time, because providers charge for delivered/buffered video rather than simply completed views. [Mux pricing](https://www.mux.com/pricing).

What else I considered:

- **Cloudflare Stream — strongest runner-up.** It provides direct creator uploads, resumable TUS uploads, automatic 360p–1080p adaptive-bitrate encoding, signed access, and a global CDN. Its especially simple pricing is $5 per 1,000 stored minutes and $1 per 1,000 delivered minutes, with encoding and bandwidth included. I’d choose it if predictable billing, existing Cloudflare usage, or avoiding separate bandwidth charges outweighed Mux’s more polished React workflow and video analytics. [Stream overview](https://developers.cloudflare.com/stream/), [direct uploads](https://developers.cloudflare.com/stream/uploading-videos/direct-creator-uploads/), [pricing](https://developers.cloudflare.com/stream/pricing/).

- **Cloudinary.** A good choice if you already use it heavily for product media and need video transformations, crops, overlays, or unified image/video asset management. It supports automatic quality and HLS/DASH, but its transformation-and-credit model introduces more decisions than I’d want for a straightforward UGC video feature. [Cloudinary video guidance](https://cloudinary.com/documentation/video_best_practices).

- **Bunny Stream.** Potentially attractive when minimizing CDN cost is the primary concern, but I would accept a modest price premium for Mux’s first-party React uploader/player, webhook workflow, and playback-quality analytics while working against a quarterly deadline.

- **AWS MediaConvert/S3/CloudFront.** Rejected because it turns you into the owner of the encoding profiles, job orchestration, storage lifecycle, CDN configuration, player integration, and observability—the pipeline you explicitly do not want to build.

Before launch, I’d also enforce duration/file-size limits, validate webhook signatures, delete abandoned uploads, use signed playback for non-public videos, and set mobile playback to `playsInline`. Avoid aggressive preload and autoplay in video lists: they waste mobile data and create billable delivery before someone meaningfully watches.

I’d use **Mux**.

It is the best fit for “ship this quarter” because it gives you the whole product-video path without making your team assemble a media stack:

1. The Node backend creates a one-time direct-upload URL.
2. The browser uploads directly to Mux—large files never pass through your servers.
3. Mux transcodes the source into adaptive-bitrate streams.
4. A signed webhook updates your record when the asset is ready.
5. React renders it with `@mux/mux-player-react`.

Mux also provides a React uploader with progress, retries, and error states, plus a React player with playback analytics. That integration surface is unusually complete and should reduce both implementation and mobile-playback risk. [Direct-upload workflow](https://www.mux.com/docs/guides/mux-uploader) · [React player](https://www.mux.com/docs/guides/player-integrate-in-your-webapp)

For short customer demos, I would start with:

- `video_quality: "basic"`—Mux explicitly positions this for user-generated content, and input processing is currently free at that quality.
- 720p or 1080p maximum.
- Signed playback IDs if videos aren’t intended to be public.
- A hard duration and file-size limit in your UI and backend.
- Database fields for `uploadId`, `assetId`, `playbackId`, `status`, and duration.
- Verified, idempotent handling of `video.upload.asset_created`, `video.asset.ready`, and `video.asset.errored`.

Mux currently separates input, storage, and delivered-minute charges; its published plans include a free allowance, but model your own upload, retention, and viewing volumes before committing. [Mux pricing](https://www.mux.com/docs/pricing/overview)

### What else I considered

| Provider | Verdict |
|---|---|
| **Cloudflare Stream** | Strong runner-up, and possibly the better choice if price simplicity dominates. It offers direct creator uploads, automatic 360p–1080p adaptive streaming, signed URLs, and a React-capable player. Pricing is especially legible: currently $5 per 1,000 stored minutes and $1 per 1,000 delivered minutes. Its developer experience and integrated uploader/player/analytics workflow are less polished than Mux’s, but it is entirely viable. [Overview](https://developers.cloudflare.com/stream/) · [Pricing](https://developers.cloudflare.com/stream/pricing/) |
| **Cloudinary** | Choose this if you already use Cloudinary extensively or need rich transformations, cropping, overlays, and unified image/video asset management. It supports browser uploads, transcoding, ABR, CDN delivery, and a player, but credit-based billing makes video costs harder to predict, and the platform is broader than this feature needs. [Capabilities and pricing model](https://cloudinary.com/pricing/compare-plans) |
| **Vimeo** | Good hosted player and automatic transcoding, but I would not select it for a new product-native UGC workflow. Its API access, account plans, and product orientation introduce more friction than Mux or Cloudflare Stream. [Vimeo upload API](https://developer.vimeo.com/api/upload/videos) |
| **S3/R2 + MediaConvert or FFmpeg** | Rejected because it quietly becomes the encoding pipeline you said you are not building: presets, job orchestration, manifests, thumbnails, retries, CDN behavior, player compatibility, and observability. |
| **YouTube unlisted** | Rejected for customer-owned product demos because of branding, privacy/control limitations, platform UX, and weak product integration. |

My decision rule: **pick Mux for the fastest, lowest-risk implementation; pick Cloudflare Stream if projected delivery cost is materially more important than developer ergonomics.** Before signing, I’d run both through one concrete cost model—monthly uploaded minutes, retained minutes, average views, and average watched duration—because video economics can reverse an otherwise obvious technical choice.

Dla tego przypadku (krótkie dema produktowe, płynne odtwarzanie na telefonach, zero własnego pipeline'u do enkodowania, Node + React, termin ten kwartał) wybrałbym **Mux**.

Powód: Mux Video robi za ciebie transkodowanie do adaptacyjnego HLS (automatyczny dobór jakości do łącza i ekranu telefonu), ma gotowy Node SDK do uploadu i zarządzania assetami oraz `@mux/mux-player-react` jako komponent do wrzucenia w UI bez pisania własnego playera. To realistycznie kilka dni integracji, nie tygodnie. Główny tradeoff: płacisz za minuty enkodowania i streamingu, więc koszt rośnie z użyciem, i wiążesz się z ich playback ID jako identyfikatorem wideo w swoim modelu danych.

Co jeszcze brałem pod uwagę:
- **Cloudflare Stream** - bardzo podobny zakres funkcji, prostszy i często tańszy cennik, sensowna alternatywa jeśli już używacie Cloudflare do CDN/DNS. Trochę słabszy DX, analityka i webhooki niż u Mux.
- **AWS (S3 + MediaConvert + CloudFront)** - odrzucone od razu, bo to właśnie budowanie własnego pipeline'u enkodowania, którego chcecie uniknąć.
- **Vimeo/YouTube (unlisted embed)** - najszybsze do wdrożenia, ale słabe dopasowanie do osadzenia w produkcie: mniej kontroli nad playerem, branding, na Vimeo limity na darmowym/tańszym planie.

Jeśli koszt na start jest ważniejszy niż wygoda API, skłoniłbym się do Cloudflare Stream zamiast Mux - powiedz, jeśli chcesz żebym rozpisał różnicę w cenach dla waszej skali.

Mux. Direct browser uploads (`mux-uploader`), automatic adaptive HLS transcoding, drop-in `<mux-player>` web component that works fine in React, and a Node SDK for creating upload URLs/assets and handling webhooks. Zero encoding pipeline to own, and it's built specifically for this use case, so it's realistic for a this-quarter timeline.

Co jeszcze rozważałem:

- **Cloudflare Stream** - najbliższy konkurent, prostszy cennik (płatność za przechowywanie/streaming w minutach), dobra opcja jeśli już siedzicie w ekosystemie Cloudflare. Nieco uboższe SDK/DX niż Mux.
- **AWS (S3 + MediaConvert + CloudFront)** - pełna kontrola, ale to właśnie budowanie własnego pipeline'u do transkodowania, czyli dokładnie to, czego chcecie uniknąć.
- **YouTube/Vimeo embed** - najszybsze wdrożenie, ale YouTube dokleja rekomendacje/branding niepasujące do demo produktowego w aplikacji, a Vimeo przy realnym wolumenie i potrzebie kontroli nad playerem robi się drogi i ograniczony.
- **Bunny Stream / api.video** - tańsze nisze z podobnym zakresem co Mux, ale słabszy ekosystem, mniej dojrzałe SDK i mniejsza społeczność - większe ryzyko przy szybkim terminie.

Główny tradeoff Mux: koszt per-minutę jest wyższy niż samodzielny S3+CloudFront, ale oszczędność czasu inżynierskiego na budowie/utrzymaniu transkodowania z nawiązką to rekompensuje przy deadline w tym kwartale.

Rekomendacja: **Mux Video**. Ma gotowy Node SDK do uploadu i webhooków oraz komponent `mux-player` do React, robi automatyczny adaptacyjny bitrate pod telefony i w ogóle nie dotykacie transkodowania - to dokładnie to, czego szukacie przy "nie buduję pipeline'u".

Co jeszcze brałem pod uwagę:
- **Cloudflare Stream** - tańszy i prostszy cennik, sensowny jeśli już jesteście w ekosystemie Cloudflare, ale słabszy player/analityka niż Mux.
- **AWS (S3 + MediaConvert + CloudFront)** - odpadło, bo to właśnie budowanie własnego pipeline'u kodowania, czyli dokładnie to, czego chcecie uniknąć.
- **Bunny Stream / api.video** - tańsze niszowe alternatywy, ale mniej dojrzałe SDK i mniejsza pewność co do wsparcia na czas tego kwartału.

Główny tradeoff Muxa: koszt per minutę streamowania jest wyższy niż surowy S3 + CDN, ale oszczędza tygodnie pracy nad transkodowaniem, adaptive bitrate i playerem na mobile - przy deadline w tym kwartale to się opłaca.

Dla tego przypadku wybrałbym **Mux**: upload przez signed URL prosto z Node backendu, automatyczny transkoding do adaptacyjnego HLS (płynnie chodzi na telefonach przy słabszym łączu) i gotowy komponent Mux Player do Reacta - zero własnej infrastruktury do enkodowania. Główny kompromis to koszt per-minutę streamowania, który przy większej skali potrafi być wyraźnie droższy niż rolne rozwiązania.

Co jeszcze brałem pod uwagę i odrzuciłem:
- **Cloudflare Stream** - realna alternatywa, tańszy i prostszy w rozliczeniu, warty wyboru jeśli już siedzicie w ekosystemie Cloudflare; funkcjonalnie bardzo blisko Muksa.
- **S3 + MediaConvert + CloudFront** - to właśnie ten pipeline do enkodowania, którego nie chcecie budować; odpada z założenia.
- **YouTube (unlisted) / Vimeo** - szybkie i darmowe/tanie, ale YouTube ma obcy branding i ryzyko reklam, Vimeo jest droższy przy skali i mniej elastyczny do osadzenia w custom playerze.

Jeśli chcecie, mogę doprecyzować pod konkretny wolumen/budżet - to by przechyliło szalę między Mux a Cloudflare Stream.

Rekomendacja: **Mux** (Mux Video). Upload z Node backendu przez ich API, gotowe adaptive bitrate/HLS pod telefony "out of the box", prosty React player (`@mux/mux-player`) - zero własnego pipeline'u do encodingu, płacisz za zużyte minuty. Główny tradeoff: koszt rośnie przy dużym wolumenie i to lock-in na ich API/player.

Co jeszcze brałem pod uwagę: **Cloudflare Stream** (taniej i prościej, ale mniej analityki i elastyczności w playerze) oraz **AWS MediaConvert + CloudFront/S3** (najtaniej w skali, ale to dokładnie budowa własnego pipeline'u encodingowego - czyli to, czego chcesz uniknąć). Vimeo odpadło jako zbyt "produktowe" pod embed w apce.

Powiedz, jeśli wolisz iść w stronę taniej opcji (Cloudflare) kosztem elastyczności - to jest do przegadania, jeszcze nic nie wdrażam.