Render Dedicated Server

A render dedicated server is a machine built to do one thing at full tilt: turn scenes into frames. Rendering is unusual among workloads because it parallelizes almost perfectly and cares nothing for latency — a node simply runs at 100% for as long as the job takes, whether that is minutes or hours, and what matters is throughput per dollar rather than responsiveness. That shape leads to hardware decisions unlike any other server, starting with a fork the render engine largely decides for you: many CPU cores, or GPUs. This page covers what a render server is, how to choose between CPU and GPU rendering, why VRAM is the ceiling on the GPU path, how to size a node, how a render farm fits together, and the honest question of whether to own the hardware or rent it.

What is a render dedicated server?

A render dedicated server is a single-tenant machine built to render 3D scenes, visual effects, or video — producing finished frames from scene files — where the workload is massively parallel batch compute rather than the interactive, latency-sensitive work most servers do. Rendering repeats the same ray-tracing math millions of times per frame, so it parallelizes almost perfectly and runs a node at full load for the duration of the job. That drives the whole machine: it is chosen for raw sustained compute, as many CPU cores or as one or more GPUs, with memory for the scene and fast storage and networking to move assets and frames.

A render server can stand alone or be one node in a farm coordinated by a queue manager. It does offline rendering — final frames for animation, architectural visualization, product shots, or VFX — which is a different problem from the real-time rendering a game engine does, and it is worth keeping the two separate when reading hardware advice, since their needs are nearly opposite. The reason to use dedicated hardware is that rendering pushes a machine to 100% for long stretches, where consistent, well-cooled, uncontended hardware matters and where the per-frame economics of dedicated capacity beat shared or abstracted environments for sustained work. This is the rendering-specific companion to our general dedicated server hosting guide.

CPU or GPU rendering — the engine decides

The first fork in a render build is CPU versus GPU, and in practice your render engine makes the choice, because changing engine mid-project is rarely realistic. Several engines are committed to one path: Redshift and Octane render exclusively on the GPU with no CPU mode, while Corona and some others are CPU-only, and V-Ray, Arnold, and Blender’s Cycles support both and let you pick per project. So the real first question is what your pipeline already runs on, and the hardware follows from that rather than the other way around.

Where you do have a choice, the trade is speed against scene size. GPU rendering is dramatically faster on supported engines — commonly 10 to 50 times faster than CPU — because a modern GPU has many thousands of parallel cores against a CPU’s dozens, so a frame that takes a many-core CPU several hours can finish on a single fast GPU in minutes. The cost of that speed is the memory ceiling covered in the next section. CPU rendering, slower per frame, keeps two decisive advantages: it handles arbitrarily large scenes through system RAM, and it is the only option for CPU-only engines. The diagram lays the two paths side by side.

VRAM is the GPU rendering ceiling

The single most important constraint on GPU rendering is VRAM, the memory on the card itself, and it is what sends scenes back to the CPU. A GPU can only operate on data that fits in its onboard memory — 24 GB on an RTX 4090, 32 GB on an RTX 5090 — and as a scene’s geometry and textures grow, they eventually exceed it. What happens then depends on the engine. Redshift, Octane, and V-Ray GPU can page textures from system memory when they overflow VRAM, at a performance cost, but geometry is stricter: the triangle data and its acceleration structure generally have to fit in VRAM, so a scene whose geometry alone exceeds the card will not render until it is optimized with instancing, proxies, or reduced detail.

When a scene exceeds VRAM by a wide margin — roughly double or more — out-of-core rendering slows to the point where CPU rendering, with access to far larger system RAM, becomes the practical answer, which is exactly why studios keep a CPU path for their heaviest scenes even when most work runs on the GPU. Multi-GPU nodes can pool VRAM with out-of-core enabled, so several cards present a larger combined memory pool and push the ceiling higher, but this does not fully erase the limit. The clean approach is to match the card’s VRAM to the scenes you actually render, size for your real heavy scenes rather than your average ones, and keep a CPU route available for the occasional scene that outgrows any single card. VRAM, not raw GPU speed, is the number that most often decides whether a GPU render succeeds.

This is also why the headline speed of a card is a poor buying guide on its own. Two GPUs can render a small scene at similar speeds and behave completely differently on a heavy one, where the card with more VRAM finishes while the card with less falls to out-of-core or fails outright. For production work, the practical order is to pick the VRAM that covers your real scenes first, then choose among the cards that meet it on speed — the reverse of how cards are usually marketed, and the way that avoids paying for raw speed you cannot use because the scene will not fit.

How do you size a render node?

Once the CPU-or-GPU path is set, sizing follows the scene and the assets. A CPU render node is built around core count, because CPU rendering scales almost linearly with cores, so production nodes commonly run dual high-core processors — EPYC, Threadripper, or Xeon — with 96 to 256 GB of RAM, since the ability to handle huge scenes depends on that large memory pool holding the geometry and textures. A GPU render node is built around the cards: one to eight GPUs depending on the throughput you need, each with the VRAM your scenes demand, plus enough CPU and system RAM to feed them and run the non-GPU parts of the pipeline. The terminal sketches both shapes.

# render dedicated server · sized to the engine and scene · mcsnet
# two paths, chosen by your render engine
cpu_node = 2x EPYC, 64-128 cores      # V-Ray/Corona/Arnold CPU, huge scenes
gpu_node = 4-8x NVIDIA, 24-32GB VRAM  # Redshift/Octane/Cycles GPU, 10-50x faster
memory   = 128-256 GB system RAM      # CPU path holds big scenes here
vram     = match to heaviest scene    # over VRAM means out-of-core or CPU
storage  = fast NVMe + capable network # asset load + frame writeback
manager  = Deadline or similar queue  # distribute frames across nodes
note     = nodes run 100% for hours; cooling and reliability matter

Storage and networking matter more than newcomers expect, because a render node constantly loads assets and writes finished frames, and on a farm those assets arrive over the network — slow storage or a congested link leaves costly compute idle, waiting on I/O. Memory is the component most often under-sized, and running short forces a fall back to disk or a failed render, both of which waste the compute you are paying for. The sound method is to profile your heaviest real scenes, size memory and VRAM to hold them with headroom, and make storage and network fast enough that the compute is never the bottleneck.

Building a render farm

A single render node speeds up one frame; a render farm speeds up a whole sequence by rendering many frames at once. A farm is several render nodes plus a queue manager — software like Deadline — that takes a job, splits it into frames or tiles, and distributes them across the nodes, collecting the finished output. The appeal is linear: within reason, doubling the nodes roughly halves the time to render a sequence, so a farm turns a render that would take a workstation a week into one that finishes overnight.

Two realities shape a farm build. The first is licensing, which surprises studios: render engines charge per-node licensing for farm use, recurring annually and applying whether a node is rendering or idle, so a farm’s running cost includes a licensing line that grows with node count. The second is the shared infrastructure — the storage holding the assets and the network carrying them — which has to be fast enough to feed every node at once, since a farm that starves its nodes for data is just expensive idle silicon. A well-built farm balances the node count against the licensing cost and backs it with storage and networking sized for the aggregate load, which is where dedicated hardware with fast local storage and a capable private network earns its place over a loose collection of machines.

Scaling a farm has a coordination cost worth planning for too. As node count grows, so does the work of keeping software versions, plugins, and assets consistent across every node, because a single mismatched plugin or missing texture on one node produces frames that do not match the rest — a subtle failure that can waste an entire render. Consistent node images and a shared asset store are what keep a larger farm producing uniform output, another reason a coherent set of dedicated machines beats an ad-hoc mix.

Why bare metal for rendering?

Rendering is a workload that rewards bare metal specifically, for reasons rooted in how it runs. A render node operates at 100% CPU or GPU utilization for hours at a stretch, which makes consistent, well-cooled hardware essential — thermal throttling or contention on a shared or oversubscribed machine directly slows the render and can cause instability under sustained heat, whereas dedicated hardware in a real data center runs at stock performance under continuous load. The table sets out the two node types.

Beyond thermals, bare metal gives the control a render pipeline needs: the freedom to install any DCC application, plugin, and render engine, to run real-time tools like Lumion or Unreal Engine when the workflow calls for it, and to know exactly which GPU and CPU you are rendering on rather than accepting whatever a cloud VM abstracts away — which matters, because render times and even results can vary between hardware generations. For sustained rendering, dedicated hardware also delivers predictable per-frame cost, since you are not paying a per-hour premium on capacity you keep busy anyway. The reliability point is not abstract, either: a render that fails at frame 380 of 500 because a node overheated or a shared host was contended is not merely slow, it is wasted money and a missed deadline, which is exactly the kind of failure that sustained-load hardware in a real facility is built to avoid.

Own or rent? The render economics

Whether to own render hardware or rent it is one of the clearer infrastructure decisions, because it turns almost entirely on how much you render. For occasional rendering — a common rule of thumb is under a couple of hundred hours a month — renting from a cloud or managed render farm is usually cheaper once total cost of ownership is counted, because owned hardware carries costs that continue while it sits idle: large upfront purchases, GPUs that depreciate at roughly a quarter of their value each year, per-node engine licensing that recurs whether the node runs or not, and electricity, cooling, and maintenance. Rented capacity converts all of that into a variable cost paid only while rendering.

The economics invert when rendering is steady and continuous. A studio or pipeline that keeps nodes busy most of the time spreads the fixed costs of owned or long-term dedicated hardware across enough work to beat per-hour rates, and gains capacity that is always available rather than queued behind others at deadline. Many operations run a hybrid: dedicated nodes sized to the steady baseline, with cloud or farm capacity burst on top for crunches, capturing both the low steady cost of dedicated hardware and the elasticity of rented. The number that decides it is sustained utilization — high and steady favors dedicated, low and spiky favors rented — and it is worth calculating honestly rather than assuming owning is always the serious choice or renting always the frugal one.

When a managed render farm fits better

It is worth being direct that a dedicated render server is not always the right tool, because a managed render farm is genuinely easier for many situations. A managed farm lets you upload a scene, handles the licensing and the distribution across its nodes, and returns finished frames, with no server administration, software installation, or license juggling on your side — for occasional rendering, for a small studio without infrastructure staff, or for validating a workflow, that convenience is worth the per-frame premium, and it removes the fixed costs of owning hardware entirely.

Dedicated render nodes earn their place when rendering is steady enough to keep them busy, when you need full control of the software and pipeline, or when you are building your own render infrastructure rather than outsourcing it. In those cases dedicated hardware is both cheaper over time and more controllable, and it becomes the baseline that a managed farm can supplement at peak. The honest split is the same as the own-versus-rent one: steady, high-volume, control-sensitive rendering points to dedicated nodes, while occasional or infrastructure-light rendering points to a managed farm, and we would rather tell you which fits than sell hardware to someone a farm would serve better.

Built for sustained compute from Toronto and six more locations

We build render nodes around the workload: high-core CPU machines with the large memory pools that big scenes need, or GPU nodes with the cards and VRAM your engine and scenes demand, both backed by the fast storage and networking that keep expensive compute fed. Our home data center is in Toronto, with servers in Frankfurt, Strasbourg, Amsterdam, Singapore, Panama City, and Miami, so render capacity can sit near your studio or your asset storage, and for larger builds the same conversation extends to an enterprise dedicated server or a multi-node farm on a private network.

Rendering sits a little outside our core focus on email and web infrastructure, and we will say so plainly — but the foundation a render node needs is exactly what we build everything on: single-tenant hardware that runs at full load without contention, real cooling, and a choice of locations. You can start from standard configurations in our configurator, and we size the node or the farm to your engine, your scenes, and your rendering volume from there.

Why work with us?

We size render hardware to how you actually render: to the engine that sets the CPU-or-GPU path, to the VRAM and memory your heaviest scenes need, and to the storage and network that keep the compute fed rather than idle. That means being honest that GPU is not universally better — VRAM caps it, and CPU-only engines and oversized scenes need the CPU path — and that owning is not universally cheaper, since occasional rendering is better rented. We would rather right-size a node, or point you to a managed farm, than sell a machine that does not match your pipeline.

We are also straight that rendering is adjacent to our main work rather than at its center — but the single-tenant, full-load, well-cooled foundation a render node needs is what we run for our own infrastructure, so the hardware is built for sustained compute even where the workload is not our specialty. We would rather build the render node or farm your pipeline actually needs — sized to the engine, the scenes, and the volume — than quote impressive hardware that bottlenecks on VRAM or sits idle. Compute that turns scenes into frames efficiently is the service.

Who this is for, and who it is not

A render dedicated server is for steady or high-volume rendering: studios and pipelines producing animation, architectural visualization, product shots, or VFX often enough to keep nodes busy, teams building their own render farm, and anyone who needs full control of the render software and hardware. If that is you, a node sized to your engine — many cores and large RAM for CPU rendering, or GPUs with the right VRAM for GPU rendering — backed by fast storage and network, is the right foundation, and on steady volume it beats per-hour rental on cost.

It is not for occasional rendering that a managed farm would handle more cheaply and with less overhead, nor for anyone who would buy a GPU node without checking that their engine and scenes fit its VRAM. Read this page as a guide to a workload with clear rules: if your rendering is steady and your pipeline is yours to run, talk to us about nodes or a farm built to it; if it is occasional, we will point you to a managed farm instead. Rendering hardware matched to your engine, scenes, and volume is what we are actually offering.