Switching From Local to Cloud Rendering: A Migration Guide for Architects
Moving architectural rendering to the cloud works best as a staged migration rather than a single switch. Keep modelling and client review on your local machines, move the step that is actually blocking you first, usually final renders or a batch of camera angles, and expand only once that runs cleanly. Your software decides the type of service before price does. Real-time tools such as Lumion, Enscape, Twinmotion and D5 are single GPU applications that upload and render farms cannot run, so they need a rented machine you control. Offline engines such as V-Ray and Corona run on both models, and Corona in particular is CPU only. Sort out licences, asset paths and billing before the first paid render, because those three are what break migrations.
In this guide, RadarRender will discuss how architects and arch-viz studios can move from local to cloud rendering step by step, covering software compatibility, licensing, project files, testing, and cost control.
What should I check before moving anything to the cloud?
Start with your software list, not with the price list. Record the exact application version, render engine, plugins, asset libraries, operating system and licence type. This information determines which cloud model can actually support your workflow.
Version numbers are especially important. A project may open correctly on the office workstation but fail on another machine because a plugin or renderer is a different release. This is easy to overlook when a studio has accumulated several projects over time.
Before moving anything, record three numbers:
- Render time for one representative frame
- Project size
- Actual VRAM usage during rendering
The frame should represent the kind of work you normally produce. A simple exterior may not tell you much about how a heavy interior scene will behave.
It is also useful to identify where the current workstation is actually slowing the team down. If the problem is viewport performance while modelling, moving only the final render to the cloud will not solve it. If the problem is a long final render or hundreds of camera angles, cloud rendering can address that part of the workflow directly.
Which cloud model fits the software I already use?
Your software decides the model. Real-time apps need a rented machine where you install your own setup. Offline engines run on both automated farms and rented machines. Corona works best on CPU systems.
There are two main models:
- SaaS (Upload & Render Farm): You upload your file, and the farm automatically renders and sends back your images.
- IaaS (Rented Remote Machine): You connect to a powerful remote PC via Remote Desktop and use it just like your own workstation.
| Software / Engine | Upload Farm (SaaS) | Rented Machine (IaaS) | Technical Notes |
| Lumion | Not Supported | Recommended | Real-time app, runs on 1 GPU |
| Enscape | Not Supported | Recommended | Real-time plugin, depends on 1 GPU |
| Twinmotion | Not Supported | Recommended | Real-time engine, runs on 1 GPU |
| D5 Render | Not Supported | Recommended | Real-time ray tracing, runs on 1 GPU |
| V-Ray | Supported | Supported | Offline engine, works on CPU and GPU |
| Corona | Fully Supported | Supported | CPU-only, best on CPU render farms |
Real-time tools like Lumion, Enscape, Twinmotion, and D5 need interactive user sessions and run on a single GPU. Automated upload farms cannot open them, so renting a full machine is your only option.
V-Ray is an offline engine that works well on both models, depending on how much control you want over software versions. Corona runs entirely on CPU, so choosing a CPU-focused render farm is usually more cost-effective than renting expensive GPU machines.
One key hardware rule: VRAM does not stack across multiple GPUs. A node with four RTX 4090 cards (24GB VRAM each) still gives you a maximum of 24GB VRAM for your scene, not 96GB. If your scene exceeds that memory limit, adding more cards will not fix it.
What happens to my software licenses when I render in the cloud?
A rented workstation normally gives you control over the operating system, but you still need to use software licences correctly. The cloud provider does not automatically give you a licence for the applications you install.
For Lumion, the current licensing system uses network-based licence management. Lumion’s documentation also notes that cloud environments need to meet its hardware and remote-access requirements, and that not every virtual machine will work correctly.
source: Lumion
Enscape uses Chaos licensing. Current Chaos documentation distinguishes between licence types and explains that floating licences can be used across machines, while fixed licences are tied to one machine at a time.
Before the first cloud session, check:
- Number of available seats
- Licence type
- Current software version
- Whether remote or cloud use is supported
- How to release or revoke a seat
- Whether another team member is already using the same seat
If you have only one available seat, close the application on the office workstation before opening it on the rented machine when the licence requires exclusive use.
The important point is simple: install the same software version and plugins you actually use, then test activation before the deadline arrives.
How do I move my project files without breaking textures?
Package your project before moving it, use relative paths, and test-open it on the cloud machine before running paid renders. Missing textures are the most common mistake during a first migration. Copying 3D files and texture folders manually often causes missing asset errors. Use your software’s built-in packaging tool (like Resource Collector in 3ds Max or Archive in Blender) to gather all textures, proxies, HDRIs, and assets into one folder.
Absolute paths (like C:\Users\Admin\Desktop\…) will break on a new machine. Switch everything to relative paths or set up a shared folder structure for your team.
The first file upload is always the slowest because 3D scenes and asset libraries are large. Future uploads will be faster since you only sync changes. To save time, upload common libraries (like plants or materials) ahead of time and keep them on the cloud drive if supported.
Before starting a paid render, open the project on the remote machine and test-render one frame to check for missing assets. Also, name your output files clearly by camera angle so combining images from multiple machines stays organized.
How do I run a safe first test without risking a deadline?
Run a real project side-by-side with your old workflow instead of switching completely. Render one test frame first, compare it with your Step 1 benchmark, and only then render the full batch.
To stay safe, pick a project with a relaxed deadline for your test. Never try a new workflow on an urgent project.
Follow these simple testing steps:
- Upload your project to the cloud machine and open the file.
- Check all material and lighting paths.
- Render a single test frame.
- Compare render time and image quality with your Step 1 benchmark.
- Once everything looks good, render the full list of cameras.
Keep your local workstations running alongside the cloud setup during this test. This keeps your studio on schedule even if unexpected issues happen.
In one real test, we uploaded a complex interior scene to a remote server and rendered the whole batch immediately. All the decorative plants turned gray because a custom plugin library was missing. The lesson is simple: always spend a few minutes testing a single frame before rendering the full batch.
How do I keep the bill predictable?
Understand clearly what you are paying for. Rented machines charge you from the moment you turn them on until you turn them off, even when you are not rendering. Upload render farms only charge you for actual render time.
The pricing model you choose determines your budget:
- Rented Machine Model (IaaS): You are billed by the hour the machine is running, starting from when the connect button appears until you shut it down completely. If you leave the machine running while editing models, tweaking materials, or forget to turn it off overnight, you will keep getting charged.
- Upload Render Farm Model (SaaS): Costs are based on the actual number of rendered frames and the hardware processing time used for your file. You do not risk paying for idle time when you are not actively rendering.
Also, keep in mind that performance does not scale linearly when adding more GPUs. Due to data transfer overhead between cards, the real-world speedup is usually about 1.9x for 2 cards, 3.6x for 4 cards, and 6.5x for 8 cards.
Which service fits which kind of architectural studio?
Choose according to your software and working style rather than starting with a brand name.
The main questions are:
- What software do you use?
- Do you need control over the entire machine?
- Do you render in large batches or continuously?
- Do you need a real-time viewport?
- Do you prefer hourly machine billing or per-render billing?
| Service | Model | Best For | Pros | Cons |
| iRender | Hourly rented machine | Lumion, Enscape, Twinmotion, D5, V-Ray | Custom software/plugins; up to 8x RTX 4090 & RTX 5090 | Billed continuously while turned on |
| GarageFarm | Upload & render per frame | Beginners, overnight batch, Corona, C4D | Easy onboarding; great human support for errors | No real-time apps; limited supported plugin list |
| RebusFarm | Upload & render per frame | V-Ray, Corona, EU studios | Built-in scene checker reduces batch errors | No real-time apps; no control over OS/environment |
| Fox Renderfarm | Upload & render per frame | High volume, long projects | Cost-effective for large batch rendering | No real-time apps; no control over OS/environment |
Ready to test the move on one real project? iRender rents the whole machine by the hour, so you install your own Lumion, Enscape, Twinmotion, D5 or V-Ray with your own licence and plugins, and the environment matches the one you already work in. A free trial covers a first test render, and new accounts get a 100% bonus on the first deposit made within 24 hours of registration.
FAQs
- Can I use a render farm with Lumion or Enscape?
No, automated upload farms cannot run them. Lumion, Enscape, Twinmotion, and D5 Render are single-GPU, real-time apps that need an interactive screen session. You must rent a full machine (IaaS) where you install software and use your own license. Offline engines like V-Ray work on both models, while Corona works best on CPU-only farms.
2. Do I need to buy new licenses to render in the cloud?
Usually no. On rented machines, you install software using your existing licenses. The limit is the number of concurrent seats, not the number of computers installed. If you have a fixed-seat license, deactivate it on your office workstation before opening it on the remote server.
3. Why do my textures disappear when I open the project on a cloud machine?
This happens when your project uses absolute file paths trỏ to your local drive or when asset libraries are left behind. Use your software’s built-in packaging tool to bundle all textures, proxies, and HDRIs, then switch to relative paths before uploading.
4. Is cloud rendering actually cheaper than buying a workstation?
It depends on your workload. For project-based or peak rendering, hourly cloud rental saves money on initial hardware, power, cooling, and maintenance. However, if your studio renders heavy scenes every single day, buying local workstations may be more cost-effective over time.
5. How long does the first upload take?
The initial upload takes the longest because 3D scenes, detailed interior libraries, and HDRI files are large. Future uploads are much faster because you only sync the modified files. Plan extra time for the first upload on a non-urgent project.
See more: Why Real-Time Arch-Viz Tools Still Need a Render Farm in 2026
