Cloudflare Workers FFmpeg Video Processing: WebAssembly Limits in 2026

Why do developers try to run ffmpeg in Cloudflare Workers?

Cloudflare Workers is fast, cheap, and global. When you have a video processing task and want to avoid managing servers, Workers looks like a natural fit. It runs JavaScript on the edge. ffmpeg is the standard tool for video. The idea of combining them is tempting.

But Workers was not designed for video processing. The V8 isolate architecture that makes Workers fast and secure also makes it fundamentally incompatible with running ffmpeg. There is no way to spawn a subprocess, install a binary, or use the native ffmpeg C library. Everything goes through JavaScript and WebAssembly.

This article covers every Cloudflare Workers limit that makes ffmpeg video processing impractical, explains what ffmpeg.wasm can and cannot do, and presents the practical alternatives that actually work in production.

Key Takeaways

• Cloudflare Workers cannot run native ffmpeg because the V8 isolate architecture does not support subprocess spawning or arbitrary binary execution.
• ffmpeg.wasm (the WebAssembly port) runs in Workers but hits hard limits: 128 MB memory per isolate, 5-minute CPU time on paid plans, no multi-threading, and a 2 GB maximum file size ceiling.
• WASI on Workers is experimental and lacks the filesystem and socket APIs that ffmpeg requires.
• Durable Objects extend CPU time to 10 minutes but do not increase the 128 MB memory limit or add threading support.
• The practical solution is offloading video processing to a dedicated hosted ffmpeg API like Very Good FFmpeg, which has no memory ceiling, no CPU timeout, and GPU acceleration.

How do Cloudflare Workers work under the hood?

Cloudflare Workers run on V8 isolates, not containers or virtual machines. This is the single most important architectural decision that determines what you can and cannot run.

A V8 isolate is a lightweight sandbox within a single operating system process. Multiple customer Workers share the same OS process. This design enables near-zero cold start times (a Worker starts in under 5 milliseconds) and strict multi-tenant security. But it also means there is no process-level isolation between Workers.

The tradeoff is spelled out clearly in Cloudflare's own blog post, "Cloud Computing without Containers." An isolate-based system cannot run arbitrary compiled code. There is no child_process module, no exec() or spawn() calls. You cannot upload a compiled ffmpeg binary and run it.

Compare this to AWS Lambda, which runs inside actual Firecracker microVMs. Lambda can include a static ffmpeg binary in its deployment package and spawn it as a subprocess. Workers cannot do this at all.

What does "no subprocess support" actually mean?

The Workers JavaScript runtime deliberately omits the Node.js child_process module. There is no spawn(), no exec(), no fork(). These are not missing features — they are excluded by design because the isolate architecture makes them impossible to implement safely.

This means you cannot:

• Install ffmpeg via npm and call it as a binary. The ffmpeg-static npm package that works on Vercel and Lambda is useless here.
• Upload a compiled ffmpeg binary in your Worker bundle. Even if you could, the Worker size limit is 10 MB gzipped and 64 MB uncompressed. A static ffmpeg binary is around 70 MB.
• Use any npm package that shells out to a system command. Packages like fluent-ffmpeg wrap the ffmpeg CLI and will fail.

The only path forward is WebAssembly.

What is ffmpeg.wasm?

ffmpeg.wasm is a pure WebAssembly port of FFmpeg compiled through Emscripten. It runs entirely in the browser (or any WebAssembly runtime) without any native dependencies. The project has 18,000 stars on GitHub and carries a stability-experimental tag.

ffmpeg.wasm works by compiling a subset of FFmpeg's codecs and filters to WebAssembly. It can handle common operations like transcoding, resizing, trimming, and concatenation. It runs in environments where native binaries are unavailable — including Cloudflare Workers.

But "can run" is not the same as "works well for video processing."

What are the Cloudflare Workers WebAssembly limits in 2026?

Every Worker runs inside hard resource caps. These caps exist regardless of whether you use JavaScript or WebAssembly. When you try to run ffmpeg.wasm inside a Worker, you hit multiple limits at once.

Memory limit: 128 MB per isolate

Each Worker gets 128 MB of memory. This is a hard limit shared between your JavaScript code, the WebAssembly module, and the video data in memory.

ffmpeg.wasm needs to load the entire video file into memory before processing. A typical 1080p video file compressed with H.264 is 100-500 MB. Even a short 30-second clip at high bitrate can exceed 128 MB. When Workers hit the memory limit, the isolate is terminated with an Out of Memory (OOM) error.

The ffmpeg.wasm FAQ acknowledges this limitation: "WebAssembly is still a lot slower than native." It also notes a maximum input file size of 2 GB imposed by the Wasm runtime. In practice, Workers OOM at far smaller files.

CPU time limit: 5 minutes

Workers on the Paid plan get 5 minutes of CPU time per HTTP request. The Free plan gets 10 milliseconds — essentially useless for any video work.

Five minutes sounds like enough time, but ffmpeg.wasm is slower than native ffmpeg. The FAQ states that WebAssembly is significantly slower than native code. Encoding a 5-minute 1080p video with ffmpeg.wasm can take 10-15 minutes of CPU time on a single thread.

Here is a comparison of what different platforms can handle:

Worker size limit: 10 MB gzipped

The total Worker bundle size is limited to 10 MB gzipped and 64 MB uncompressed. The ffmpeg.wasm core WebAssembly binary is approximately 30 MB uncompressed. Bundling it alone consumes half of the total size budget before writing any application code.

You can use Cloudflare's wasm module support to load the WebAssembly module separately, but the size constraint still applies to the total Worker deployment.

No threading support

Cloudflare Workers run on a single thread. WebAssembly threading (shared memory and atomics) is not supported in the Workers runtime. The documentation explicitly states: "Threading is not possible in Workers. Each Worker runs in a single thread, and the Web Worker API is not supported."

ffmpeg uses multi-threaded decoding and encoding by default. When compiled to single-threaded WebAssembly, those code paths fall back to sequential execution. For a task like video transcoding that parallelizes well across cores, this means 4x to 6x slower performance compared to native multi-threaded execution.

File size ceiling: 2 GB

The WebAssembly runtime itself imposes a 2 GB maximum file size for any single input. This is a hard limit of the Wasm memory model. In practice, Workers hit the 128 MB memory OOM limit long before reaching 2 GB, but the ceiling exists even if the memory limit were raised.

Video files for typical use cases exceed both limits:

What about WASI on Cloudflare Workers?

WASI (WebAssembly System Interface) extends WebAssembly with system-level capabilities like file I/O and socket access. Cloudflare announced WASI support on Workers in 2022 as an experimental feature.

However, the WASI implementation on Workers only supports a subset of system calls. It can run simple CLI programs that operate on stdin-to-stdout streams — demos include hexyl (a hex viewer) and zstd (a compression tool). It does not support the filesystem access or socket APIs that ffmpeg requires for reading video files, writing temporary files, or streaming network sources.

For ffmpeg to work via WASI, it would need:

• Full filesystem access for reading input files and writing output files.
• Socket support for network stream protocols like RTSP and HLS.
• Process spawning for codec plugins and filters.

None of these are available in the current WASI implementation on Workers. The documentation for WASI on Workers says it is "experimental" and "not all syscalls are implemented." This has not changed meaningfully since the 2022 announcement.

Can Durable Objects help with ffmpeg?

Durable Objects are a Workers feature that provides consistent storage and longer execution time. Each Durable Object invocation gets up to 10 minutes of CPU time, compared to 5 minutes for a standard Worker.

The longer CPU time helps with one problem — the 5-minute timeout — but the memory limit remains at 128 MB, and threading is still unavailable. A Durable Object will also OOM on any video larger than a short clip.

Durable Objects might work for very small jobs: generating a thumbnail from a 10-second clip, or re-wrapping a small video container from one format to another. Anything beyond that runs into the same hard barriers.

What happens when you try to run ffmpeg.wasm in a Worker?

The community has tried this path repeatedly. The experience follows a predictable pattern.

First, bundling fails. The ffmpeg.wasm module is too large for the 10 MB gzip Worker size limit. You need to use wasm module imports in wrangler.toml to load it separately, which reduces the bundle pressure but adds deployment complexity.

Second, on the first real video file, the Worker hits the memory limit. Even a 50 MB video file causes OOM crashes because ffmpeg.wasm needs working memory beyond the file size for decode buffers, intermediate frames, and encode buffers.

Third, reducing the video to a tiny test file reveals the CPU time limit. A 30-second video transcoded with single-threaded WebAssembly ffmpeg takes 3-4 minutes of CPU time. For longer videos, the 5-minute limit is insufficient.

The Cloudflare community forums and GitHub issues contain many threads from developers who tried this and gave up. Common phrases include "it works for tiny files," "memory limit kills it," and "just use a hosted API instead."

What do developers actually do instead?

Developers who need video processing and hit Workers limits have three main options.

Option 1: Use a serverless platform that supports native ffmpeg

AWS Lambda, Google Cloud Run, and other serverless platforms run inside containers or microVMs that support spawning native binaries. You can include a static ffmpeg binary in your deployment package and use child_process.spawn() to run it. These platforms have their own limits (Lambda has a 15-minute timeout and 10 GB memory ceiling) but they can handle real video processing.

Option 2: Use a hosted ffmpeg API

Very Good FFmpeg is a hosted ffmpeg REST API purpose-built for video processing jobs. It works as a drop-in replacement for running ffmpeg locally. Instead of fighting Workers limits, you send an API request with your video and get the processed result back.

Very Good FFmpeg provides:

• 16 dedicated 5+ GHz vCPUs per job.
• Nvidia GPU acceleration for encoding and decoding.
• Up to 6 hours of runtime per job.
• No memory ceiling beyond the video itself.
• TypeScript and Python SDKs for easy integration.
• Real-time logs and role-based authentication.
• 99.99% uptime SLA.

Pricing is usage-based at $0.50 per GB of video processed. There are no monthly minimums or upfront commitments.

Option 3: Pre-process videos before upload

For applications where users upload videos, one strategy is to pre-process the video client-side before uploading. The browser can run ffmpeg.wasm locally, or the device can use native encoding. The server then only needs to store and serve the already-processed file.

This approach avoids all server-side video processing but shifts the computational cost to the user's device. It is not suitable for scenarios where the server needs to process videos on demand.

Should you run ffmpeg in Cloudflare Workers in 2026?

No. The short answer is that Cloudflare Workers architecture is fundamentally incompatible with video processing at any reasonable scale.

The V8 isolate model was designed for quick, lightweight request handling. Video transcoding is the opposite: heavyweight, long-running, and resource-intensive. Even if Cloudflare raised individual limits, the architectural constraints of single-threaded isolates and no binary execution would remain.

WebAssembly ffmpeg is an ingenious technical achievement, but it is not a production-ready solution for video processing in Workers. It works for browser-based client-side use cases where the user's machine provides the resources. In Workers, it is a dead end for anything beyond thumbnail generation from very short clips.

The right tool for video processing is dedicated compute where ffmpeg runs natively — either self-managed instances, serverless platforms that support binary execution, or a hosted ffmpeg API that abstracts the infrastructure entirely.

FAQ

Can you run native ffmpeg in Cloudflare Workers?

No. Workers use V8 isolates, not containers. They cannot spawn subprocesses or run arbitrary binaries. This includes native ffmpeg or any other compiled software.

What is the memory limit for WebAssembly in Cloudflare Workers?

128 MB per isolate. This includes your JavaScript code, the WebAssembly module, and all video data loaded in memory. Video files larger than 50-100 MB will typically cause OOM errors.

Is ffmpeg.wasm production-ready on Cloudflare Workers?

No. ffmpeg.wasm works in browsers where it has access to more memory and no hard CPU timeouts. In Workers, it hits limits on memory, CPU time, bundle size, and threading that make it impractical for real video processing.

What is the maximum video file size for Cloudflare Workers?

2 GB is the WebAssembly limit, but the 128 MB Worker memory limit is the real constraint. In practice, files larger than 50 MB risk OOM crashes during processing.

Does WASI on Workers enable ffmpeg?

Not in 2026. WASI on Workers is experimental and lacks the filesystem and socket APIs that ffmpeg requires for real video processing.

Can Durable Objects handle video transcoding?

Partially. Durable Objects extend CPU time to 10 minutes but the 128 MB memory limit and lack of threading remain. They can handle very small jobs like thumbnail generation from short clips, but not real video transcoding.

What is the cheapest alternative to Workers for video processing?

Very Good FFmpeg at $0.50 per GB with no CPU or memory limits, GPU acceleration, and up to 6 hours per job. AWS Lambda with the ffmpeg layer also works but requires more infrastructure setup and has a 15-minute timeout.

How do Cloudflare Workers compare to AWS Lambda for ffmpeg?

AWS Lambda supports native binary execution. You can include a static ffmpeg binary in the Lambda layer and spawn it with child_process. Lambda has a 15-minute timeout, up to 10 GB memory, and up to 6 vCPUs. Workers cannot run native ffmpeg at all, which makes Lambda strictly better for this use case despite its own limitations.

References

• Cloudflare Workers Platform Limits (2026): https://developers.cloudflare.com/workers/platform/limits/
• Workers WebAssembly Runtime: https://developers.cloudflare.com/workers/runtime-apis/webassembly/
• How Cloudflare Workers Works (Isolates): https://developers.cloudflare.com/workers/reference/how-workers-works/
• Cloud Computing without Containers (Cloudflare Blog): https://blog.cloudflare.com/cloud-computing-without-containers/
• ffmpeg.wasm GitHub Repository: https://github.com/ffmpegwasm/ffmpeg.wasm
• ffmpeg.wasm FAQ and Known Limitations: https://ffmpegwasm.netlify.app/docs/faq
• WebAssembly in JavaScript Workers (Official Docs): https://developers.cloudflare.com/workers/runtime-apis/webassembly/javascript/
• WASI on Cloudflare Workers (2022 Announcement): https://blog.cloudflare.com/announcing-wasi-on-workers/
• Very Good FFmpeg — Hosted FFmpeg API: https://www.verygoodffmpeg.com