The readiness check
Before a machine goes live, one button on the Platforms tab answers whether it will pass the marketplace’s requirements. The check measures the real hardware against that marketplace’s current thresholds and names what to fix when it will not.
The four verdicts
Section titled “The four verdicts”| Verdict | Meaning |
|---|---|
| Pass | the requirement is met |
| Warn | met, but worse than recommended. Does not block the listing |
| Fail | not met — the marketplace will not accept this machine |
| Unknown | not measured, or nothing can measure it |
Every row also tells you where its number came from: read from what the agent already reported, measured on the host by the check, taken from the marketplace, or confirmed by you.
Why the thresholds are dated
Section titled “Why the thresholds are dated”Marketplaces change their requirements silently and without versioning. Every threshold Flotera checks against carries the date it was last verified against the marketplace’s own documentation, and you can see that date on the row.
An old date means “we do not know whether this is still current” — which is more honest than showing a confident number that quietly went stale.
Host system — the shared floor
Section titled “Host system — the shared floor”These 13 apply to both marketplaces. A failure here blocks every one of them.
Base system
Section titled “Base system”CPU architecture — x86-64. Both marketplaces ship x86-64 container images only. On another architecture nothing a tenant rents would start. Not fixable; it is the hardware.
Operating system — Ubuntu Server LTS. Marketplaces certify hosts on LTS releases only; that is what their driver and runtime testing covers. A desktop edition works but is not what they test against.
Desktop environment — none installed. A graphical session holds video memory and CPU the tenant is paying for, and its display manager can grab the GPU outright.
Fix: systemctl disable --now gdm3 and boot to multi-user.target.
Automatic OS updates — disabled. An unattended upgrade can replace the GPU
driver under a running tenant. The rental dies mid-job and the downtime counts
against you. Turn off unattended-upgrades and update deliberately, between
rentals.
SSH server — listening on 22. Tenants connect over SSH, and so do you when something breaks. A non-standard port is fine; the check looks at 22 because that is the port the marketplaces document.
VRAM and hotspot sensors — BAR0 readable. NVML publishes neither memory nor hotspot temperature; there is no public call for either. They are read straight from the card’s registers, and a hardened kernel blocks that.
Fix, only when the row reports the read denied: add iomem=relaxed to
GRUB_CMDLINE_LINUX in /etc/default/grub, run update-grub, reboot.
GPU and driver
Section titled “GPU and driver”GPU vendor — NVIDIA. Clore takes NVIDIA only, and Vast lists AMD so poorly that in practice nobody rents it.
NVIDIA driver — loaded, current stable branch. Tenants pick images by CUDA version, and the driver decides which of those images can run. An old branch narrows who can rent you. Update between rentals — the reload takes the GPUs away for a moment.
PCIe link width — full width. Vast measures PCIe bandwidth with its own benchmark and publishes the number, where tenants filter on it. A card sitting on 4 lanes instead of 16 is advertised as the slow machine it currently is.
Fix: check the slot, any riser, the lanes shared with M.2 sockets, and bifurcation settings in the BIOS.
Containers
Section titled “Containers”Docker — installed and running. A rental is a container. Without a running daemon the machine can be listed and will fail the first booking.
NVIDIA Container Toolkit — installed. Without it a container starts and sees no GPU. The tenant pays for a card that is not there — the worst way for this to fail, because everything looks healthy.
Marketplace agents on this host — at most one. See one machine, one marketplace.
Public IPv4 — reachable, not behind CGNAT. Tenants open SSH and Jupyter straight to your address. Behind carrier NAT the machine can be listed and never rented. Fix: a dedicated public IPv4 from your ISP, or a VPS with a static address and a tunnel.
Vast.ai requirements
Section titled “Vast.ai requirements”Vast sizes everything per GPU, not per machine. Adding a card raises several thresholds at once.
| Requirement | Threshold |
|---|---|
| Ubuntu version | 18.04 or newer; 22.04 / 24.04 recommended |
| AVX support | required by their listing rules |
| CPU cores | 1 physical core (2 threads) per GPU |
| System RAM | 4 GB per GPU |
| SSD capacity | 128 GB per GPU |
| Identical GPUs | every card the same model |
| VRAM per GPU | 7 GB |
| CUDA | 12.0 to verify; 13 reaches the whole market |
| Open ports | 3 per GPU minimum, 100 recommended |
| Uplink bandwidth | 2.6 Mbps per GiB of VRAM, floor 100, capped at 500 |
The two that catch people out
Section titled “The two that catch people out”Docker filesystem — XFS with pquota. Vast gives each tenant a disk quota,
and quotas are an XFS feature. On ext4 the platform cannot enforce them and
refuses the host. XFS alone is not enough either — without the pquota mount
option the quotas do not apply.
Fix: give /var/lib/docker its own XFS volume, mounted rw,auto,pquota,nofail.
Disk quota enforced. XFS with pquota is necessary but not sufficient.
With the containerd snapshotter enabled, Docker accepts --storage-opt size
without an error and then ignores it — a container told to fit in 10 GB
still sees the whole disk. Nothing looks broken until a tenant fills your
drive.
Fix: remove features.containerd-snapshotter from /etc/docker/daemon.json
so the classic overlay2 driver is used, then restart Docker. Images pulled
under the other snapshotter are invisible after the switch — export what you
need first.
Reading the bandwidth rule
Section titled “Reading the bandwidth rule”The uplink requirement scales with how much VRAM you sell: 2.6 Mbps per GiB, never below 100, never above 500, and symmetric.
A machine with 4 × 24 GB cards sells 96 GiB of VRAM, so it needs 96 × 2.6 ≈ 250 Mbps up and down. Upload matters as much as download — that is what carries a tenant’s results home.
Account rows
Section titled “Account rows”Vast agent and Machine identity are not about your hardware. Their daemon is what actually rents the machine out; until it is installed and has checked in with Vast, everything else is preparation. Both clear themselves once you install the agent from the Platforms tab.
Clore.ai requirements
Section titled “Clore.ai requirements”Clore states its minimums per rig, not per card — their documentation grew out of mining.
| Requirement | Threshold |
|---|---|
| Ubuntu version | 22.04 or newer |
| RAM | 8 GB minimum, 16 GB recommended |
| Disk | 32 GB, SSD rather than a flash drive |
| Bandwidth | 100 / 100 Mbps; their table calls 1 Gbps premium |
| Latency | under 100 ms |
| Inbound ports | 22, 8080, and 3000–4000 reachable from outside |
GPU rules specific to Clore
Section titled “GPU rules specific to Clore”Driver branch — R580 LTSB or R590. Clore qualifies exactly two branches. Use R590 for RTX 50-series and newer. Outside these you are on your own when a tenant’s image will not start.
Kernel against driver. Kernel 6.16 and newer will not build driver branches R550 and older. The pair breaks at boot, not at rental — the machine simply comes back without a GPU. Fix either side: move the driver to R590, or pin an older kernel. It is the combination that fails, not either one alone.
Banned GPU list. Clore refuses certain models outright. Check the model against their published list before buying or listing — if it is there, the machine cannot be used on Clore at all.
Overclock and power limit — factory values. Clore requires stock clocks before connecting. An undervolted or power-limited card benchmarks below its class and gets priced as the weaker card it looks like.
After you fix something
Section titled “After you fix something”Re-run the check. Nothing is inferred from the fix itself — the row changes when the machine is measured again, not when you say you changed it.