20-node RTX 5090 fleets · Your credentials · Your data · Cross-country optimized
The SaaS render farm model fits most studios — upload, render, download, managed licenses, no infrastructure to think about. It does not fit every workload. Some teams need a private GPU fleet that no other tenant shares, credentials that never leave the customer's identity boundary, and a network path that survives long-distance links between artists and the render hardware. That is the territory this page covers.
A dedicated GPU cluster rental from Super Renders Farm means a fenced section of the render fleet — RTX 5090 nodes, a shared cache box, an encrypted tunnel to the customer's location — operated for one organization at a time. We have built deployments like this for creative agencies and VFX studios with these six capability anchors:
The customer signs into their own cloud storage account on each node. Super Renders Farm provides hardware, OS, render apps, and the cache layer. We never hold the customer's storage credentials, never inspect files, and never retain data after a deal closes. End-of-engagement wipe and reimage are part of the standard cycle, with a written attestation.
Assets stream from the customer's cloud once into a single shared SMB3 cache, then every node in the cluster reads from local LAN. The naive alternative — one cache per node — multiplies storage and international bandwidth by the node count. Twenty nodes at 10 TB each would mean 200 TB of duplicated pulls. Shared cache avoids that, and pre-warming the cache before a render day removes cold-pull latency on the first frame.
Every connection between the customer and the cluster runs through WireGuard with encryption by default. We turn on BBR congestion control on the gateway so throughput holds steady across jittery international and public-ISP segments, and we apply TCP MSS clamping to avoid the MTU blackhole failure mode where small packets succeed and large packets such as TLS, RDP, and SMB silently drop. This stack is not theoretical — it is the configuration our cross-country deployments actually run.
Each node runs Sunshine as the streaming host with NVENC hardware encode; artists connect with Moonlight. The result is a remote experience tuned for 3D and GPU workloads — not the generic RDP latency profile that breaks on viewport interaction. Parsec is supported as a fallback when a specific workflow needs it.
A common pattern: roughly half the nodes come from existing rack capacity at the main datacenter, the other half from rented space at a secondary site. The two sites connect via WireGuard site-to-site. Customers do not pay for twenty new nodes built from scratch — they pay for the cluster that meets their headcount and timeline. This is the lever that keeps dedicated deployments financially comparable to long-duration SaaS billing.
Customers and their nodes see only the cluster they paid for. They do not see the Super Renders Farm internal NAS, router, or shared-tenant nodes. Tier-1 segmentation runs at the edge via routed firewall rules; Tier-2 runs as host firewall on each node. This is the design layer that turns dedicated infrastructure into something operationally enforceable, not just a marketing label.
A dedicated GPU cluster deployment has three planes: the customer's location, the cluster edge, and the render nodes themselves. The cluster edge is a single Ubuntu 22.04 LTS box that runs four functions — WireGuard hub, SMB3 cache, DNS resolver, NTP server — and routes between the WireGuard tunnel and the LAN that the render nodes live on. Render nodes are Windows 11 Pro with RTX 5090 hardware, Sunshine streaming host, the customer's cloud storage client, and the render application bundle the customer specifies.
The hybrid pattern matters because it is how dedicated cluster economics actually work for most enterprise deals. Building twenty fresh RTX 5090 nodes on a six-month engagement does not pencil out. Using ten existing rack nodes plus ten rented at a partner site does. The two groups appear as a single Layer-3 routable cluster to the customer — they can run their own Deadline or render manager across both groups without seeing the underlying site split.
For deeper cross-country network design — WireGuard hub-and-spoke, BBR rationale, MTU clamping symptoms — see the cross-country optimization deep-dive.
Everything below is what dedicated cluster deployments actually run, not aspirational. We list it openly because customers evaluating dedicated infrastructure want to verify they can stand up their own pipeline on top of it.
WireGuard is the only inbound surface — UDP 51820 open to the customer's source, everything else default-deny via ufw. BBR is the TCP congestion control on the gateway because it tolerates jitter and packet loss on international paths better than CUBIC. TCP MSS clamping on the WireGuard router prevents large-packet drops through the tunnel — without it, small probes work and TLS, RDP, and SMB silently fail when they hit the MTU ceiling.
Samba 4 on Ubuntu 22.04 LTS, SMB3 protocol, served from a single SATA SSD on ext4. The cache server is intentionally simple — one ext4 filesystem instead of LVM, single SSD instead of RAID — because the redundancy story is re-fetch from the customer's cloud rather than rebuild from parity. Cache pre-warm before a render day removes the cold-pull penalty on the first frame; live invalidation flows through normal SMB semantics.
dnsmasq serves the internal .lan zone so nodes resolve cache.lan, rn-a01.lan, and similar names instead of IP literals. chrony keeps clocks tight across the cluster — important for render manager log correlation and for any workflow that depends on timestamp ordering across nodes.
Sunshine is the streaming host on each node, encoding via NVENC on the RTX 5090. Moonlight is the recommended client; Parsec works as a fallback when a specific artist machine or network blocks Moonlight. There is a quality gate built into the deployment — internally called the Test-8 checkpoint — that verifies the stream meets the bar before a node enters service.
The customer specifies the bundle. Common installs include Cinema 4D with Redshift, 3ds Max, Maya, Blender, Houdini, After Effects, and NukeX, paired with V-Ray, Corona, Arnold, Redshift, Octane, or Cycles depending on the customer's pipeline. Plugin installs and version pinning are part of node imaging — we keep the image deterministic so a refreshed node behaves identically to the one it replaces.
Every node is Layer-3 routable. The customer can stand up their own Deadline server, their own license server, their own NAS mount layout, and treat the cluster as raw compute. Super Renders Farm provides the substrate; pipeline orchestration belongs to the customer when they want that level of control.
For operational depth on a full deployment cycle, see how we deploy 20-node dedicated GPU render farms.
For credential-handling specifics, see the Model B credentials guide.
Dedicated GPU cluster rental is not the right answer for every workload. The honest comparison matters as much as the selling points — pushing a dedicated cluster onto a four-frame test render or a one-person archviz freelancer wastes the customer's money and our setup time.
| Use case | Dedicated cluster fit | Why |
|---|---|---|
| Creative agency with IP-sensitive workflows | Strong | Customer-owned credentials + no Super Renders Farm access to project files + end-of-engagement attestation match agency confidentiality requirements. |
| VFX studio with 10+ artists | Strong | Predictable capacity, headcount-stable cluster size, and dedicated bandwidth survive multi-shot deadline crunches. |
| Cross-country team (US + EU + Asia mix) | Strong | WireGuard + BBR + MSS clamp stack is built for jittery international paths; shared cache cuts the per-team international bandwidth bill. |
| Long-duration project (3+ months) | Strong | Setup amortizes across the engagement; hybrid own-plus-rent economics work best at multi-month timelines. |
| High-security workflow (no farm data access) | Strong | Tier-1 edge segmentation + Tier-2 host firewall + customer-owned auth means Super Renders Farm operationally cannot reach customer data. |
| Short burst render (hours to days) | Weak | SaaS managed render farm is the better fit — billing aligns with usage and there is no setup overhead. |
| Single-artist freelance project | Weak | Cost of a dedicated cluster outweighs the value at this scale; SaaS pricing tiers are designed for this case. |
When the SaaS managed model is the better fit, we say so. Compare SaaS vs dedicated for the full decision framework.
Dedicated GPU cluster rental is quoted per engagement, not per minute or per frame. Pricing depends on cluster size, engagement duration, the own-versus-rent mix at the secondary site, the bandwidth profile the customer needs, and the render application bundle. The shape of a typical quote includes a setup fee, a monthly minimum, and a multi-month commitment window — the specifics belong in a direct conversation with our enterprise team rather than on a public page.
If your team is still deciding between managed SaaS and a dedicated cluster, the pricing conversation can include a comparison against equivalent SaaS volume — we are not interested in selling a dedicated cluster to a team that would be better served by per-frame billing on the main rental options page.
Practical minimum is around eight RTX 5090 nodes. Below that the per-node operational overhead — edge box, cache server, segmentation rules, monitoring — dominates the economics, and a managed SaaS plan typically delivers better value.
Yes. Model B / BYOC is the default for dedicated cluster engagements. Each node signs into the customer's storage account (for example, Frame.io, Dropbox, or any other cloud-streaming client the customer prefers) using the customer's own credentials. Super Renders Farm never holds those credentials.
Three layers. Customer-owned credentials mean we cannot reach customer cloud data. Tier-1 edge segmentation and Tier-2 host firewalls mean nodes cannot reach our internal infrastructure. End-of-engagement reimage and cache wipe with a written attestation close the loop on residual data.
Every node is reimaged from a clean base. The shared cache server is wiped. We issue a written attestation confirming the wipe and reimage cycle. If the customer wants a hash-level inventory of the wipe scope, we provide it.
Yes. The WireGuard tunnel stays up continuously; Sunshine streaming hosts are available whenever the cluster is in service. Maintenance windows are coordinated in advance with the customer.
Yes. Every node is Layer-3 routable, so a customer-managed Deadline server (or any other render manager) can drive the cluster directly. We provide the compute and the network substrate; pipeline orchestration is the customer's domain when they want that level of control.
Pricing is per engagement, not per render minute. Quotes include a setup fee, a monthly minimum, and a multi-month commitment window. The exact numbers depend on cluster size, duration, own-versus-rent mix, and bandwidth profile. Contact our enterprise team for a quote tailored to a specific project.
Two to four weeks from contract signature to production readiness. Setup covers procurement or reallocation of nodes, edge box configuration, WireGuard provisioning, cache pre-warm, render application install and version pinning, and the streaming quality verification gate before the cluster enters service.
Our main datacenter is in Hà Nội, Vietnam, with international fiber for cross-country links. Secondary sites for hybrid deployments are coordinated per engagement — typically other Hà Nội facilities or partner racks. Customer geographic latency is addressed by the WireGuard + BBR + MSS clamp stack rather than by datacenter proximity.
WireGuard handles encryption with low per-packet overhead. BBR congestion control on the gateway holds throughput steady through international jitter and public-ISP segments better than CUBIC. TCP MSS clamping prevents the MTU blackhole pattern where large packets silently drop. The shared SMB cache moves the heavy assets to the cluster's LAN, so most artist traffic is interactive streaming rather than bulk asset transfer.
Yes, within the bounds set in the engagement contract. Scale-up typically requires one to two weeks for new node provisioning. Scale-down is faster — nodes can be removed from the cluster, reimaged, and returned to the shared pool within a few days.
