run.cloud does not create or host an S3 bucket. Create the final and temporary
objects in your own S3-compatible storage and provide presigned PUT and GET
URLs for them.
Before you start
You need:- Node.js 20 or newer and
@run-cloud/sdk - a run.cloud API key in
RUN_CLOUD_API_KEY - a deployed Remotion bundle URL
- an exact Remotion version, an organization-owned runtime snapshot, or a compatible custom image
- a presigned PUT URL and a downloadable URL for the final output object
Render in one sandbox
cloud.remotion.render() waits for the render, returns its result, and destroys
the sandbox when it finishes or fails.
remotion package in your project on the same version. The SDK uses
remotionVersion to select the matching public runtime image and install that
exact renderer during sandbox startup. Use image instead when you maintain a
compatible image that already includes Remotion, Chrome, and FFmpeg.
Cache dependencies in a runtime snapshot
The zero-setup path installs the exact renderer when a sandbox starts. For repeated renders, install it once into a snapshot owned by your run.cloud organization:snapshotId instead
of remotionVersion:
cloud.snapshots.delete(snapshotId).
Move from Remotion Lambda
For code that already uses@remotion/lambda/client, switch the import to the
compatibility adapter and add s3Output. Existing region and functionName
fields may remain while the compute moves to run.cloud.
runCloud.remotionVersion,
runCloud.snapshotId, or runCloud.image explicitly.
Add distributed concurrency
Without distributed rendering, one render request creates one sandbox.concurrencyPerLambda controls the Remotion renderer concurrency inside that
sandbox; it does not create more sandboxes.
To split one video across multiple sandboxes, set concurrency and provide a
temporary customer-owned object for each video and audio chunk:
presignTemporaryObject() is your storage helper. It must return
{ uploadUrl, downloadUrl, headers?, contentType? }, with the PUT and GET URLs
pointing to the same object. Add downloadHeaders when the signed GET requires
headers.
concurrency is the target maximum sandbox count. You can use
framesPerLambda instead and let the SDK calculate the count from the selected
composition. Chunks must be equal-sized except for the last chunk, so a short
composition can use fewer sandboxes than requested. Read render.sandboxCount
or progress.runCloud.sandboxCount for the exact number allocated.
Each allocated sandbox renders one frame range. Temporary chunks and the final
artifact stay in storage you provide, and sandboxCount is the total compute
allocated for the render.
Progress and cleanup
The Lambda-compatible methods keep the render detached so you can poll it from another process. Destroy every render after completion, failure, or cancellation:cloud.remotion.start(),
cloud.remotion.getProgress(), and cloud.remotion.cancel() for the same
detached lifecycle. Finite sandbox timeouts are a cleanup backstop, not a
replacement for cancelling completed or abandoned renders.
Configure an S3 lifecycle rule for the temporary chunk prefix. Use short-lived
signed URLs that remain valid for the expected render duration; signed URLs are
written to private files inside the sandbox and are not included in command
logs.
See Remotion’s distributed rendering guide
for the underlying chunking model.