VFX taught me everything I know about infrastructure

The first version of Juno ran on four Raspberry Pis, two miniature PCs, and a gaming rig.

We were trying to render an IMAX movie on it.

That sounds like a bad idea, and it was. It was also the constraint that forced us to build something worth building. When you have almost no hardware and real production pressure, you cannot waste anything. There is nothing spare to give. Every CPU cycle has to count, every GPU has to be shared based on what each workload needs right then, and every workload gets exactly the resources it needs and nothing more.

That is where Orion came from. It did not start on a whiteboard. It started with us trying to make something work that had no right to work.

What VFX actually teaches you

The VFX industry has been solving compute problems that the rest of the world is only now running into.

Render workloads are bursty by nature. A production has nothing to render for months, then needs to render everything at once, then has nothing again. Static infrastructure for that pattern is either massively over-provisioned in the quiet months or nowhere near enough during crunch. Neither works when the delivery date is fixed.

Artists need very different amounts of compute depending on what they are doing. A layout artist needs a responsive workstation but not much GPU. A particle simulation artist needs GPU capacity that would embarrass a small data center, for exactly as long as the sim takes to bake. The infrastructure has to serve both without parking expensive hardware on one of them forever.

And the people using it are artists, not infrastructure engineers. They should not have to think about where their compute comes from any more than they think about how electricity gets to the wall. The system has to be good enough to disappear.

We learned all of this under real production pressure before we were a company. It is a strange way to start, and it turned out to be a useful one.

The scheduling problem

The core thing we figured out early is that the scheduling layer is everything.

Most compute infrastructure treats scheduling as solved. You have resources, you have jobs, you match them. Kubernetes does this natively and so does any cluster manager. The trouble is that naive scheduling leaves a huge amount of capacity on the table.

When you give one GPU to one artist and another GPU to another artist, both GPUs are idle most of the time. Interactive work follows people. The artist is on a call, reading notes, or in a review, and the GPU waits. Meanwhile another artist is trying to bake a simulation and cannot get a GPU because every one of them is “allocated.”

So we built a scheduling layer that treats GPU as a shared pool. Essentially, the artist gets their GPU when they need it, and when they do not, that capacity flows to the job that does. Think of it like a restaurant kitchen that cooks to order instead of plating every dish on the menu at opening. The artists do not notice the difference. The utilization numbers change dramatically.

At R3D Studios, this came out to 2:1 GPU density, with 10 artists sharing 5 GPU instances and no performance difference anyone could see. R3D Studios reported up to ~40% compute cost reduction. That math came straight from what we learned on the gaming rig.

The portability problem

The second thing VFX taught us is that production environments move around all the time.

A production might start on-prem because the studio has local hardware. It might burst to cloud during crunch when local capacity runs out. It might run in a remote location because a key supervisor is there. The environment has to follow the work.

That is where container-native workstations came from. If the workstation is a container instead of a physical machine, it runs wherever there is capacity. The artist connects to the same environment in the studio, at home, or on location. The project state, the application stack, and the storage mounts all travel with the workstation.

We built it because VFX productions needed it. Later we found that researchers running computational experiments need the same thing. They want to pick up exactly where they left off no matter which cluster runs their job. Defense teams running classified workloads need environments that are isolated and ephemeral by default. Higher education needs workstations that behave the same for students on campus or off.

VFX forced the problem. The answer turned out to be general.

What “works on anything” means in practice

The gaming rig constraint gave us a platform that runs on whatever hardware is around, which is not what we expected.

Orion runs on NVIDIA GPUs, AMD GPUs, Intel Arc, and CPU-only nodes. It runs on bare metal, VMs, and cloud instances, in air-gapped environments with no external connectivity, and on clusters from a single node up to whatever size the customer needs.

That range comes straight from building something that had to run on four Raspberry Pis and a gaming rig and still produce broadcast-quality output. When you cannot assume hardware, you build for any hardware. That turns out to be exactly what enterprise customers need too, especially the ones with a mix of on-prem hardware, cloud instances, and edge nodes that are all a little different.

Nobody designs for hardware agnosticism on a whiteboard. Necessity forces you into it.

Why this matters if you are not in VFX

The pressures VFX production has lived with for decades are showing up in other industries now, pushed by AI workloads and the broader move to GPU-heavy compute.

Research organizations deal with bursty demand from experiments that need GPU capacity for days and then nothing for weeks. Life sciences teams have the same utilization problem render farms always had. Defense environments need portable, isolated, ephemeral compute that runs on whatever hardware is in the room.

The patterns match even when the specifics differ. The infrastructure that handles them is the same infrastructure that had to render an IMAX movie on a gaming rig.

We think a lot about where Juno came from, because the origin explains the product. The constraints of VFX production are why the scheduler works the way it does, why the workstations are containers, and why the platform runs on anything. If you understand where it came from, you know what it is good at.

It turns out to be good at a lot of things outside VFX. That was never the plan. It is what happened when we solved a hard problem well, mostly because we thought it was a cool problem to solve.

If you want to see what that looks like for your environment, we are happy to show you. Book a demo

Alex Hatfield is the CEO and co-founder of Juno Innovations. Juno builds Orion, the customer-hosted unified compute plane. Orion runs inside your own environment, air-gapped by design, and gives your people one place to use the compute you already have, from GPUs and CPUs to VMs and bare metal.