Vercel FFmpeg Video Processing: Serverless Function Limits in 2026

Why do developers try to run ffmpeg on Vercel?

Next.js and Vercel are a popular stack. When you need to process video, ffmpeg is the first tool that comes to mind. It is natural to think: "Just install ffmpeg in my API route and done."

But Vercel serverless functions were not designed for video processing. They were built for quick I/O tasks like reading a database, calling an API, or rendering a JSON response. Video transcoding is CPU-heavy, memory-intensive, and slow. The architecture fights you at every turn: cold starts, an ephemeral filesystem, a hard bundle size cap, and a tiny request/response payload limit.

This article covers every Vercel serverless function limit that kills ffmpeg, why the official Vercel Labs demo is not production-ready, and the only practical workaround: offloading video processing to a dedicated hosted ffmpeg API like Very Good FFmpeg.

Key Takeaways

• Vercel serverless functions have five hard limits that make ffmpeg impractical: 250 MB bundle size, 4.5 MB payload, 800s maximum duration, 4 GB memory ceiling, and 500 MB scratch space.
• The static ffmpeg binary alone is 70-100 MB, eating nearly half your bundle budget.
• Vercel's official stance is that ffmpeg in serverless functions is "not recommended."
• The vercel-labs/ffmpeg-on-vercel demo proves it works for simple tasks but is not production-ready for real video workloads.
• Vercel Workflows address the duration limit but still lack ffmpeg and GPU support.
• The real solution is offloading video processing to a hosted ffmpeg API like verygoodffmpeg.com. Vercel handles the app layer; the ffmpeg API handles the video.

What are the exact Vercel serverless function limits in 2026?

Vercel publishes official limits for serverless functions. These are hard caps. You cannot bypass them with configuration changes or higher plan tiers on Hobby. Pro and Enterprise plans raise some limits but do not remove them.

Source: Vercel Functions Limitations and Vercel Functions Memory Config.

Every one of these limits creates a problem for ffmpeg. The static binary alone is 70-100 MB. A 10-minute video transcode takes 8-12 minutes of CPU time on a 1 vCPU machine. A 100 MB video file is 20x larger than the 4.5 MB payload limit. And without GPU, encoding is 5-10x slower than GPU-accelerated alternatives.

Can ffmpeg actually run on Vercel at all?

Yes, technically. The vercel-labs/ffmpeg-on-vercel demo repo proves it is possible. It uses the ffmpeg-static npm package and requires explicit configuration in next.config.ts with outputFileTracingIncludes to bundle the binary.

But there are major caveats:

1. It requires Pro or Enterprise. The demo recommends 3009 MB memory (4 GB / 2 vCPU). Hobby is locked to 2 GB / 1 vCPU and cannot change this.
2. It works for simple operations. A thumbnail extraction, a 5-second clip, a format swap between two small files. These fit within the limits.
3. It falls apart for real workloads. Transcoding a 10-minute 1080p video to H.264 takes 8-12 minutes on 1 vCPU. That exceeds both the Hobby 300s and Pro 800s duration limits. Memory usage during transcoding can reach 500 MB to 1.5 GB, which is fine for 2 GB functions but tight for complex filter chains.

As one developer put it on Reddit: "Transforming medias with ffmpeg on Vercel serverless functions is not a great idea. First, you have a timeout of 10 or 15 seconds. Then, you will exceed the 50 MB size limit because of the ffmpeg binary and the media being transformed."

The demo proves technical possibility. It does not prove production readiness.

What does Vercel say about ffmpeg on serverless functions?

Vercel's official position is clear. In a GitHub discussion, a Vercel employee (wiiiimm) wrote: "We generally do not recommend running this kind of server workload as serverless functions and installing ffmpeg will very likely push the serverless function over the 50 MB limit."

This response appears repeatedly across Vercel's support channels. On the Vercel community forum, developers report that ffmpeg works in development but fails in production. The same official response is given: not recommended.

The Vercel troubleshooting guide for the 250 MB function limit explicitly suggests: "If certain functionality of your app is causing the bundle to bloat, consider turning that portion into an external service." This is the most direct recommendation to offload video processing.

Why is the 250 MB bundle size limit a dealbreaker for ffmpeg?

The 250 MB uncompressed limit (approximately 50 MB gzipped) is the single biggest obstacle. Here is why:

1. The ffmpeg static binary is 70-100 MB. That leaves 150 MB for your application code, all node_modules, and any other dependencies.
2. If you also need Chromium (for example, with Remotion for programmatic video rendering), that adds another 100-150 MB. Combined with ffmpeg, you exceed the limit before your application code is even included.
3. Tree-shaking and includeFiles/excludeFiles help at the margins but cannot solve the fundamental problem: ffmpeg itself is the bloat.

A common workaround is downloading the ffmpeg binary at runtime from a URL instead of bundling it. This works in theory but introduces cold-start latency (downloading 70-100 MB before the function can start processing) and still leaves you with all the other limits.

Why does the 4.5 MB payload limit matter for video?

Video files are measured in megabytes and gigabytes. The 4.5 MB request/response body limit means you cannot:

• Upload a video file directly to a serverless function as a request body.
• Return a processed video file as a response body from a function.

The workaround is to upload files to object storage (Vercel Blob or S3) first, then pass the URL to the function. This solves the payload problem but does not solve the bundle size, duration, memory, or GPU problems. You still need to download the file from storage to the function, process it within the function's limits, then upload the result back.

This pattern is described in Vercel's documentation for the FUNCTION_PAYLOAD_TOO_LARGE error. It is the recommended approach, but it only fixes one of five broken constraints.

Are Vercel Workflows a solution for video processing?

Vercel Workflows are Vercel's answer to long-running tasks. They support pause/resume from minutes to months, survive deployments and crashes, and have higher limits:

• Max payload: 50 MB
• Entity storage: 2 GB per run
• Concurrency: up to 100,000

Workflows address the duration limit. A video transcode that takes 30 minutes can run inside a Workflow step. But Workflows do not solve the other problems:

1. No ffmpeg binary included. You still need to bundle or download the 70-100 MB binary, which hits the same 250 MB bundle limit.
2. No GPU. Workflows run on the same CPU-only infrastructure as serverless functions.
3. Built for orchestration, not transcoding. Workflows are designed to coordinate multi-step processes, not to be a video processing engine.

Workflows can coordinate external video processing. They cannot replace it.

How much does it cost to run ffmpeg on Vercel?

Vercel's Fluid Compute pricing charges for active CPU time and provisioned memory. Video processing is CPU-intensive, so costs add up quickly.

Source: Vercel Fluid Compute Pricing.

A 10-minute video transcode taking 8-12 minutes of CPU time costs significantly more than a typical I/O-bound function invocation. Without GPU, you pay for 5-10x more CPU time than GPU-accelerated alternatives. At scale, a hosted ffmpeg API with GPU support is cheaper per video, faster, and simpler.

What are the memory and CPU requirements for ffmpeg transcoding?

FFmpeg's resource usage varies by codec, resolution, and filter complexity. Here is a rough guide:

Vercel's Hobby tier (2 GB memory, 1 vCPU, 300s timeout) cannot handle anything beyond simple operations. The Pro tier (4 GB memory, 2 vCPU, 800s timeout) extends the range but still fails for longer videos or complex workflows.

No tier provides GPU access. CPU-only H.265 encoding at 5-10 fps on a single vCPU makes a 10-minute video take 15-25 minutes -- well past the Pro 800s timeout.

What does the community say about ffmpeg on Vercel?

The developer community has tried and struggled with ffmpeg on Vercel for years. The consensus is consistent.

A Reddit thread on r/nextjs titled "Anyone been able to make ffmpeg work on Vercel?" produced this top response: "Transforming medias with ffmpeg on Vercel serverless functions is not a great idea."

On Stack Overflow, a developer built a video converter using Next.js API routes and ffmpeg. They hit the 4.5 MB body limit and could not return the processed video. The solution was to use object storage, but the function still timed out on any non-trivial video.

The FFHub article on serverless ffmpeg provides a comprehensive comparison across Lambda, Vercel, and Cloudflare. Key findings: the static binary is 70-100 MB, 1080p transcode takes 8-12 minutes, and there is no GPU on any serverless platform.

The Zencopa guide is blunt: "It is not feasible to render videos or even still frames directly inside a Vercel Serverless Function."

Multiple community threads show the same pattern: ffmpeg works in development, fails in production, and Vercel support responds with the same "not recommended" guidance.

What is the actual workaround?

Offload video processing to a hosted ffmpeg API. This is the pattern Vercel's own documentation suggests when it recommends turning heavy functionality into an external service.

Here is how the architecture works:

1. Vercel handles the app layer. Authentication, API routing, frontend, file upload, webhook handling, and client delivery.
2. The hosted ffmpeg API handles video processing. Transcoding, compression, filters, watermarking, format conversion, snapshot extraction, and any other ffmpeg operation.

The integration pattern looks like this:

1. User uploads a video to your app on Vercel.
2. Your Vercel API route receives the request and calls the hosted ffmpeg API with the file URL and processing parameters.
3. The ffmpeg API processes the video on dedicated hardware with GPU support and no timeout limits.
4. A webhook delivers the processed file URL back to your Vercel function.
5. Your app serves the result to the user.

This keeps Vercel doing what it does best (frontend, routing, and API orchestration) while giving the video work to infrastructure built for it.

Why Very Good FFmpeg?

Very Good FFmpeg is a hosted ffmpeg API built specifically for developers who hit the limits of serverless video processing. It solves every problem listed above.

Key features:

• Same ffmpeg syntax. Your existing ffmpeg commands work. Same flags, same filter graphs, same codec options. No new DSL to learn.
• Usage-based pricing. Pay per GB processed. Volume discounts kick in automatically. No monthly minimums.
• GPU acceleration. Set machine: "nvidia" on any request to route to Nvidia GPU workers. GPU encoding is 5-10x faster than CPU.
• 6-hour timeout. Encode a feature film in one job. No chunking around a 15-minute Lambda clock.
• 100 requests per second rate limit. Fan out batch processing in one go.
• Realtime logs. Watch ffmpeg stderr stream live in the dashboard while the job runs.
• TypeScript and Python SDKs. Official clients so you are not writing raw curl commands.
• Auto-diagnosis. When a command fails, AI analyzes the ffmpeg output and tells you what went wrong.

The API is straightforward. Send a POST with your input file URL and ffmpeg command. Get a webhook with the result.

What about other alternatives?

Before settling on a hosted ffmpeg API, consider these common alternatives and why each falls short for production video processing.

ffmpeg.wasm runs ffmpeg in the browser via WebAssembly. It is limited by browser memory, has no access to the server filesystem, and is slower than native ffmpeg. Good for client-side previews. Not reliable for server-side processing.

AWS Lambda has similar limits to Vercel: 250 MB bundle size (including layers), 15-minute timeout, and no GPU. Lambda gives you more memory (up to 10 GB) and more time, but you are still fighting the same class of limitations. The FFHub article shows Lambda costs roughly $0.022 per video versus $0.008 with GPU-backed EC2.

Vercel Edge Functions have even tighter limits: 1-15 second timeout, no writable /tmp, and minimal memory. Edge Functions are designed for fast, lightweight responses -- the opposite of video processing.

Self-hosted ffmpeg on a VPS or dedicated server gives you full control but requires infrastructure management, scaling, monitoring, and maintenance. You are running your own video processing pipeline.

Specialized video APIs like Mux, Cloudflare Stream, and AWS Elemental MediaConvert work for specific use cases but lock you into their workflow. They do not let you write arbitrary ffmpeg commands.

Very Good FFmpeg fills the gap: arbitrary ffmpeg commands on managed infrastructure with GPU, long timeouts, and no bundle size limits.

Verdict

Running ffmpeg on Vercel serverless functions is a dead end for anything beyond toy examples. The five hard limits -- bundle size, payload, duration, memory, and no GPU -- make production video processing impractical.

The evidence is consistent: Vercel's own documentation recommends against it. The community has tried and failed. Technical analysis confirms the math does not work for real video workloads.

The fix is not to fight Vercel's limits. It is to use the right tool for each job. Vercel excels at the app layer: frontend, routing, authentication, and API orchestration. Let it do that. Offload video processing to a hosted ffmpeg API built for the task.

Very Good FFmpeg is the cleanest fit for this exact use case. Same ffmpeg syntax, GPU acceleration, 6-hour timeouts, usage-based pricing, and no bundle size limits. Your Vercel app stays lean, and your video processing actually works.

FAQ

Can I use ffmpeg.wasm instead of a server-side solution?

ffmpeg.wasm runs ffmpeg compiled to WebAssembly in the browser. It is limited by browser memory (typically 1-4 GB), has no access to the server filesystem, and is slower than native ffmpeg. It works for client-side previews or small files but is not reliable for production video processing at scale.

What about Vercel Edge Functions for video processing?

Edge Functions have even tighter limits than serverless functions: 1-15 second timeout, no writable /tmp directory, and minimal memory. They are designed for fast, lightweight operations like header manipulation and geo-routing. They are a worse fit for ffmpeg than serverless functions.

Do Vercel Workflows come with ffmpeg pre-installed?

No. Workflows are containers you control, but you still need to package ffmpeg yourself. The 250 MB bundle size limit still applies. Workflows solve the duration problem but not the bundle size, memory, or GPU problems.

Can I use AWS Lambda instead of a hosted ffmpeg API?

Lambda has similar limitations: 250 MB bundle (including Lambda layers), 15-minute timeout, and no GPU. You get more memory (up to 10 GB) and more time than Vercel, but you still face the same class of constraints. The FFHub article compares costs: Lambda is roughly $0.022 per video for transcoding versus $0.008 per video with GPU-backed EC2 instances.

How do I handle large video uploads without hitting the payload limit?

Upload files directly to object storage like Vercel Blob or S3 using presigned URLs. Pass the storage URL to your video processing service. The processed result can be stored in the same bucket, and a webhook notifies your Vercel function when it is ready. This is the pattern recommended by Vercel's own documentation.

Is the vercel-labs/ffmpeg-on-vercel demo production-ready?

No. The demo proves technical feasibility for simple operations on Pro/Enterprise plans. It is not a production deployment pattern. It requires explicit binary tracing configuration, 4 GB / 2 vCPU, and still hits duration and payload limits for any real video workload.

References

• Vercel Functions Limitations
• Vercel Functions Memory Config
• Vercel Functions Duration Config
• Vercel Fluid Compute Pricing
• Vercel General Limits
• Function 250 MB Limit Troubleshooting
• FUNCTION_PAYLOAD_TOO_LARGE Error
• Vercel Runtimes
• GitHub Discussion -- Vercel Staff "Not Recommended"
• GitHub Discussion -- Build Step ffmpeg Fail
• vercel-labs/ffmpeg-on-vercel Demo
• Reddit -- Anyone made ffmpeg work on Vercel?
• FFHub -- FFmpeg on Serverless: Challenges and Solutions
• Zencopa -- Render Videos with Vercel Functions
• Vercel Community -- Including ffmpeg Binary in Production
• Vercel Workflows
• Stack Overflow -- 4.5 MB Body Size Limit
• dev.to -- ffmpeg in Python Serverless