# Add video processing to n8n Cloud Canonical: https://rendobar.com/blog/n8n-video-processing-node/ Author: Abdelrahman Essawy Published: 2026-09-09 Updated: 2026-09-15 --- ## Key takeaways - n8n Cloud can run FFmpeg now. One search in the nodes panel installs the Rendobar node, on a platform that ships no FFmpeg binary and has kept the Execute Command node off by default since n8n 2.0. - A 344 KB clip compressed to 191 KB, under a 200 KB cap, in 19.6 seconds from submission to completion. The run went through the node against production and cost $0.0136. - A cap above the source size is not free. The same clip under a 1 MB cap came back byte for byte identical, after a 20 second compress step and a $0.0238 bill. - Three ready-made workflows target real gaps: the template library has 5 results for compress video and none of them compress video, and the most viewed of its 18 ffmpeg templates runs only self-hosted. - A long job parks on a Wait node with no worker held. The Create node takes the Wait node's resume URL as its callback, and two settings make that safe: POST, and a 10 hour limit. 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. _Typed into a fresh instance with nothing installed. The badge is n8n's, not ours._ _The details panel behind that result. Install node puts the Rendobar node and its trigger on the whole instance._ 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. _Eight nodes, three of them Rendobar. The sticky notes are the setup guide, so the workflow explains itself after import._ 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. _The fields under Values to Send come from the job type's own schema. A job type that ships next month appears here without a node release._ ## 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 suits a clip. Callback plus Wait suits an hour. The trigger suits a workflow that is the reaction._ **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](/blog/n8n-ai-agent-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. _Two of the ten trigger events are about the balance, not a job. Account Get is what answers how low._ ## 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.