Cloud render farm for Blender: 87% cheaper than AWS

A render job is a thousand independent frames. Losing one frame costs you five minutes. Buying a dedicated GPU for the week you render costs you five hundred dollars. The economics of rendering are wrong in both directions, and the fix has been sitting inside Kubernetes the whole time.

Pitchlane cut their Blender render bill 87% versus AWS. Rackspace Spot runs render queues on managed Kubernetes at the clearing price of a live GPU Market. GPU A30 nodes start at $0.15/hr. Across 2.5 years of operation, 96% of Spot bids ran without a single interruption.

Spot helped us render videos at scale without going bankrupt as a bootstrapped company. Monthly expenditure compared to AWS dropped by 87%. Patrick M., CEO and Co-founder, Pitchlane.

Why a render farm belongs on Spot instances

Every Cycles frame is a self-contained batch of samples. The scene loads, the frame computes, the EXR writes. There is nothing to preserve between frames. If a Spot node gets pre-empted mid-frame, you lose that one frame. The queue picks up the next frame on the next available node.

Pre-emption runs with a six-minute grace window. The queue manager watches for the signal, drains the worker, and reschedules the frame on a fresh node. The job completes. The bill reflects only the hours your pool actually ran.

Cloud render farm cost: a 1,000-frame Blender job

A 1,000-frame Cycles job averaging 4 minutes per frame on an A30 is 67 GPU-hours. Here is that cost at each pricing model.

A30 Spot starts at $0.15/hr. Typical cloud GPU uses a published $0.84/hr equivalent. Dedicated weekly assumes a $495 weekly subscription prorated to this job.

Nothing magical is happening here. You pay only for the hours your queue ran, at a price the Market sets. The savings come from two places. Idle GPUs cost you zero. A dynamic price finds the floor during off-peak hours.

How Spot pre-emption works on a render farm

Pre-emption happens when the clearing price for a pool rises above your bid. The platform sends a signal to every node in the pool. You have six minutes.

Six minutes is enough time for Flamenco to:

• Mark the current frame as pending and return it to the queue
• Flush any partial EXR tiles to shared storage
• Shut the worker down cleanly

The frame restarts on the next available node, from the start. You pay for the compute the pre-empted worker used, at the clearing price. The next bid cycle runs twenty minutes later.

How to bid for cheaper render farm pricing

The urgency of the job sets the bid. The Market sets what you pay. Every render farm charges you the same whether you need frames by Monday morning or by the end of next month. This one does not.

The bid ceiling, explained. Your bid is the most you are willing to pay per node-hour. You pay the clearing price, which usually sits below your bid. If the Market rises above your ceiling, your nodes are reclaimed. Higher bids trade cash for certainty. Lower bids trade speed for cash.

Autopilot Bids: automated bidding for render farm pools

Rebidding after a pre-emption is manual work. Autopilot Bids is the alternative.

You set: vCPU count. Memory per vCPU (any, 2, 4 or 8 GB). Budget per hour across the pool.

Autopilot runs: Picks the cheapest matching server classes in your region. Places your bids. Rebids on another class within budget when outbid. Shows picks in the Capacity and Health tab.

Autopilot is free on every account. You pay the market price for every node, the same as a manual bid, and never above your budget.

Autopilot runs on CPU server classes. On a render pipeline this means the Flamenco job manager, the storage controllers and any CPU-side preprocessing go to Autopilot. The GPU render workers run on manual bids.

How to set up a Blender render farm on Kubernetes

A Cloudspace is a managed Kubernetes cluster. Add a Spot-backed GPU pool for rendering. Keep an On-Demand CPU pool for Flamenco's job manager, where guaranteed uptime is worth the fixed price. Submit scenes from your workstation.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: flamenco-worker
spec:
  replicas: 20
  template:
    spec:
      nodeSelector:
        rackspace.com/pool: gpu-spot-a30
      terminationGracePeriodSeconds: 330
      containers:
      - name: worker
        image: flamenco/worker:3.6
        resources:
          limits:
            nvidia.com/gpu: 1

Flamenco hands each frame to a worker, watches for completion, and resubmits anything a pre-empted node did not finish. The job manager stays warm on an On-Demand node. The GPU workers come and go at the clearing price.

Which GPU to pick for your render farm: A30 or H100

The right class depends on three things. Scene complexity, VRAM footprint, and whether you are using OptiX.

A scene that spills VRAM falls back to CPU rendering and loses the economic case for a GPU pool. Check VRAM usage locally first with the Blender system console.

Renderers that work on a cloud render farm

Spot runs standard Linux containers. If the renderer runs headless on Linux with a CLI, it runs on a Spot GPU pool.

Blender scene prep checklist before submitting to a render farm

Three minutes of prep saves three hours of re-renders. Before you submit a scene to Flamenco, run through this.

1. Pack external data. File > External Data > Automatically Pack Resources.
2. Pin the Blender version. Set the image tag on the worker to the exact Blender version you tested on.
3. Write outputs to shared storage. Set Output to /render/frames/####, which maps to the PVC mounted on every worker.
4. Use open EXR for intermediates. Multilayer EXR survives partial writes, and recovery is cleaner on retries.
5. Enable Open Image Denoise at the compositor stage. Keeps samples per frame down. 128 samples with OIDN usually beats 512 samples without.
6. Test one frame first. Submit frame 1 alone, inspect the output, then queue the range.

Four ways to submit render jobs to a cloud farm

Pick the one that matches how your team already works.

Flamenco. The Blender Foundation's own job manager. Submit from the Blender UI, watch frames arrive in the shared folder. The friendliest path for an artist-led workflow.

Raw Kubernetes Jobs. For teams already using kubectl, a Job per frame with a parallelism cap scales linearly against the Spot pool.

spotctl + render script. The Spot CLI handles Cloudspace creation and node-pool scaling. Pair it with a small shell script that submits frames in batches and polls for completion. Works for CI pipelines that already drive other build steps.

Spot MCP server. Hand Spot to your coding agent. The Spot MCP server lets Claude, Cursor or any MCP-compatible client stand up a Cloudspace, size a GPU pool and submit a render job from a prompt. Useful when the artist is also the operator.

When to use On-Demand instead of Spot for rendering

Spot is the cheapest way to render when the schedule can absorb a retry. An On-Demand pool gives you the same managed Kubernetes, the same GPU classes and the same regions, with fixed monthly pricing and guaranteed availability. Three situations where On-Demand is the right call:

• A single final frame due in under thirty minutes. Pre-emption risk is low, the clearing price is usually workable, but a reset costs the whole render.
• Interactive look-dev sessions. An artist tweaking samples and waiting on previews should stay on a stable node.
• Render passes that write incrementally to the same file. A pre-empted write mid-pass corrupts the output.

The hybrid cluster is the honest answer. Spot for the batch. On-Demand for the moments that cannot pause. A single Cloudspace can hold both pools.

Cloud render farm FAQ

Do I need to rewrite my .blend files?

Pack external data, point output at the shared PVC path, and submit the file as is.

Does this work with licensed renderers like Octane or V-Ray?

Yes. Install the renderer in the worker image and point it at your license server.

What happens if the whole GPU pool gets pre-empted?

Every frame in flight returns to the queue. Flamenco holds the queue until bids clear again.

Can I use the same cluster for other work?

A Cloudspace can hold multiple pools. GPU pool for rendering, CPU pool for simulation, On-Demand pool for anything that cannot pause.

How are storage costs handled?

Persistent volumes bill separately at a flat rate. A 100 GB scene cache costs a few dollars a month.

Is there a minimum spend?

A Cloudspace with zero running pools costs zero. You pay for the GPU-hours your renders consumed and the storage you kept.

Start rendering on your own cloud render farm

Open a Cloudspace. Add a Spot A30 pool with your bid ceiling. Attach a PVC for scenes. Deploy the Flamenco worker manifest. Submit your scene from Blender. Renders begin within minutes.