We hear this a lot. “Can’t we just add more nodes?”
And yes, you can. That logic built the VFX industry. You need more throughput, so you buy more hardware and add it to the pool. It is simple math, and it worked for decades. I am not going to tell you it failed, because it didn’t. It got studios through some of the most complex productions ever made.
The trouble is that the work changed and most farms stayed the same.
Where we come from
Before Juno was a company, our team ran pipelines and render farms inside VFX studios. I started as a compositor at Digital Domain, taught myself Python to build tools for the artists around me, and ended up building infrastructure at Cinesite and other studios. Dan, who now runs our product, was a pipeline TD. Tony spent about a decade running production departments. Between us we have watched a lot of artists wait.
Waiting was the part that bugged me most. Artists waited on workstations, and they waited on render nodes. The way I still put it is that artists just need their workstation running in sixty seconds, not sixty minutes.
The farm had its own version of the problem. Picture 100 servers and 100 jobs queued up, with every server running at half capacity. Another 50 jobs come in and they all wait, while there is idle compute everywhere you look. The math should work. It doesn’t, because nobody taught the farm to share.
That is where Juno started. When I pitched the fix inside a studio, I was told it was ten years out, so I built it at home on a few Raspberry Pis and an old gaming PC. The more studios we have worked with since, the more we see the same problem in different forms.
How farms are built
Traditional renderfarms were designed for batch work. You submit a job, the farm processes it, and you get frames back. The queue is clean and so is the math. A node either has a job or it is waiting for one.
Today’s pipeline is a lot messier. Batch jobs still run, and right next to them are interactive workstations. Artists preview heavy simulations in real time, supervisors review shots before the render finishes, and teams in different time zones hand work back and forth. Compute demand is no longer a queue you can schedule cleanly. It is predictable jobs and unpredictable people hitting the same hardware at the same time.
Run those on separate dedicated hardware and the economics fall apart fast. The farm sits idle between submissions. The workstation pool has GPUs assigned one to one to artists who are on a call or reading notes. Both pools look busy from the outside, and neither is.
Enterprise GPU utilization across on-premises infrastructure typically sits at 10-15% on a fleet-wide, time-averaged basis (sources). The first time studios see that number, it surprises them, and I get why. Every node looks active and the dashboard shows something. But the share of available GPU-hours doing real work is much lower than it looks, and that gap is where the money goes.
What we did about it
Starting in VFX meant solving this on a tight budget. We were not a hyperscaler and could not throw hardware at it. We had to get clever about how compute was handed out, and that constraint ended up being the whole product.
The first thing we learned is that a lot of the pipeline never needed a GPU. Comp, editorial, file wrangling, and plenty of render passes run fine on CPU. If every workstation gets a GPU by default, the cards end up parked under people who never touch them. So in Orion the GPU is part of the workload template. An admin decides which templates ask for a GPU, whether that is a full card or a slice of one, and who can launch them. The CPU-only work runs on CPU nodes, and the GPUs go to the teams and the shots that need them most.
GPU slicing is not new. NVIDIA has had GPU sharing for years through time slicing, MIG, and vGPU. We do not do the slicing ourselves, NVIDIA does. What we built is the scheduling on top, so an artist’s workstation container and a batch render container can share the same physical GPU when it makes sense, or one of them can have the whole card when that matters more.
We built it this way because we kept seeing the same thing at studios. The farm had idle capacity while artists waited on their workstations, and the workstations had idle GPUs while the farm was peaking. The two pools had no way to talk to each other, so they stayed siloed.
When you connect them, things change quickly. Moving from one GPU per artist to a shared pool lets several artists share each GPU. In the setups we have seen, artists did not notice a difference, because the scheduler handled who needed priority and when. Every studio will land on different numbers, but the direction holds. When idle capacity in one pool flows to the work that needs it, you get more out of the same hardware.
The workstation side of it
The other piece is how workstations get set up, and it gets overlooked a lot.
A traditional workstation is a fixed image on fixed hardware. You provision it, maintain it, and replace it, and the environment is tied to the box. If an artist in Vancouver gets their setup perfect for a show and a supervisor in London needs to pick up where they left off, the supervisor starts from scratch or copies files by hand and hopes it works.
Container workstations fix that. The desktop, the application stack, and the project setup live in a container, and the hardware is whatever is free. The same workstation can run on a local node, on a cloud instance, or on a node that just finished a batch job. The workstation follows the artist.
The Linux desktops we provide are built on Helios, our open-source workstation container. Helios is a minimal Linux desktop image that streams to the browser, so there is no VPN or client to install, and you can read the code on GitHub. Studios extend it with their own tools like any other container image, or run their own Linux container instead. The trade-off is that you are now packaging your applications into images, and some of them fight that harder than others. We have hit plenty of apps that needed extra dependencies before they would run properly in a container.
We built all of this because artists do not want to think about infrastructure. They want to click something and have it work. What started as “let’s make it easy for an artist to get a Blender workstation” turned out to apply just as well to researchers who want a Jupyter notebook and developers who want a sandbox.
The 60-second launch came from the same pressure. A supervisor running a review cannot wait 20 minutes for a workstation to spin up. Containers are what make a fast launch possible at scale.
What the renderfarm becomes
We are not saying renderfarms go away. They don’t. Studios with steady, predictable batch work will keep running them, and for pure throughput on known job types a well-tuned farm is still the right tool.
What changes is how the farm relates to everything around it. When the farm is part of one shared pool instead of its own silo, idle farm capacity can go to interactive work during the day, and idle workstation GPUs can pick up batch jobs at night. The same hardware does more without buying more of it.
None of this means shrinking the farm. The goal is to run the farm you have more efficiently and add interactive capacity on top without a matching hardware bill.
Why this matters right now
Buying GPU hardware is hard right now. Lead times are long, and cloud GPUs get scarce at peak demand. Studios feel the squeeze from the infrastructure side too. In a March 2025 survey from TV Tech and Quantum, many respondents rated keeping their infrastructure up to date as a bigger worry than meeting deadlines. If your studio is planning capacity for a bigger slate, the first question is whether the fleet you already have is being used.
In most cases we have seen, it is not, and nobody made a bad decision. The infrastructure was built for a workload that has since moved on. A studio that did all batch rendering five years ago now has a lot of interactive demand on top, on hardware that was never designed to serve both.
Fixing that does not always mean buying more hardware. Sometimes it means connecting the hardware you already have. That matters most for smaller studios, which could never justify a dedicated farm and a separate workstation pool in the first place.
We are happy to work through what this looks like for your setup. Book a time with our team
WRITTEN BY
Alex Hatfield
Alex co-founded Juno to fix how enterprise compute gets done. He leads product vision and customer strategy, and spends most of his time working directly with infrastructure and research teams pushing the limits of what their hardware can do.