Skip to main content

Cross-Country Render Farm: Optimized Long-Distance Rendering Workflows

WireGuard encryption · BBR congestion control · Shared cache · For globally distributed creative teams.

Contact for Cross-Country DeploymentSee the Architecture

Why Cross-Country Rendering Is Different

Modern creative work is increasingly distributed. A 3D pipeline can have an art director in New York, a lighting team in Berlin, freelance look-dev artists in Seoul, and a render fleet on a different continent again. When all four sit on the same gigabit LAN, render farm access is a non-problem. When they do not, the workflow runs across the public internet, and every quirk of long-distance routing starts to show up in the timeline.

Three issues recur in this kind of setup. The first is latency — round-trip times of 150 to 250 ms between continents change how interactive any remote desktop feels, and they amplify any chattiness in a render manager or asset-streaming protocol. The second is jitter — international links often run hot, and packet timing varies. The third is bandwidth cost and contention — pulling a 40 GB scene file across an intercontinental link once is acceptable; pulling it twenty times because each render node has its own cache is not.

A local render farm sidesteps most of this. Teams that already have a cluster in the same datacenter region as their artists do not need most of what this page describes. Cross-country rendering becomes the right architectural choice when one of the following holds:

  • The team is split across regions and needs a single shared render fleet.
  • Hardware availability or cost makes the customer-preferred GPU class easier to source in one region than another.
  • The artist team is decoupled from the render hardware on purpose — for example, a US-based studio renting dedicated capacity in Asia for project-specific scale.
  • Cloud storage and project files already live in one region, and the render fleet has to read from them either way.

When any of these are true, the question becomes operational: how do you make a render farm on the other side of the world behave like part of the artist's local network. The rest of this page is how we approach that at Super Renders Farm.

Network Optimization Stack

Network Optimization Stack

We optimize cross-country links with four pieces, applied together rather than one at a time.

WireGuard for encrypted long-distance transport

Every connection from a customer endpoint to the render farm runs over WireGuard. The customer's machine becomes a WireGuard peer; the main datacenter runs a hub. Encryption is automatic and end-to-end; the customer does not see plaintext traffic on the public internet, and neither do we. WireGuard is also lightweight enough that it does not become the bottleneck on a long-distance link — its overhead is much smaller than a traditional IPsec stack.

TCP BBR for congestion control

The Linux kernel's default congestion control (CUBIC) is conservative when faced with jitter and packet loss — it reads loss as a signal to slow down, even when the loss is from intermittent international routing rather than actual congestion. BBR (Bottleneck Bandwidth and RTT) measures the actual bandwidth-delay product of the link and keeps the pipe full when capacity is available. On a stable transcontinental route, BBR commonly delivers two to three times the throughput of CUBIC for the same hardware. On a jittery route, the gap is larger.

TCP MSS clamping to avoid MTU blackholes

When a packet travels through a tunnel like WireGuard, its effective Maximum Transmission Unit (MTU) is smaller than on the underlying interface. If a TCP connection negotiates a Maximum Segment Size (MSS) larger than the tunnel can carry, two things happen: small packets succeed, large packets get silently dropped. The symptom is one of the more frustrating in remote work — SSH works, ping works, but TLS handshakes, RDP sessions, and SMB file copies of any meaningful size all hang. We clamp the MSS at the WireGuard gateway so that all TCP connections negotiate a segment size the tunnel can actually deliver.

Internal DNS and time services

Inside the farm, we run `dnsmasq` for internal DNS resolution and `chrony` for time. These are quiet pieces of infrastructure that matter more than they look. Internal DNS means render nodes refer to the shared cache as `cache.lan` instead of an IP address, which makes the layout safe to rearrange. Time synchronization matters because most render managers and log pipelines do not tolerate clock skew well — a node that is 30 seconds off the rest of the fleet can produce confusing job-assignment behavior. Both services listen on the internal network only; nothing from the public internet talks to them directly.

Together, these four pieces are what makes a long-distance render farm feel less like a remote machine and more like a slow-LAN extension of the artist's workstation. None of them are exotic; the value is in applying them as a stack and tuning the parameters for the specific routes the customer's traffic actually takes.

Architecture for Long-Distance Workflows

The deployment shape we use for cross-country setups is a hub-and-spoke topology, with a single primary datacenter as the hub and one or more secondary sites connected over site-to-site WireGuard.

Hub-and-spoke topology: main datacenter and secondary site

A few decisions in this layout are worth calling out because they recur every time we set one of these up.

The edge and cache run on one box, not three. The same Ubuntu machine that terminates WireGuard from the outside world also hosts the Samba cache, the internal DNS, and the time service. We do not split these roles across multiple machines unless there is a specific reason to. The right-sizing is deliberate. A single dedicated cache box has one network path in and one network path out, which makes the routing math simple. It also makes failure modes easier to reason about — if the cache is up, internal services are up; if it is down, nothing internal works, and that single signal is easier to alert on than three separate ones.

Site-to-site WireGuard handles the secondary location. When the deployment spans two physical locations — for example, a main datacenter plus a smaller rented site in the same metro — the two are linked by a site-to-site WireGuard tunnel over the public ISP. The traffic between them looks, from the host's perspective, like one big subnet. Render group B at the secondary site reads from the cache at the main DC the same way render group A does, just with more hops.

The network is Layer-3 routable. Every node is a real IP host that other nodes can address directly. We do not insist on a particular render manager. Teams that prefer Deadline can run their own Deadline repository on a customer-owned coordinator node; teams that prefer something else can run that. The farm provides the hosts, the network, the cache, and the optimization stack; the orchestration layer on top is the customer's choice.

For a deeper walk-through of how this comes together, the operational deployment guide covers the full procedure step by step, and the architecture deep-dive goes into the WireGuard and cache design in more detail.

Bandwidth Optimization and Shared Cache

Intercontinental bandwidth is expensive in two senses: it costs money on the cloud egress invoice, and it costs time when artists are waiting for an asset to come down the pipe. A render fleet that does not think about this can spend a meaningful fraction of every job's wall time on cold-pulling scene files that are already sitting in cache somewhere else in the building.

The shared cache pattern is the simplest and largest lever. One Samba (SMB3) cache server in the main datacenter holds project assets. Each render node mounts the cache and reads scene files over LAN. When a new asset is referenced by a job, the cache pulls it from the customer's cloud storage once. Every subsequent node that needs that asset reads it from the LAN copy. A 20-node fleet that would otherwise pull a 40 GB scene file twenty times pulls it once.

This is straightforward in principle. In practice, two pieces of the design matter.

Avoid per-node caching. It is tempting to give each render node its own large local SSD and let it cache whatever it wants. For a 20-node fleet with 10 TB of project data, this becomes 200 TB of duplicated storage with no shared invalidation story. We do not do this. The shared cache is the only cache; nodes treat their local disks as scratch space, not as a project archive.

Pre-warm the cache before D-day. When a customer announces that a project starts on Monday, we pre-warm the cache over the weekend. The first job on Monday reads from a warm cache instead of triggering twenty hours of cold pulls. This is the single most reliable way to make the first render of a project feel fast.

A note on right-sizing: the cache box uses a single SATA SSD with an ext4 filesystem. For a cache (as opposed to primary storage), a single-disk layout is the correct trade-off. The cache is not the source of truth — the customer's cloud storage is — and the cache can be rebuilt by re-pulling from cloud or rsyncing from a project backup. Building a redundant array on top of an encrypted volume would add cost, add complexity, and not change the operational story; a node losing the cache is a one-evening rebuild, not a data loss event. Right-sizing the cache hardware to match the role is one of the easier ways to keep operating cost predictable.

For teams considering a permanent cluster rather than a single cross-country deployment, the dedicated cluster options page covers what that arrangement looks like in more detail.

Performance Characteristics and Fit

Performance Characteristics and Fit

Cross-country render farms are not a uniformly better option. They make sense for a specific kind of workflow, and they trade off against a local farm in predictable ways.

Stream quality for remote 3D work

For artists who need to drive a GPU node interactively — for example, opening a Cinema 4D scene with Redshift, doing IPR previews, or framing renders before submitting full jobs — we use Moonlight as the client and Sunshine as the host. Both use NVENC hardware encoding on the render node's GPU, which produces a noticeably smoother stream than software-encoded remote desktop protocols. Encoded video over a tuned long-distance link delivers an experience that is usable for real work, including high-detail viewport interaction; the same workload over plain RDP often does not. Parsec is configured as a fallback for the rare cases where Sunshine has trouble negotiating a session.

Latency profile, in general terms

A well-tuned intercontinental link typically lands at 150 to 250 ms round-trip. The number depends on the geographic separation and on the route the customer's traffic actually takes. We do not publish a specific city-pair latency on this page because it does not generalize — your own ISP, your own peering, and your own local hops dominate the experience as much as any number we could quote. We can run a probe from a candidate endpoint during the planning phase and share the actual measurements for the route your team will use.

Tested at meaningful fleet sizes

Our cross-country deployments have run at 20-node cluster scale with current-generation consumer GPUs (RTX 5090 class hardware), with project storage on the customer's own cloud platform. This is roughly the scale at which the architectural choices in the previous sections start to matter — at smaller fleets, a less-optimized setup can get away with more.

When this is the right fit

Cross-country rendering is the right fit when artists are distributed and the render fleet has to be somewhere, when project data already lives in a specific cloud region, when the customer needs IP-isolated infrastructure that the local options cannot supply, or when GPU availability or cost favors a particular region.

When a local farm is a better fit

If everyone on the team works from the same office or country as the render fleet, the optimizations on this page are mostly unnecessary overhead. A local farm with shorter pipes and simpler routing will be easier to operate and will not benefit from BBR or MSS clamping in the same way. Honest counter-positioning matters: not every team needs this architecture. For workloads where artists and render hardware can sit in the same region, the standard render farm rental options cover the case well.

Frequently Asked Questions

In general terms, well-tuned long-distance links land in the 150 to 250 millisecond round-trip range, with the exact number depending on the artist's ISP, the route the traffic takes, and where the endpoint sits geographically. We can run a probe from a candidate workstation during planning and share the actual measured numbers for your route.

BBR congestion control is the primary mitigation — it keeps throughput stable when the link is jittery rather than collapsing on packet loss the way default CUBIC does. WireGuard's own behavior is also forgiving of brief network blips because it does not maintain a session state the way an IPsec tunnel does. For ISP-level outages, the tunnel reconnects as soon as the upstream route is back; in-progress render jobs continue running on the farm side regardless of whether the artist's connection is up.

Yes. Every link is WireGuard-encrypted: artist endpoint to the main datacenter, and site-to-site between the main DC and any secondary site. There is no point on the public internet at which an observer can read plaintext traffic between your team and the render fleet. We do not require trust in any intermediate transport; the encryption is at the WireGuard layer, not bolted on as an option.

Yes. The WireGuard hub accepts multiple peers, so any number of artists from any number of locations can connect to the same farm at the same time. Each artist runs the WireGuard client on their workstation, opens Moonlight, and connects to whichever render node they have been assigned. Internal services like the cache and DNS are shared across the fleet, so two artists working on the same scene from different continents see the same set of assets.

Through the shared SMB cache. When a render job references an asset that the cache has not seen yet, the cache pulls the asset from the customer's cloud storage once. Subsequent nodes that need the same asset read from the cache over LAN at line rate, not over the intercontinental link. For projects with predictable start dates, we pre-warm the cache before D-day so the first render of the project benefits from a warm cache rather than triggering a cold pull cascade.

It works the same way; the geographic separation just means the initial pull into the cache takes longer than it would for in-region storage. Once an asset is in the cache, geographic separation no longer matters — render nodes read from LAN. We typically pre-warm the cache in this scenario so that the cross-region pull happens on our side before the project starts rather than during the first render.

Data residency depends on where the render fleet itself is provisioned, which we plan with the customer ahead of time. For teams with specific residency requirements, the conversation needs to cover where project data is held, where renders are produced, where logs are stored, and how data is wiped at end of engagement. This is a planning conversation rather than a single yes-or-no answer; please contact us to discuss the specifics of your case.

The render itself continues. Render jobs run on the farm side independently of whether the artist's tunnel is up — once a job is dispatched, the artist can disconnect entirely and the frames keep producing. When the tunnel comes back, the artist re-establishes their WireGuard peer and reconnects via Moonlight to the same session. The most common practical impact of a mid-render tunnel drop is that the artist cannot monitor progress live for the duration of the outage; the render itself does not restart.

Next steps

Next steps