Expressions, aerender, Templater, nexrender, Plainly and Nubu: what each After Effects automation method really does, where it stops, and how to choose.
Nubu Team··16 minute read
Ask ten people how to automate After Effects and you will get ten different answers: an expression, a script, a plugin, an open source render farm, a SaaS subscription. All ten are right for somebody. The hard part is working out which somebody you are, because most writing on the subject is either Adobe's documentation (accurate, but silent on everything outside the app) or a vendor guide that happens to conclude you should buy the vendor's product.
This is also a vendor's guide, so the bias goes on the table now: we build Nubu, a creative automation platform whose render farm drives real After Effects installs at production scale. The way we would like to earn your trust is by describing every method accurately, including the ones we do not sell, and being precise about where each one stops. If a free expression solves your problem, you should write the expression.
We cover six approaches in increasing order of infrastructure: native tools, scripting, desktop plugins, open source render infrastructure, and hosted platforms (both render services and full campaign pipelines), then finish with a decision framework and a comparison table.
Three different jobs hide under one phrase, and most buying mistakes come from mixing them up.
Automation inside a project. Making layers respond to data and to each other, so one composition adapts instead of being rebuilt. Expressions and Essential Graphics live here.
Automating the rendering. Getting from "the versions exist" to "the files exist" without a person watching a progress bar. The Render Queue, aerender, watch folders, render bots and render farms live here.
Automating the pipeline. Everything before and after the render: data in, versions generated, someone approving the result, files landing where they are used (an ad account, a CMS, a shared drive), failures retried and traceable.
A render bot does not fix a review bottleneck. An approval workflow does not fix a laptop that renders one comp at a time. Keep the three layers in mind through everything below, and if you want the wider discipline this sits inside, we have written a primer on creative advertising automation.
Native After Effects tools: what ships in the box#
Adobe gives you more automation than most people use, and it is worth exhausting the free tier of effort before spending money.
Expressions automate relationships inside a comp: a lower third that resizes to fit its text, every accent colour read from one control layer, timing driven by markers. The modern JavaScript expression engine is genuinely capable, and recent versions can import a JSON file as footage and read it from expressions, which is the closest native After Effects gets to data binding. What expressions cannot do is make more renders exist. They change how one comp behaves, not how many versions leave the building.
Essential Graphics lets a motion designer expose a curated set of controls (text, colours, sliders, image wells) on top of a complex comp and hand it over as a Motion Graphics Template for Premiere Pro. It is best understood as a fence: editors change what they are allowed to change and nothing else. That idea, a curated schema of editable fields on top of a protected project, is the seed of every serious automation system in this guide, including ours. What Essential Graphics is not is batching: a person still fills in the fields and exports, one version at a time.
The Render Queue and Adobe Media Encoder batch outputs within a session. Queue twenty comps with saved render settings and output module templates, press Render, go to lunch. This is real automation of a real chore, and for many motion designers it is all the automation they need. It still starts from versions that already exist in the project.
aerender is the piece most people discover next: a command line renderer that ships inside every After Effects install. Point it at a project and a comp and it renders headless, with no GUI, from any shell, which means it can be called by scripts, scheduled tasks and CI systems. You can run more than one instance in parallel if the machine has the memory. Its honest limitation: aerender renders the project exactly as it sits on disk. It changes nothing, so by itself it automates exporting, not versioning.
Watch folders distribute the work. After Effects' own watch folder mode lets several networked machines share the rendering of a project, and Adobe Media Encoder can watch a folder and encode whatever lands in it with a preset. This is old technology in the best sense: reliable, free, and entirely blind. Nothing tracks which output belongs to which campaign, nothing retries a failure, and the error report is a dialog box on a machine in a cupboard.
Where the native stack stops is easy to state: it renders the compositions it is given. There is no version matrix, no queue that survives a crash, no record of who changed what, and no review step. For one person at modest volume, that can be perfectly fine.
Scripting: ExtendScript and the do-it-yourself route#
Everything the UI can do, a script can do, plus a great deal the UI cannot. After Effects' scripting layer runs ExtendScript, an ES3-era dialect of JavaScript, from .jsx files: scripts can open projects, walk every comp and layer, set text, swap footage sources, apply render settings, add items to the render queue, kick off renders, write logs and shell out to other programs. The classic automation script is a loop: read a row of data, apply the values, queue the render, next row. Studios have run entire broadcast versioning pipelines on nothing more.
Scripting is the right call when three things are true at once: the workflow is stable and repeated, someone technical owns it (a technical artist or a developer who does not mind AE's quirks), and the volume fits the machines you already have. When those hold, a few hundred lines of ExtendScript can replace a plugin subscription outright.
The honest costs: a script is production code you now maintain. Dialog boxes can still block an unattended run, fonts and plugins must match across every machine that renders, output versioning and failure handling exist only if you write them, and the tooling is dated (the ExtendScript Toolkit is deprecated; a VS Code debugger exists; ES3 means none of the modern language niceties without a build step).
One thing worth saying plainly, because scripting sometimes gets dismissed as the amateur option: this same scripting layer sits at the bottom of serious render automation, our own render farm included. What turns a script into infrastructure is everything wrapped around it, the queueing, the retries, the logging, and that wrapper ends up being far more work than the script.
Desktop plugins: Dataclay Templater and the classic render bot#
Between "I could script this" and "I just need versions from a spreadsheet" sits the desktop plugin, and the best known is Dataclay's Templater.
Templater is an After Effects plugin that binds layers in your project to columns in a data source, including Google Sheets, and batch renders one output per row on your own machine. It is the stack School of Motion teaches in "Build an Automated Render-Bot in After Effects" (Joey Korenman's tutorial): Templater for the data binding, Essential Graphics for tidy controls, a Google Sheet as the interface everyone can edit, and an Adobe Media Encoder watch folder to encode what falls out. The tutorial dates from the 2018 era and shows its age, but the architecture still works, and for a solo motion designer producing tens of versions of a known format it remains the fastest route to a working render bot that involves no code at all.
The ceiling is operational, not creative. Every render happens on your machine, under your After Effects licence, while that machine does nothing else for you, and with you as the error handler: when row 34 fails at 2am, the bot waits until you wake up. Scaling means more machines, each one configured, licensed and supervised by you. There is no shared queue, no review step beyond watching the output folder fill, and delivery to wherever the files are needed is manual. None of that is a flaw in Templater; it is what "desktop" means. If your volume and team fit inside one machine and one pair of eyes, this category is honestly hard to beat on cost.
When developers decide to own the problem properly, the reference answer is nexrender: open source After Effects render automation, free to self-host, with 1.8k+ GitHub stars as claimed on its site.
The model is clean. A render job is a JSON document that names the project, the composition and the changes to make (text values, footage swaps) along with render options. You feed jobs in through the CLI, or run nexrender's server and workers so a pool of machines forms a small render farm, each worker driving After Effects on hardware you control. It is an excellent developer tool, and the people who choose it usually know exactly why: full control, no per-render fees when self-hosted, and it slots into whatever stack you already run.
The trade is that you own the entire operational surface: the machines themselves with a licensed After Effects install on each, fonts and plugins kept in parity, uptime, queue depth, retries and error handling, storage, and the delivery step at the end. nexrender is an engine, not a workflow tool, so anything a non-developer touches (a form for submitting jobs, somewhere to review outputs, an approval step) is software your team designs and builds around it. Their hosted cloud, listed from €99 per month plus €0.18 per render minute, rents you the machines while keeping the same JSON job model.
Who it fits: product teams embedding AE-quality video generation inside their own software, and studios with engineering capacity who want infrastructure they control and are happy to run.
Hosted platforms: rendering as a service, and beyond#
The last step is letting someone else run After Effects entirely. Hosted products share a starting point, your own .aep remains the source of truth, and differ in how much of the surrounding pipeline they take on. Two are worth knowing well.
Plainly ("Plainly - Automate video creation", as its homepage puts it) is a focused render service: upload an After Effects template, connect your data, and the videos render in their cloud. Pricing is metered in render minutes by plan, listed from $69 per month for Starter with 50 render minutes, then Explorer at $134, Team at $259, Pro at $649 and Unlimited from $1,500, with custom enterprise plans and a 14-day trial.
If what you need is renders from data with the infrastructure handled, Plainly is a strong, focused way to get exactly that. Where it ends and Nubu begins is mostly a question of how much surrounds your render: we have written up the differences properly in Nubu vs Plainly, and the short version is that the two overlap on cloud rendering and diverge on the campaign workflow around it.
We built Nubu because in advertising work the render is the middle of the job, not the end of it. The versions have to be generated from somewhere, somebody has to approve them, and the files have to land in ad accounts with the right names. So Nubu automates the pipeline, with a real After Effects render farm in the middle of it.
It starts with the project file your motion designer already has. The Nubu Builder plugin (installing Nubu Builder) scans the project, lets the designer mark which properties and footage items are dynamic, and exports the whole thing as a single zip package: the ordinary .aep, a JSON schema describing every dynamic field (a renamed or reordered layer breaks nothing), plus the footage and fonts folders, which travel with the project so the render machines see exactly what the designer saw. Upload the package and every output composition in the schema becomes a renderable format. A one-frame comp renders as a static image and everything else renders as video, so one template covers a campaign's video and static placements together (templates overview).
The template becomes a pipeline. Instead of maintaining a table of versions, you wire a flow: Market, Language and Version nodes fan a template out into a matrix of creatives, text and footage pipe into typed inputs, and an Output node fixes the format and destination (flows overview). Data can be typed in by hand, piped from the asset library, or uploaded as a CSV dataset of up to 5,000 rows and 40 columns, with columns piped straight into the graph (we cover that workflow in CSV to video ads). A build turns the flow into as many as 5,000 creatives in one pass, and rebuilding is safe: pressing Build twice cannot duplicate work, and editing a flow regenerates only what actually changed (building a creative).
Rendering is a farm, not a machine. Approved creatives enter a queue served by a farm of real After Effects machines. However many machines are rendering at once, each creative renders exactly once: duplicate renders cannot happen. Paid work always goes to the front of the queue. A failed render retries automatically; a second failure marks the creative failed with the error kept on the record. Every attempt is stored as its own version, never overwritten, with the full After Effects log attached, so "why does this output look wrong" is a lookup rather than an archaeology project. If a machine dies mid-render, the job goes back to the queue for another machine to pick up.
Nothing renders without review. Builds land in a review state, where each creative is checked and approved before it ever reaches the render queue: review, then approve, then render. Edit a creative after it has rendered and it goes back through the queue to re-render, so the approved state and the rendered file can never quietly drift apart.
Delivery is part of the pipeline. Finished work leaves by two routes. Direct delivery pushes to Meta as paused ads, and to Google Ads as paused Demand Gen ads or Performance Max asset groups, so nothing spends a penny until a human activates it inside the ad platform (platform delivery sits on the Business+ plan). Everything else leaves as a ZIP export with a manifest CSV listing every file, assembled for you so a thousand-creative download is one link, not an afternoon.
Pricing is per seat, from £29 per month plus £12 per seat, with a free tier for trying the pipeline (free renders queue behind paid work, exactly as described above).
And the honest limits, because every tool here got the same treatment: Nubu has no public API, so if your goal is to embed rendering inside your own software, nexrender is the better shaped tool. Direct delivery covers Meta and Google; for anywhere else, the ZIP export is your route. If your workload looks like campaigns rather than one-off renders, the free tier is the cheap way to test our claims: upload a template and build a small matrix.
A solo motion designer versioning their own templates should start native: expressions plus Essential Graphics, then Templater when the spreadsheet arrives. Your bottleneck is your machine's render time, and that is a cheaper problem than any subscription right up until it is not.
A studio with a technical artist should weigh Templater against scripting. Templater wins on time to first render; a script wins once the workflow outgrows what a plugin exposes. When client volume outgrows what desks can render overnight, that is the moment to look at nexrender if you have engineers to own it, or a hosted service if you do not.
A product or engineering team embedding video generation into software wants nexrender (self-hosted for control, or their cloud to skip the machines). You will be building your own review and delivery regardless, because they have to live inside your product.
A performance marketing team rarely has a rendering problem alone. The problem is the matrix (markets by languages by placements), the approvals, and getting files into ad accounts intact. That is a pipeline shape, and it is what Nubu is built for; a render service plus glue code can reach the same place if you have engineers to write the glue and keep it standing.
Five questions settle most cases:
Volume and cadence. Ten renders a week is a desktop problem. A thousand on campaign day is infrastructure.
Who runs the machines. Every method up to hosted means After Effects installs you maintain: fonts, plugins, updates, licences, and someone on call when a render hangs.
Where the data lives. A spreadsheet, a feed, a CSV out of another system: choose a method that reads it without a human re-typing it.
Who has to approve. If a client, a brand team or legal signs off every version, review is part of the pipeline, not an email thread bolted on afterwards.
Where the files must land. An output folder is not delivery. Count the hops between "rendered" and "live", and ask which method removes them.
After Effects automation in 2026 is a spectrum, not a product category. Native tools automate the comp. Scripting and render bots automate the machine you own. nexrender turns rendering into infrastructure you run. Hosted platforms make the machines someone else's problem, with Plainly focused on the render and Nubu on the campaign around it. The method that fits is the one that matches the layer your bottleneck actually lives at, and being honest about that layer will save you more money than any pricing page.
Whichever you choose, the craft stays where it belongs: the whole point of every method here is that the motion design lives in the .aep while the repetition leaves it. If the campaign layer is your bottleneck, see what the pipeline covers on the features page and the pricing page, or start on the free tier: you can have your own template rendering through the pipeline in an afternoon.
