RenderWrangler

What this is

A render farm that belongs to you, built inside your own AWS account.

Not capacity we rent you by the hour. Infrastructure we build, hand over, and teach your team to run.

A GPU fleet on AWS that starts when work arrives and shuts down when the queue drains.

Artists submit from inside their own application — through a plugin we set up and walk them through.

Machine images with your plugins and versions baked in — what AWS calls a customer-managed fleet (CMF) — so every worker renders identically. We’ll talk through when AWS’s service-managed fleets (SMF) suit you better.

Your own render licences, or per-hour licensing from AWS — chosen per queue.

On-demand or spot machines — on-demand for deadline work; cheaper spot capacity for renders that can wait, since AWS can take a spot machine back mid-frame.

Render progress posted to your Slack or email — how far along it is, how many machines are on it, when it’ll finish, and in Slack, the latest frames — so you spot a wrong scene while it’s still cheap to stop.

A cost dashboard — what rendering actually cost, by type of machine (and per job, on Production), matched to your AWS bill the next day.

Everything needed to rebuild it, handed to you — so you’re never locked in to us.

Your artists’ workstations left alone. Rendering happens somewhere else.

Linux or Windows workers, or both — Linux by default, as it has been cheaper per hour in our experience; Windows where your pipeline needs it.

From a live production project

A 3,700-frame scene. Nearly five days of continuous rendering, compressed into an evening.

A Cinema 4D and Redshift animation carrying about 115 hours of render work. On one machine that is nearly five days of solid rendering, assuming nothing crashes and nobody needs the computer. On a 25-worker fleet it finished in 6 hours 15 minutes, from submit to final frame.

Faster renders are what you'd expect from a farm. The bigger win was something else.

Then the scene turned out to be wrong

Two textures didn't reach the workers, and the frames came back without them. It is the oldest failure in cross-platform rendering, and every studio has shipped it at least once.

The farm didn't prevent that; moving to a farm brings traps of its own, and this was one. But any scene can turn out wrong — a texture, a light, a client's late note. What changes is how long the mistake stays expensive.

A scene that turns out wrong	On one workstation	On the farm
When you find out	When the render finishes	About two hours in
How you find out	Someone opens the folder in the morning	Finished frames arrive in your Slack as they land
What the mistake cost	Five days of machine time	About two hours, stopped halfway
Putting it right	Start again, another five days	Corrected scene resubmitted the same afternoon
Every frame delivered	The following week	Six hours later

The farm isn't free. It's cheaper than a week without your best machine, an artist with nothing to work on, and a render nobody can watch for five days.

And once a scene can be re-rendered in an afternoon, a studio works differently. It fixes the texture, tries the other lighting version, and still takes the client's note on Thursday.

Why it was caught in two hours

A long render can start any time, even at the end of the day.

Nobody should have to keep checking a dashboard, or go to the machine, to see how it's going. So the farm reports to where your team already is: Slack or email.

Posted to Slack	What it carries
Render started	Which scene, who submitted it, what it's rendering on, and how much work is queued
Checkpoint, while running	Frames completed, elapsed time, machines running, an ETA, and an actual rendered frame
Render finished	Completion summary and the final frame

The ETA does quiet work of its own: a producer can plan the rest of the day around a render instead of guessing at it. A public render farm sells you a queue. It doesn't tell your artist, in your Slack, that a shot looks wrong.

Why would I need it

What changes, in practice

Measured on one real production scene — about 3,700 frames of Cinema 4D and Redshift.

	Before	After
A scene that turns out wrong	About ten days: five on the broken scene, found at the end, then five more	Within a day: caught two hours in, fixed, and re-rendered the same afternoon
The artist’s machine	Tied up for the duration	Free. Rendering happens elsewhere.
Finding out a scene is wrong	When the render finishes	As frames arrive in your Slack, with an ETA
Capacity	Whatever hardware you own	Scales to the job. No compute bill when idle.
The deadline	Missed, or an awkward call to the client asking for another week	Met. Nobody outside the studio ever knew.
Team morale	Days of waiting, then the sinking feeling. Shame over the mistake, worry about the blame, and a lost weekend plus a few late nights of rework.	A minor annoyance, fixed before anyone went home
The boss	Not again. The buffer is gone, the client will be unhappy, and there's a team to pay while nothing ships.	A few hundred dollars more on the bill. It shipped on time, and mistakes happen.

Your tools

Your artists keep submitting from the software they already use.

Deadline Cloud has integrations for these applications. Nobody learns a new tool, and no scene gets rebuilt to suit the farm.

Applications

Cinema 4D
Maya
3ds Max
Houdini
Blender
Nuke
Unreal Engine
After Effects
KeyShot
VRED

Renderers

Redshift
Arnold
V-Ray
RenderMan
Karma
Cycles
Octane

We need both halves before we can answer you. The application decides whether a submitter exists to get your job onto the farm at all. The renderer decides what the farm is made of — GPU and CPU are different fleets, not different settings. That is why we ask for both before the first call.

Not sure your setup will work? The Render Assessment tries it on your own scene. If it can't be made to render, you get a written report of what blocked it.

GPUs

Which GPU works best

AWS rents GPU machines in several types. These two are the ones that matter for rendering, and both rendered production frames on the farm we built. The prices are what AWS charged us.

	NVIDIA A10G — the best balance	NVIDIA L40S — when it helps
AWS machine we run	g5.12xlarge	g6e.12xlarge
GPUs per machine	1 / 4 / 8	1 / 4 / 8
Memory per GPU	24 GB	48 GB
CPU threads (vCPUs)	48	48
System memory	192 GB	384 GB
Price per hour, about Linux Windows	$5.70 $7.90	$10.50 $12.70
Speed on a heavy scene	The baseline	About 1.75× faster
Cost per frame	About the same	About the same
Available when you need it	Almost always	Not always
What it is for	Almost every scene	Scenes that need 48 GB, or a tight deadline when machines are free

Compare them on your own scene →

Why we usually pick the A10G. In the AWS region we render in, it turned out to be the best balance of availability and speed: AWS almost always has it, and it renders almost every scene. The L40S finishes sooner for about the same money per frame — when you can get it. We've had jobs sit waiting for L40S machines that AWS didn't have. So we move a job up when the scene needs the memory, or when the deadline is tight and the machines are there.

Linux gives you more usable VRAM than Windows on the same card. Windows reserves a slice for its display driver, and on a 24 GB A10G that reserve is the difference between a scene rendering and the identical scene failing on an allocation error. We lost a day finding that out. It is in no one’s documentation.

On-demand for deadlines, spot when it can wait. Spot capacity is cheaper, but AWS can take a spot machine back in the middle of a frame, and a deadline can't absorb that. So deadline work runs on on-demand machines, and spot is there for renders that can wait.

Prices are AWS on-demand rates, before the Deadline fee and your renderer licensing — see render cost for the all-in figure. You aren't buying a machine: the GPU is picked per job.

The question everyone asks

AWS says you can set this up in minutes. Why would you need us?

If the standard setup works for you, that's great. We're for when you outgrow it.

The setup wizard genuinely gets you a working farm quickly, on AWS's own software packages, and plenty of studios never need more. You outgrow it when your renderer version and plugins, your licensing, how each worker's environment is set up, your asset paths, your farm's limits and preferences or your scene's quirks stop fitting the standard setup. Then the answer is your own packages, or your own machine images, and the work of making them fit.

Outgrowing it is where the minutes stop. On a real first attempt, the worker couldn't find the plugin that starts the application. Once it could, the renderer couldn't find its own data. Once that was fixed, the plugin's parts were installed in one place and looked for in another. Every fix took hours and uncovered the next problem, and none of it was in the documentation.

The studio in this story had already tried, and had been stopped by exactly that boundary before we were brought in.

Honest comparison

Which render-farm approach is right for your studio?

Approach	Works well when	Costs you
Public render farm	Occasional overflow on a standard scene. Genuinely good at this — we won’t compete for it.	Little control over your pipeline, custom plugins or where assets live.
Build it yourself on AWS	You have an engineer who knows both AWS and rendering, and weeks to spare.	The build is the small part. The year after is the real cost.
Hire a cloud engineer	Rendering is a permanent, full-time problem at your scale.	$8k+ a month before they’ve built anything.
Managed implementation	You want your own farm without building the competence in-house.	A fixed engagement, then optional ongoing support.

What it costs to build

Scoped, fixed-fee, and priced before we start.

Most studios land in the middle. We can't price yours until we've seen the pipeline — that's what the first call is for.

Start here

Render Assessment

$2,500

You provide

A production scene that renders correctly on your own workstation. A heavy one, so the numbers reflect your real work
How long a frame takes there, and how that machine is set up
Help when we need it: access to your software's installers, a licence or two for the test, and quick answers to our questions
Your own AWS account to run it in, which becomes your farm's home if you go ahead. AWS bills you directly for the test renders. We help you request the GPU capacity, and the two weeks start once it's in place

You get, within two weeks

Your scene rendered on a farm built for the test
Minutes a frame, cost a frame, and what a full job would cost
A written recommendation and a scoped, fixed-fee proposal
If it can't be made to render, a written report of what blocked it

Credited in full against an implementation booked within 60 days.

Quickstart

Farm, queue and one GPU fleet
One application and renderer: Maya, Houdini, Cinema 4D, Blender or another
Submission from inside your application
Slack render reporting, yours to keep (updates come with a plan)
Assets checked before they reach the farm
Cost dashboard, matched to your AWS bill
Documentation and handover

Build cost: $20k

Recommended for production teams

Production

Everything in Quickstart
Multiple fleets and GPU tiers
Cost per job, reconciled the next day
Benchmark and cost-per-frame report
Training for up to 3 people

Build cost: From $30k

Studio Pipeline

Everything in Production
Several applications and renderers
Shared storage design, including your own NAS
Custom submitters
Pipeline integration
Training scoped to your team

Build cost: Individual

What it costs to render

You pay AWS directly. We don’t mark it up.

Put in a job of your own: how long the film is, how long a frame takes on your workstation, and how many previews you run before the final. You'll see what it costs and how long it takes, on both GPUs.

Length, min : secMinutes a frame, full resPreview passes

That is 4,320 frames.

	A10G — the best balance	L40S — when AWS has it
Preview	2 × $389 = $778 · 4.5 hours	2 × $387 = $775 · 2.6 hours
One full-resolution render	$1,513 · 8.7 hours	$1,476 · 5.0 hours
The job: 2 previews + full	$2,292 · 13.2 hours	$2,251 · 7.7 hours

Workers 25Your AWS GPU limit sets the ceiling. New accounts start low; we request more as part of the build.

Minutes a frame means a full-resolution frame on your own workstation; a top-end one renders about as fast as one A10G machine. Previews are assumed to render about four times faster. Every machine takes about five minutes to start, and that is included. The L40S is about 1.75× faster on a heavy scene, but AWS doesn't always have them free. All of these figures are approximate: real cost depends on your scene, resolution, renderer, how the fleet starts up and AWS's prices. Rates include the four-GPU machine and the scheduler fee. With licences from AWS they also include about $1.25 an hour of renderer licensing, an approximate average of usage-based rates on Deadline Cloud (Arnold is $0.66, KeyShot $1.50).

More machines doesn’t cost much more. Ten workers for an hour bill about the same as one worker for ten hours. The compute costs about the same either way; what you choose is how long to wait — which is why there’s no reason to render slowly.

Estimates before, the real bill after. We tag every machine, disk and licence-hour the farm uses, and set up a cost dashboard on top of it. You see what rendering actually cost: in total, by type of machine, and production apart from testing, matched to your AWS bill the next day. On Production builds, per job too.

What it costs to keep

No compute bill when it’s idle. Mostly storage.

Hardware bills you whether it renders or not — the capital, the power, the space, and a machine worth less every month. This doesn’t. Workers exist only while there is work: the fleet scales to zero when the queue drains. A month with no renders bills no compute at all.

It stays yours the whole time. It runs in your own AWS account, under your billing and your IAM. Terraform and Packer come to you under licence. No seat fee, no subscription, no key to renew — if you never speak to us again, it keeps working.

What bills while the farm sits idle is mostly storage, and it can be as low as about $23 a terabyte a month. Old scenes and rendered frames delete themselves after 60 days, or whenever you choose, so it doesn't pile up.

What it costs to maintain

It keeps working. Staying current is a different job.

Your application and renderer, the Deadline agent, the GPU driver and the operating system all move on their own schedules. Most of those releases don’t matter to you. Knowing which ones do — and rebuilding the image when one does — is the work.

Every implementation includes three months of settling in, counted from handover (the Assessment is a test, not an implementation). During it we diagnose, teach, fix and maintain — whether the cause turns out to be the farm or the scene. Most early problems are scene-side, and while you're learning the system we don't make you argue about which is which.

After the settling-in period	What that means
How you reach us	A shared inbox, or a Slack channel in your workspace - whichever your team already lives in.
Business hours	Monday to Friday, 09:00–18:00 US Pacific. Wherever you are, we answer within one business day; the callout is for urgent work outside those hours.
Outside those hours	$750 callout — covers the response and up to two hours. Anything more is quoted first. Nothing is ever refused; the price decides whether it's really urgent.
Asking a price	Always free, from what you describe. Finding the cause is work, and we quote it first. Nothing starts until you agree, so you never get an invoice you didn’t expect.
If you change the farm	It is yours to change. On a plan, we check monthly that it still matches what we deployed.

Or an ongoing plan

After three months you either move to a plan, or you're on your own with the farm you own. Starting a plan later, or again after a gap, begins with a quoted check of the farm. The work is the same either way. What a plan buys is when it happens: scheduled, before it bites, rather than queued after it has.

Advise

$1,200 / month

We tell you what changed, what it does to your farm, and how long you have
The work happens when you choose: scheduled, not queued
You do it, or we do, quoted and scheduled
Front of the queue if something breaks

Nothing for you to track

Maintain

$2,500 / month

You don't have to find out: we track it
The work happens on a schedule we agree with you, before it bites
We do it
Front of the queue if something breaks

Both include: tracking updates from your application and renderer vendors, NVIDIA and AWS · updates and fixes to the Slack render reporting · a monthly check that the farm still matches what we deployed · a monthly cost report (per job on Production builds) · crunch weeks declared in advance at $1,500 a week.

What we won't promise: GPU capacity during crunch — that belongs to AWS, not to us. And no guaranteed time to restore, because nobody can promise one honestly. What we commit to is watching, failing over across instance types and zones, and picking up the phone.

Why us

We've already been through it.

Built and run in production. The farm in the story above rendered real client work, not a demo.

We know where it breaks. Every one of those failures cost hours to find, and we have found them already.

We fix things at the source. When AWS’s own integration made renders come out dark, we found the bug, and our fix was merged into AWS’s code. It now ships to everyone.

You keep everything. Your account, your farm, and the code to rebuild it. No lock-in.

Honest numbers. An estimate before you render, and the real bill per job after.

We love this work. And once your farm is running, we have a few more interesting things to show you.

Your artists shouldn't lose a workstation to a render.