Frequently Asked Questions

SolverCloud gives you an on-demand Linux sandbox in the cloud, preloaded for open-source CFD and electromagnetics work. You create a VM, connect to it with a remote desktop or SSH, set up and debug your solver case interactively, and stop the machine when you're done. You pay by the hour for the time it runs — there is nothing to install on your own hardware.

SolverCloud is developed and operated by Empirisch Tech GmbH, a company registered in Vienna, Austria (empirischtech.at). It is part of the NumericalAI family of simulation platforms and is hosted at sandbox.numericalai.net.

A sandbox is a machine, not a batch job. You aren't uploading a case and waiting in a queue — you get a full desktop you control, where you can edit files, run the solver from a terminal, watch it fail, fix it, and run it again. That makes it suited to setting up and troubleshooting a case, rather than running a long production job.

The sandbox images are prepared for PyFR (high-order CFD), MFC (multiphase compressible flow), and Palace (computational electromagnetics), with MPI for parallel runs and ParaView and Blender for post-processing. Because you have full root access to the machine, you can also install any other package you need with apt or pip for the lifetime of that VM.

Every sandbox runs Ubuntu 24.04 LTS Desktop on x86_64, with the full GNOME desktop on Xorg. You get an administrator account with sudo rights.

The quickest route is Remote Desktop: xrdp comes preinstalled and listening on port 3389, so the Remote Desktop client built into Windows connects with nothing to install at either end. Enter the VM's public IP, then your admin username and password. You can also connect over SSH, or install NoMachine, X2Go, VNC or Chrome Remote Desktop yourself. The Remote Desktop guide walks through each option.

Open My VMs, find the VM in the list, and click the info icon to open its details. The public IP, admin username and admin password are all there, each with a copy button; the password stays hidden until you click the eye icon. If you left the password blank when creating the VM, a strong one was generated for you and this is where you retrieve it.

No. Ports 22 (SSH) and 3389 (RDP) are reachable on the VM's public IP as soon as it starts, and the host firewall is inactive on a fresh sandbox. If you install a different remote desktop server, such as NoMachine on port 4000, that port is reachable too.

Your admin password is the only thing in front of that open port, and automated scanners find new RDP endpoints within minutes. Use the strong password generated at VM creation rather than replacing it with something memorable, and stop the VM when you aren't using it. If you want the port closed entirely, the Remote Desktop guide shows how to bind xrdp to loopback and reach it through an SSH tunnel instead.

Sizes run from 2 vCPU / 8 GB RAM up to 64 vCPU, in Germany West Central and East US. Current sizes and their hourly rates are shown on the Create VM page, which reads the live pricing catalogue. Pick the region closest to you — latency has a large effect on how a remote desktop feels.

Provisioning usually completes in a few minutes. The VM appears immediately in My VMs with a transitioning status and the page refreshes itself until it reports running. You can watch the full provisioning log from the activity entry for that VM.

Yes. Stopping a VM deallocates the compute but keeps its disk, so your files, installed packages and configuration are all still there when you start it again. Deleting a VM destroys the disk permanently — copy anything you want to keep off the machine first.

There is no fixed limit; you can run as many as your remaining credits support. Each running VM bills independently, so the practical limit is your budget.

By the hour, against prepaid credits, for as long as a VM exists. A running VM is charged its compute rate plus a small storage surcharge; a stopped VM is charged the storage surcharge only. Billing ends when you delete the VM. Your dashboard shows credits remaining and your current hourly burn rate across the whole fleet.

Because your remaining credit reached about €1. We stop running VMs at that point rather than letting them burn through the last of your balance, so that you keep your disks and have a window to top up. Add credits and you can start them again yourself — we do not restart them for you. If you do not top up, the stopped VMs consume the remainder and are deleted when the balance reaches zero.

There is no fixed period. Stopped VMs keep consuming the last of your credit at the reduced storage rate, so the window depends on how many VMs you hold and how large their disks are — more VMs means the remaining €1 runs out faster. Treat the automatic stop as a final prompt to act, not as a grace period you can plan around.

Yes — a smaller amount, but not nothing. Stopping releases the compute but retains the disk and the reserved public IP, and those carry an hourly surcharge. This catches people out, so if you have finished with a sandbox, delete it rather than leaving it stopped indefinitely — and be aware that a stopped VM is deleted along with every other VM on your account the moment your credits reach zero.

Two things happen. When you have about €1 of credit left, your running VMs are stopped automatically — this releases the compute and slows the burn right down, so your data is still there and a top-up brings everything back. We also email you warnings along the way. But a stopped VM still costs a little, so if you do not top up, that last €1 drains and the balance hits zero. At that point all of your VMs are deleted — running and stopped alike — along with their disks and everything on them. That deletion is permanent: nothing is archived, and topping up afterwards does not bring a deleted VM back. The reason is that a VM costs money for as long as it exists, even stopped, because it still holds a disk and a reserved public IP that our hosting provider charges for hourly; we cannot keep those resources open on an account with no balance. Keep an eye on the runway estimate on your dashboard, which divides your remaining credits by your current burn rate, and top up before it gets close to zero.

Act on the low-credit warning emails — they exist precisely so you can top up before anything is deleted. Beyond that: copy anything important off the VM (scp, rsync or your preferred transfer tool) as you go, watch the dashboard runway estimate, and delete VMs you have finished with so they stop burning credits in the first place. We keep no backup of a VM's disk and cannot restore one after deletion, so your own copies are the only safety net. Make sure the email address on your account is one you actually read.

Yes. Credit hours are valid for 12 months from purchase. If unused credits expire and that leaves your balance at zero, it has the same effect as consuming them all: every VM on your account is deleted automatically. You receive expiry reminders by email beforehand, but treat the expiry date shown in your account as the authoritative one.

Go to the Settings page and open 'Manage Billing' to view and download your invoices.

If you are registered as a business customer, you can reclaim VAT by providing your company name, address, and valid VAT ID through the contact form on the Settings page. Ensure your details are complete and accurate at checkout; we will then issue an invoice with VAT deducted.

The sandboxes are CPU machines, sized for setting up, testing and debugging a case rather than running it at full scale. Once your case runs cleanly, take it to the GPU platform built for your solver — SRS for PyFR, CMF for MFC, or CEM for Palace. Links to all three are on your dashboard.

Copy the working case off the VM with scp or your preferred file transfer tool, then submit it on the relevant GPU platform. Because the sandbox runs the same solver builds, a case that runs clean here should need little or no change.

Your sandbox is a private, single-tenant machine and its disk is not shared with other customers. Treat it as scratch space regardless: keep the authoritative copy of your work somewhere you control, and don't store credentials for other systems on it. Full details are in the Privacy Policy.

From the Settings page, under Delete Account. You type your own email address to confirm — it must match the account you are signed in to. Because an account that still owns VMs cannot be removed until those machines are released, deletion runs in two stages: every VM on your account is deleted first, then the account itself. Tearing down a VM takes a few minutes and you see the progress of each machine while it runs, so leave the window open until it finishes.

Every VM on the account and everything stored on its disk, your user profile and account information, your job history and provisioning logs, and any credits still on the account — those are forfeited and cannot be refunded or transferred. The one exception is billing data: invoices and payment records are kept for seven years after your last purchase because Austrian tax law requires it, and are used for nothing else. Copy anything you want to keep off your VMs first; we hold no backup and nothing can be restored afterwards.

Your VMs are still deleted — that continues on our side — but your account is not removed. Sign in again and repeat the request to finish it. Repeating it is safe: it picks up the teardown already running rather than starting a second one.

Use the Contact Us form on the Settings page. Our support team typically responds within 24 hours on business days.