Add video processing to n8n Cloud

The most repeated video question on the n8n forum is whether FFmpeg works on n8n Cloud. It was asked in August 2025 and again in April 2026, and the answer both times was no: Cloud ships no FFmpeg binary and allows no shell. Since n8n 2.0 the Execute Command node is off by default on self-hosted instances too, so the workaround of running ffmpeg in a shell step went with it.

Short version#

The Rendobar node is verified by n8n and live on n8n Cloud. Press + on the canvas, search for Rendobar, and install it from More from the community. A Create Job step then runs any of the live job types on Rendobar’s workers, including raw FFmpeg commands, and hands the output back. Three ready-made workflows cover compression, captions and arbitrary FFmpeg, all built for Cloud. In a measured run through the node, a 344 KB clip came back at 191 KB in 19.6 seconds for $0.0136. The rest of this post is how the pieces fit, and where they stop.

Installing from the canvas#

A verified community node is one n8n has reviewed and publishes itself. The practical difference from an unverified one is where it shows up. Type the name into the nodes panel and it appears under More from the community with a badge and an Install button, on Cloud and on self-hosted 1.94.0 or later.

The install takes one click and applies to the whole instance. If the section does not appear on Cloud, an instance owner turns on Verified Community Nodes in the Cloud Admin Panel, and a restart may be needed the first time. The older route, Settings, Community nodes, still works on self-hosted instances with the package name @rendobar/n8n-nodes-rendobar.

Two nodes arrive. Rendobar runs operations against the API, and Rendobar Trigger starts a workflow on ten events: five about a job, three about a storage delivery and two about the account balance.

What a workflow looks like#

The compression workflow is the shape all three share. A Google Drive trigger fires on a new file, Drive downloads it, and Rendobar’s Upload turns the binary into a URL. Create Job submits compress.target with a 25 MB cap. A Wait node parks the execution. Get Job downloads the result, and Drive and Telegram both receive it.

The other two follow the same skeleton. The captions workflow runs caption.burn with the language on auto and posts the Drive link to Slack. The FFmpeg workflow starts from a form that takes a video URL and a command, and a second branch listens for any failed job, reads the runner log with Get Logs, and posts the FFmpeg error text to Slack. That second branch is the one people miss. A filter graph that refuses to build tells you exactly why in stderr, and Get Logs is how the text reaches a channel instead of dying in a status field.

Waiting without a worker#

Media jobs are slow relative to a workflow step. The node offers three ways to get a result, and the templates use the second.

Wait for Completion polls until the job ends. It is what the measured run below used, because a five second clip is done before a poll loop gets expensive. Callback URL plus a Wait node is the template default. Create carries the Wait node’s resume URL, the execution parks with no worker held, and Rendobar’s callback resumes it. Two settings make it safe. The Wait node resumes on a POST, because Rendobar POSTs and the node defaults to GET, and Limit Wait Time is on at ten hours so an execution whose callback never lands releases itself. The trigger node is the third option, for when the workflow is the reaction rather than the thing that waits.

The callback path was exercised for real, not only described. Each template’s Rendobar chain ran through a local n8n reachable over a tunnel, with the Drive, Telegram and Slack steps swapped for stand-ins. All three executions parked on the Wait node, Rendobar’s job.completed callback resumed each one, and Get downloaded the file: jobs job_b5122d6b635a4c1a, job_1a7c1365a9b94119 and job_8db34493a2144cce. The failure branch fired too. A job with a missing input woke the trigger and Get Logs returned the download error the runner reported.

What the run measured#

The compression job ran through the node against production on 8 September 2026 (UTC), on the 344 KB, 1280 by 720, five second sample clip Rendobar publishes for tests. Two runs, because the first one taught something.

The first run set the cap at 1 MB. The output came back at 352,121 bytes, which is the source byte for byte. The compress step still ran for 20.3 seconds and the job cost $0.0238. A cap the source already meets is not a no-op, so put the cap where you need it.

The second run set the cap at 200 KB, which is 204,800 bytes. The output was 195,532 bytes, 44.5 percent smaller than the source and 9,268 bytes under the cap, at the same 1280 by 720. From submission to completion took 19.6 seconds: 7.0 seconds waiting for a worker, 0.1 downloading the input, 8.9 compressing and 3.5 uploading the output. The node’s own step, polling every five seconds, finished in 23.3 seconds. The job cost $0.0136, and client on the job record read n8n, which is how the dashboard’s usage view knows where it came from.

Sizes are deterministic, so the byte counts above will reproduce. Timings and cost track the clock and will not, so treat them as one sample.

The node as an agent tool#

The node is marked usable as a tool, so it attaches to an AI Agent’s tool port and n8n builds the tool schema from the node’s parameters. The design decisions for an agent that spends money are in Give an n8n AI Agent real video tools. The short form: give the agent Account Get next to Job Create, so it reads its balance before it runs an encode, and give it Get Logs so a failed job comes back as FFmpeg’s actual error instead of the word failed.

Where this stops#

The trigger fires on every event of a subscribed type across the account, not filtered by job type or workflow. Two pipelines sharing one account will wake each other’s workflows.

The ready-made workflows need Google Drive, Slack or Telegram credentials of your own, and the Drive trigger polls once a minute, so a new file waits up to sixty seconds before anything happens.

Updates to a verified node ship on n8n’s release cadence, roughly every two weeks, after n8n reviews the new version. A fix published to npm today reaches Cloud instances when that review lands, not the same afternoon.

The measured run is one clip and one cap. A long source, a high cap, or a different codec will move every timing above and the cost with them. The byte counts are the part to trust.

On a self-hosted instance the Wait node’s resume URL must be reachable from the internet, so a laptop needs a tunnel. n8n Cloud has no such step.