Point a job at an object and a folder, and the output lands back in the bucket. Nothing downloads to your servers, and the connection is an IAM role rather than a stored key.
import { createClient } from "@rendobar/sdk";
const rb = createClient({ apiKey: process.env.RENDOBAR_API_KEY });
// Read the object from the connected bucket, deliver the result back into it.const job = await rb.jobs.create({ type: "ffmpeg", inputs: { source: "storage://media/raw/interview.mov" }, params: { command: "ffmpeg -i source -c:v libx264 -crf 20 -c:a aac -movflags +faststart out.mp4", }, destinations: ["storage://media/exports"],});The usual pipeline copies the object into a Lambda function, runs FFmpeg, and uploads the result. Every step spends the same 900-second budget, and /tmp tops out at 10,240 MB, which has to hold the input and the output at once.
It works for short clips. The upload that fails is the longest one, and a timeout at minute fifteen throws away the download and the encode along with it.
// handler.ts, AWS Lambda with an FFmpeg layerimport { GetObjectCommand, PutObjectCommand, S3Client } from "@aws-sdk/client-s3";import { spawnSync } from "node:child_process";import { createWriteStream, readFileSync } from "node:fs";import { pipeline } from "node:stream/promises";
const s3 = new S3Client({});
export const handler = async ({ bucket, key }) => { // 1. Copy the whole object into /tmp: 512 MB by default, 10,240 MB at most. const obj = await s3.send(new GetObjectCommand({ Bucket: bucket, Key: key })); await pipeline(obj.Body, createWriteStream("/tmp/in.mov"));
// 2. Encode, racing the 900-second function timeout. spawnSync("/opt/bin/ffmpeg", ["-i", "/tmp/in.mov", "-c:v", "libx264", "/tmp/out.mp4"]);
// 3. Read the whole output back into memory and upload it. // A timeout at any step throws away all three. await s3.send(new PutObjectCommand({ Bucket: bucket, Key: "exports/out.mp4", Body: readFileSync("/tmp/out.mp4"), }));};Pick Amazon S3 in the dashboard and a CloudFormation stack opens, filled in for one bucket. It creates a role Rendobar can assume and reports back when it is ready. No access key is created or stored, and deleting the stack revokes access.
Name the object as an input and a folder as a destination. Both references are checked against your account when you submit, so a typo or a bucket you don't own fails immediately instead of after a wait.
The job gets a signed link to that object and nothing else in the bucket, and runs your exact FFmpeg command for up to 1 hour on Free or 9 hours on Pro.
It lands under the connection's file name pattern, and job.delivery_succeeded fires for the bucket. A failed delivery retries on its own and can be retried again without re-running the encode.
Every number here came from a job we ran and recorded. Each one links to the write-up with the command, the data and its limits.
| Approach | Handles a long video? | Why |
|---|---|---|
| Lambda with an FFmpeg layer | No | Stops at 900 seconds and copies the object into /tmp first |
| ECS, Fargate or EC2 you run | Yes | No time limit, and you build, patch and scale the container |
| AWS Elemental MediaConvert | Yes | Writes to S3 through a role, with its own job spec instead of FFmpeg commands |
| Rendobar with a storage connection | Yes | One request, the FFmpeg command as written, output delivered back |
FFmpeg has no s3 protocol, but it reads HTTPS, so a presigned GET URL works as an input. With a storage connection you pass storage:// followed by the connection ID and the object key, and Rendobar gives the job a signed link to that one object.
A regular MP4 can't be streamed into S3, because FFmpeg seeks back to write its index. Write a file and upload it, pipe a fragmented MP4 into aws s3 cp, or add destinations to the job and let it deliver the finished file.
No. The one-click path creates an IAM role through a CloudFormation stack, and Rendobar receives temporary credentials when it needs them. Access keys remain an option if your team prefers them.
Read and write objects in the one bucket, abort its own unfinished multipart uploads, list that bucket, and read bucket names and regions so the dashboard can offer a picker. It can't delete objects, and a read only connection gets no write permission at all.
Up to 1 hour per job on Free and 9 hours on Pro. The plan sets the limit, not a function timeout.
Jobs are billed by compute time. Every account begins with $5 in free credits and no credit card, so you can run a real job against your own bucket before paying anything.
A storage connection works the same way on every provider, and the job submits from any runtime that can make an HTTPS request.
$5 free on signup. No credit card. No access key.