Workload · Rendering Blender scenes

A Blender render server that works through your frames while you keep modelling

To build a Blender render server, you put Blender on a Linux machine with a recent NVIDIA graphics card and start renders over SSH with blender -b, so your own computer stays free for modelling. Before anything else, check two things: that Cycles supports the card, and that your heaviest scene fits in the card's memory. When one machine stops being enough, Flamenco shares the frames out across several.

The short version
  1. No screen needed: blender -b renders over SSH
  2. NVIDIA cards need compute capability 5.0 or newer
  3. Your scene has to fit the card's own memory
  4. Flamenco spreads frames over several machines
  5. Whole card, your driver, nothing metered on the port

Will your card render Cycles at all?

It will if it is an NVIDIA card with compute capability 5.0 or higher. That is the floor the Blender 5.2 LTS manual sets for both CUDA and OptiX. Compute capability is NVIDIA's version number for a chip's features, and NVIDIA publishes it for every card. OptiX also needs a driver from the 575 series or later, and on RTX cards it uses their hardware ray tracing for extra speed. OpenImageDenoise runs on the card only from 7.0 upward; on older NVIDIA cards, the OptiX denoiser still denoises on the card.

Examples from our card listNVIDIA's numberWhat Cycles does with it
Quadro 3000M, Quadro K3100M2.1 and 3.0Below the floor: Cycles will not use it
Tesla M60, Tesla P40, GTX 1080 Ti5.2 and 6.1Renders with CUDA or OptiX; denoises on the card with OptiX, not with OpenImageDenoise
Tesla T4, Quadro RTX 6000, Tesla V1007.5 and 7.0Renders, and denoises on the card
RTX A5000, A40, L40S, RTX 50908.6 to 12.0Renders, and denoises on the card

Our AMD Instinct cards are a different story. Blender's HIP backend covers the Radeon RX 5000 series and later, plus the Pro W6000 and W7000 lines, and the Instinct MI50 and MI210 are not among them. For Blender, choose NVIDIA.

How much card memory does your scene need?

Enough to hold the whole scene, and you find out by measuring rather than guessing. Render one heavy frame with --cycles-print-stats added and Blender logs how much memory the render used. Pick a card with clear room above that figure.

  • Textures are usually the big item. The manual's own figures: an 8k image texture takes 256 MB, a 4k one 64 MB, 2k 16 MB and 1k just 4 MB.
  • Running a little over is not fatal. On CUDA, OptiX or HIP, Cycles borrows the server's ordinary memory when the card fills. It slows down, though the manual says it usually still beats rendering on the processor.
  • Two cards do not add up. Each card needs the full scene loaded on it. Only NVIDIA cards joined by NVLink can share, by turning on Distribute Memory Across Devices in Preferences.
  • Smaller tiles help. If memory is tight, the manual suggests dropping Tile Size from 2048 to 1024 or 512, at a small cost in speed.

Don't forget the server's own memory either. Blender asks for at least 8 GB and recommends 32 GB, and any spill from the card lands there.

Getting Blender onto a server with no screen

  1. Install NVIDIA's driver and check that nvidia-smi lists your card. Pick a 575-series driver or later if you want OptiX.
  2. Fetch Blender from blender.org rather than your distribution. Some distributions' own packages are built without Cycles GPU support, the manual cautions.
  3. Compare the download with the checksum file Blender publishes beside it, then unpack it with tar.
  4. Run blender --version to make sure it starts. If it complains about a missing library, install the package that provides it.
sudo mkdir -p /opt/blender && cd /opt/blender
sudo curl -LO https://download.blender.org/release/Blender5.2/blender-5.2.3-linux-x64.tar.xz
sudo curl -LO https://download.blender.org/release/Blender5.2/blender-5.2.3.sha256
grep linux-x64 blender-5.2.3.sha256 | sha256sum -c -
sudo tar -xf blender-5.2.3-linux-x64.tar.xz
sudo ln -s /opt/blender/blender-5.2.3-linux-x64/blender /usr/local/bin/blender
/opt/blender/blender-5.2.3-linux-x64/blender --version

Your first render over SSH

Copy the .blend and everything it links to onto the server, then render with -b, which runs Blender without its interface. One rule trips most people up: Blender reads its arguments in order. Give the output path before the frame option, and put Cycles' own options after a lone --.

# start a session that survives your connection dropping
tmux new -s frames

# render frames 1 to 120 on the card, with a memory report
blender -b myscene.blend -o //renders/shot_#### -s 1 -e 120 -a -- --cycles-device CUDA --cycles-print-stats

# watch the card from a second window
watch -n 5 nvidia-smi

--cycles-device picks CUDA, OPTIX or HIP for that run, so you don't have to change anything saved inside the file. According to Blender's source, it uses every card of that kind with a suitable driver. Swap CUDA for OPTIX and render the same frame again to see which is faster on your scene.

Outgrowing one server: Flamenco

Flamenco is free, open-source render management from Blender Studio, which uses it in production. You run one Manager, a Worker on every machine that renders, and a Blender add-on that sends the job. The Manager hands out frames, so a long animation finishes sooner; a single still image cannot be split across machines yet.

  1. Give every machine the same shared folder at the same path, NAS-style. Sync tools like Dropbox or Syncthing will not do, the Flamenco docs say, because each Worker needs to see files the instant another writes them.
  2. Install Blender in the same place on each machine.
  3. Start flamenco-manager and step through its setup assistant, pointing it at the shared folder and at Blender.
  4. Tell each Worker where the Manager is with manager_url in flamenco-worker.yaml, and download the add-on from the Manager's web page.
  5. Switch each Worker's Blender to the card: the Flamenco FAQ says each Worker renders with whatever its Blender preferences say, so set CUDA or OptiX and the card there, and don't run Workers' Blender with --factory-startup, which puts it back on the CPU. Also set the scene's render Device to GPU Compute before you save the .blend.

With no screen to click through Preferences, that last step is one line of Blender Python. It selects the device type, lets Cycles find the cards, prints what it found and saves the result for the Worker's user.

# on each Worker, once: choose OptiX, switch on its cards, save the preferences
blender -b --python-expr "import bpy; p = bpy.context.preferences.addons['cycles'].preferences; p.compute_device_type = 'OPTIX'; p.refresh_devices(); [setattr(d, 'use', d.type == 'OPTIX') for d in p.devices]; [print(d.type, d.name, d.use) for d in p.devices]; bpy.ops.wm.save_userpref()"

The Manager answers on a single port, 8080 unless you change it, for its web page, its API and file uploads. Keep that port off the open internet. You can give its listen setting a specific address; use a private one, for example on a WireGuard link between your servers.

Why a whole server suits this job

A render ties up a card for hours, so you want nobody else on it. On our GPU servers the card is handed directly to the operating system you install: no time-slicing, no shared slice, nothing pausing your job because another customer's work arrived. You choose the driver and the Blender version, and they stay put until you change them.

  • Files flow freely. The port is unmetered, so big scene folders going up and image sequences coming down never turn into a traffic bill.
  • A screen when you need one. Each server has its own iLO or iDRAC console, so if a new driver knocks the network offline you can still reach the machine from your browser.
  • Room to grow. Memory, disks and port speed can be added to the machine you already have, with no move and no new IP address.
  • Close to you. Five cities, New York to Bucharest, though not every card is offered in every city; the locations page shows them all.

Before you order

  • Mind the timing. A machine already carrying your card is ready about 30 minutes after approval. Fitting a card we hold takes 4 to 24 hours; one we have to buy in takes 5 to 10 working days, and 10 to 15 for a current-generation card on allocation.
  • Monthly suits steady work. If you render once a year for a single deadline, paying per job elsewhere may cost less. If frames go out every week, a server of your own makes sense.
  • More than one card? Builds with several cards in one machine are quoted by hand; the multi-GPU page explains the options.
  • Cycles only. Everything here is about Cycles; check other render engines' requirements separately.

Questions people ask

Can I render on a server without a desktop installed?
Yes. The Blender manual says background rendering needs no graphical display at all, not even an X server on Linux, and that SSH from your own computer is all you need. You copy your files up, run blender -b, and collect the frames when they are done.
Which is quicker for my scenes, CUDA or OptiX?
It depends on the scene and the card, so test it. OptiX can use the ray-tracing hardware on RTX cards but needs a 575-series driver or newer. Render the same frame once with each --cycles-device value and keep the winner.
Can I use the AMD cards for Blender?
Not the ones we fit. Blender's HIP support covers Radeon cards from the RX 5000 series onward, and our AMD cards are Instinct accelerators that are not on that list. For Cycles, an NVIDIA card is the safe choice.
My render runs out of memory on the card. What now?
First measure with --cycles-print-stats to see how far over you are. Shrinking the largest textures and lowering Tile Size often brings a scene back under. If it still does not fit, move to a card with more memory; adding a second card of the same size will not help without NVLink.
Do you run the renders for me?
No, it is your machine. You get root, install Blender and Flamenco the way you like, and no other customer's work runs on your card or your server.

Get a server for your Blender renders

Pick a card that Cycles can use and that holds your biggest scene, then render around the clock without tying up your own computer.

Find your render card

Read next