Remotion Lambda or a Sume Timeline job: who runs the servers?

With Remotion Lambda you operate the render infrastructure inside your own AWS account; with a Sume Timeline 1.0 render you submit a job and Sume's workers run ffmpeg. Remotion Lambda gives you more control over what a frame can contain. Sume gives you less to operate, and far less that it can express.

Remotion's Lambda page was read on 2026-10-10; the Sume numbers come from Timeline 1.0, Errors and rate limits and Authentication.

What you set up for Remotion Lambda

Remotion describes the flow as deploying your project to S3, invoking a Lambda function that opens it, spawning parallel Lambda instances to render chunks of the video, then stitching the chunks and uploading the result to S3. The page lists a Lambda function (with a Chromium layer hosted by Remotion), an S3 bucket, CLI tools and optional Node.js APIs, plus a minimal set of AWS permissions for your user.

• Videos under 80 minutes at Full HD are the stated target.
• AWS Lambda's concurrency limit of 1000 per region applies, and it can be raised.
• The page gives 10 GB of storage per Lambda, roughly 5 GB of output, about two hours of Full HD.
• AV1 encoding is not available, and companies need Cloud Rendering Units licensing.
• Remotion says most users render multiple minutes of video for a few pennies, with the exact cost depending on region, memory and video parameters.

What you send to Sume instead

A Timeline render is a single POST /v1/timeline-1.0/render with a JSON document and an Idempotency-Key. The default mode is async, so you get a job back and poll GET /v1/jobs/:id/status; passing mode: "sync" waits up to 30 seconds for a finished job. The job uses worker ffmpeg only, with no provider inference, and the public rate is $0.10 per ceil output minute.

Limits are different in kind. Output length runs from 1 to 1800 seconds, a document holds up to 200 slots, and the default render.strategy of auto chunks past 12 segments. Sume refuses single above 12 slots with render_strategy_unsafe.

Failure handling is different too

On Lambda, a failed render is something you read from your own logs and CloudWatch. On Sume, a bad document fails at admission with stable codes such as timeline_must_start_at_zero, segment_overlap or transition_too_long, and a 429 carries retry-after. The docs also warn not to retry unsafe submits without an Idempotency-Key, which is exactly the protection a pay-per-job API needs.

Decision rule

If your team already runs AWS and needs a frame the Timeline cannot draw, Remotion Lambda is the better fit, and you should price your own compute. If the job is stitching clips under a voice-over and nobody wants to own a render farm, a Sume job is shorter to build. Run the free plan call on a real document first; it returns billable_minutes before anything is charged.