Run Blender headless on a CPU-only cloud VPS: what works and what it costs

What works headless

• Scripting. Everything in the bpy Python API that does not need a window: building scenes, importing models, materials, cameras, lights.
• Cycles stills on the CPU, with the OpenImageDenoise denoiser.
• Export and re-import of glTF/GLB, FBX, OBJ, USD and STL (we exercised each over our tool server).
• Turntable video. Blender 5.2’s own video output path worked, using the FFmpeg bundled in the official build rather than one from the OS package manager.

# render.py - run with:  blender -b -P render.py
import bpy

scene = bpy.context.scene
scene.render.engine = "CYCLES"
scene.cycles.device = "CPU"
scene.cycles.samples = 16
scene.render.resolution_x, scene.render.resolution_y = 640, 480
scene.render.filepath = "/tmp/cube.png"
bpy.ops.render.render(write_still=True)

bpy.ops.export_scene.gltf(filepath="/tmp/cube.glb", export_format="GLB")

Illustrative script, not a measured benchmark; the timings below came from our tool server driving the same engine.

What does not

We did not offer the interactive UI or the EEVEE engine, and we did not test either on a server. Our desk research found two reasons, both from public or vendor sources rather than our own measurement: Blender’s published hardware minimums (4 cores, 8 GB and a GPU with 2 GB) describe the UI and EEVEE, and EEVEE needs an OpenGL context, which a GPU-less server can only fake with software rendering that reports describe as slow and flaky. Cycles on the CPU in background mode is the supported path.

A GPU would also make renders much faster; that is simply a different product. One third-party data point from that research (not ours): a 2 vCPU machine took about 39 seconds a frame, mostly in the denoiser, against about 1.5 seconds with a GPU.

What it measured on a 4 vCPU / 8 GB server

Three test runs on a shared-CPU server with 4 vCPU and 7.9 GB of RAM, plus a fresh Ubuntu 22.04 server (the image some providers still hand out, with Python 3.10 where 24.04 has 3.12). Single observations, no variance.

• Install: 73–86 s on Ubuntu 24.04 and 86.7 s on 22.04, of which the 383 MB official tarball took 3–4 s to download (about 130 MB/s), and checking and unpacking it 27–40 s.
• On 22.04 the default cube took 5.67 s to render and 11 s end to end.
• Each full test run cost $0.07 in server time.

A turntable at default settings is the thing to watch: 36 frames took about 500 s, which blew through the 300 s job limit we started with. A short low-sample turntable (12 frames at 480 px, 8 samples) took 43.8 s.

Memory: the limit that matters

Blender does not fail gently when it runs out of RAM, so each job runs under a virtual-memory limit of 70% of the machine. Normal renders pass. The surprise is that Cycles reserves about 1.25–1.4 times as much address space as it actually uses, so the effective ceiling on an 8 GB box is a resident 3.7–4 GB, not the 5.56 GB (5,558 MB) the limit suggests.

We tested the edge with a 16.1 M-triangle scene. Without the limit it rendered in 47.6 s and peaked at 5.17 GB. With the limit it was refused cleanly, with a message that the job ran out of memory, the service stayed up and the kernel’s out-of-memory killer never fired. We kept it that way: conservative, but a refused job is better than a dead server.

The plan floor we chose, and why

We offer Blender on plans from 4 vCPU / 8 GB up. That is a choice backed by the numbers above, not a discovered minimum: nothing smaller was run. By inference only, a 4 GB box under the same limit would refuse the 4-million-triangle scene (3.88 GB of address space against about 2.8 GB allowed).

Letting an agent drive it over MCP

Our preset runs Blender in background mode behind a small MCP (Model Context Protocol) server that listens on the server’s loopback interface only, so nothing is exposed to the internet. It offers eight tools: blender_info, run_bpy, import_model, apply_material, render_still, render_turntable, export_model and scene_info. Outputs come back as file paths and, once the server has an app hostname, as links.

On a raw Ubuntu 22.04 server, Hermes, Claude Code and Codex each listed all eight tools after registration. The registration for each, if you do it by hand:

# Claude Code
claude mcp add --scope user --transport http blender http://127.0.0.1:8030/mcp

# Codex (~/.codex/config.toml)
[mcp_servers.blender]
url = "http://127.0.0.1:8030/mcp"

# Hermes (~/.hermes/config.yaml)
mcp_servers:
  blender:
    url: http://127.0.0.1:8030/mcp

# OpenClaw: a bare url FAILS, it needs the transport named
openclaw mcp set blender '{"url":"http://127.0.0.1:8030/mcp","transport":"streamable-http"}'

The OpenClaw note is real: with only a url it reported SSE error: Non-200 status code (400) and listed nothing. Naming the transport as streamable HTTP fixed it. If you run these agents yourself, see self-host OpenClaw, self-host Hermes Agent and Claude Code and Codex on a VPS.

Bugs only real hardware showed

• A default turntable needed about 500 s against a 300 s timeout, so it always timed out.
• The light rig we added to imported models was roughly 50 times too bright.
• A turntable read its camera before the scene graph was updated, so every frame came out black.
• On a 22.04 server, the Python dependencies had to be locked to wheels built for Python 3.10: a test that only runs on 24.04 would not have caught that.

We checked renders for validity, not artistic quality. And pin what you install: the Blender tarball is checked against its published hash, as in pin your agent versions.

Related

• Run Godot headless on a VPS — the same approach for games and web exports.
• The cheapest VPS for AI agents — the floor for the agents themselves.
• What an AI video clip costs on a rented GPU — when you do need a GPU.