As an Amazon Associate, SpecPicks earns from qualifying purchases. See the review methodology.
Quick Answer
Yes — a Raspberry Pi 4 hosts a Foundry VTT world for a typical 4-6 player table without trouble, provided you buy the 8GB board and boot it from a USB 3.0 SSD instead of microSD. The Pi 4's LPDDR4-3200 memory tops out at 8GB per Raspberry Pi's specifications, and that ceiling — not CPU — is what decides how many modules your world can carry.
By Mike Perry · Published September 4, 2026 · Last verified September 4, 2026 · 15 min read
The usual setup is that the DM's laptop hosts the world, which works until the lid closes, the machine sleeps, or Windows decides that 9:40pm on a Tuesday is an excellent time to reboot for updates. Everyone reconnects, the DM re-shares the map, and ten minutes of the session are gone. This happens often enough that "should I get a dedicated box for this" is a question most long-running groups eventually ask.
The two answers people reach for are opposite in every dimension. One is a single-board computer that draws single-digit watts, costs about as much as two months of a streaming bundle, and lives on a shelf behind the router forever. The other is the desktop already in the closet — an Intel Core i7-9700K build from 2019 that got replaced but still boots fine, with eight real cores and a 4.9 GHz turbo ceiling (Intel) that dwarf anything a Pi can do.
The instinct is that the faster machine must be better. For this specific workload, it mostly is not, and the reason is that a VTT server is not a compute problem. It is a memory-residency and file-serving problem with a very spiky access pattern: nothing happens for ten minutes, then a DM reveals a scene and 40 MB of map assets have to reach six clients at once.
This piece is about where that line actually falls, what the real upgrade is (it is storage, not silicon), and the one cost that quietly reverses the answer if you run the machine continuously for a year.
Key takeaways
- The 8GB Pi 4 is the right board; 4GB works for a bare world and runs out of headroom the moment you add a module stack.
- Storage, not CPU, is the upgrade that matters — microSD is the dominant long-term failure mode on always-on Pi hosts.
- The i7-9700K's 8 cores and 4.9 GHz turbo are almost entirely irrelevant to this workload.
- Idle power draw is the difference between single-digit watts and an order of magnitude more, every hour, all year.
- A Ryzen 7 5800X box only makes sense if it is also your gaming machine or media server.
Step 0: what actually loads a VTT server
Before comparing hardware, be clear on what the server process does during a session, because almost everyone budgets for the wrong resource.
The server holds the world state in memory, serves static assets over HTTP, and relays small state updates over a websocket. Token movement, chat, dice rolls, initiative changes — these are tiny messages, a few hundred bytes each, dozens per minute at a busy table. No amount of CPU makes them faster because they are not CPU-bound.
What is heavy: the moment you activate a scene, every connected client requests the map image, the tile artwork, the ambient audio, and any lighting or wall data attached to it. A high-resolution battle map can be 10-40 MB on its own; a scene with layered tiles can multiply that. Six clients pulling it simultaneously is the peak load of the entire session, and it is dominated by disk read speed and upstream network throughput.
What is persistent: module count and world size determine the resident memory footprint. This is the number that decides whether a board is adequate, and it scales with what you have installed, not with how many people are connected. A stripped world with three modules and a 40-player-hour campaign log is a fundamentally different memory profile from a world running two dozen automation modules.
So the thresholds that matter, in order: resident memory (module stack), disk read (asset delivery), upstream bandwidth (asset delivery to N clients), and only then CPU. Player count barely registers until you get past roughly a dozen simultaneous connections, which no home table has.
What does Foundry VTT actually require?
Foundry publishes its own installation documentation covering the Node.js application server, the dedicated-server install path, and the platform builds (Foundry VTT) — read it before you buy anything, because the install method you choose determines whether ARM64 is even on the table for you.
The important structural facts, none of which are invented numbers:
- It is a Node.js application. It runs anywhere Node runs, including ARM64 Linux on a Raspberry Pi.
- It self-hosts by design. The licence is per-user, not per-server, and running your own instance is a first-class supported path rather than a workaround.
- Assets are served from local disk. Your world directory grows with every map, token and audio file you add, and it is served straight off the filesystem.
- The application is single-instance per world. There is no clustering to spread across cores, which is the technical reason an 8-core CPU buys you nothing here.
That last point deserves emphasis, because it is the crux of the whole comparison. If the workload could use eight cores, the 9700K would win outright. It cannot, so the comparison collapses to memory, storage and power.
Spec delta: Pi 4 8GB versus an i7-9700K desktop
| Spec | Raspberry Pi 4 Model B (8GB) | Intel Core i7-9700K desktop |
|---|---|---|
| Cores / threads | 4 cores / 4 threads (Cortex-A72) | 8 cores / 8 threads |
| Clock | 1.5 GHz base | 3.6 GHz base, up to 4.9 GHz turbo |
| Memory | LPDDR4-3200, 8 GB maximum | DDR4, typically 16-64 GB |
| Storage interface | microSD, or USB 3.0 to SATA/NVMe | Native SATA and NVMe |
| Networking | Gigabit Ethernet, 2× USB 3.0 | Gigabit Ethernet (board-dependent) |
| Idle power | Single-digit watts | Tens of watts, more with a discrete GPU |
| Street price | Board only, budget tier | Already owned, or used-market CPU |
Sources for the hardware figures: Raspberry Pi 4 Model B specifications and Intel's Core i7-9700K product page.
Read that table with the Step 0 priorities in mind. The 9700K wins every CPU row by a wide margin and none of those rows are the bottleneck. It wins the memory row, which is a bottleneck — that is the strongest real argument for the desktop. The Pi wins the power row by roughly an order of magnitude, and that row compounds 8,760 hours a year.
Where the resource pressure actually lands
The table below describes the shape of the load rather than lab results — these are the patterns groups report publicly and the ones you should size for. Treat them as a planning model, not as first-party measurements; we did not run a controlled test bench for this piece.
| Session state | Dominant resource | What fails first if you undersize |
|---|---|---|
| Idle, world loaded, nobody connected | Resident memory | 4GB board with a large module stack starts swapping |
| 4-player session, scene already loaded | Websocket relay, negligible CPU | Nothing — this is the easy case on any hardware |
| Scene change, 6 clients pulling assets | Disk read + upstream bandwidth | microSD read speed, then home upload bandwidth |
| Heavy module stack, long campaign log | Resident memory | Out-of-memory kills the Node process mid-session |
The interesting row is the third. Your home connection's upload speed is a hard ceiling that no server upgrade touches. If six clients each need 30 MB of new scene assets and your upload is modest, the wall time to load that scene is set by your ISP, and a faster host changes nothing. The mitigation is asset discipline — compress maps, prefer WebP, do not ship 8K PNGs — not hardware.
Which one wins for a 4-player table?
The Raspberry Pi 4 Model B is the pick for a standard weekly table, with three conditions attached.
Buy the 8GB variant. This matters enough to repeat, because the listings are confusing — the widely-stocked kits are frequently the 4GB board, and the memory size is the one spec you cannot change later. 8GB is not about player count; it is headroom for the module stack, the OS page cache doing asset caching for you, and whatever second service you inevitably add.
Add active cooling. A Pi hosting a session runs a sustained workload for four to five hours. Passive cooling in a closed case will throttle, and a throttled Pi serving assets is exactly the "why is the map taking so long" complaint you bought the machine to avoid. A small heatsink-and-fan case solves it permanently for under $20.
Boot from USB 3.0, not microSD. Covered in detail below, but the summary is that the Pi 4's USB 3.0 ports are the difference between a host that lasts years and one that corrupts a world file at some point in month eight.
Configured that way, it disappears behind the router and does its job. The DM closes their laptop, the world stays up, and the session starts on time — which is the entire point of the exercise.
When the old desktop wins instead
The Intel Core i7-9700K box wins in three concrete cases.
You already own it and it is otherwise idle. The acquisition cost is zero, the memory ceiling is four to eight times higher, and the storage is native SATA or NVMe with no USB adapter in the path. If your world is enormous, your module list is long, or you want the host to also run a Discord bot, a backup target, and a media server, the desktop absorbs all of that without thinking about it.
You need x86 specifically. Some tooling around VTT hosting — certain automation scripts, some containerized helper services — has better x86 support than ARM64. If your stack includes something that only ships x86 binaries, the decision is made for you.
You want zero adapter complexity. The Pi's USB-to-SATA path is reliable with a good enclosure and flaky with a cheap one. A desktop has none of that surface area.
The counter-case is electricity, and it is not a rounding error. An always-on machine runs 8,760 hours a year. A Pi in the single-digit-watt range costs a few dollars annually at typical US residential rates. A 9700K desktop idling an order of magnitude higher — more if a discrete GPU is still installed — costs meaningfully more every year, indefinitely, to do a job the Pi already does. Pull the GPU if the box is headless; that is the single largest idle-power reduction available to you.
We compared these two chips directly for a heavier hosting workload in Ryzen 7 5800X vs Core i7-9700K for a 24/7 Game Server, and the same power-versus-capability tension shows up there.
Storage is the upgrade that actually matters
If you take one thing from this article: do not run an always-on Foundry host from microSD.
A VTT host writes continuously — session logs, world saves after every state change, module updates, backups. Consumer microSD cards are specified for a finite write endurance and have no meaningful wear-reporting, so the failure is not gradual and visible, it is sudden and total, usually noticed when a world file will not load an hour before a session.
The fix is a SATA SSD in a USB 3.0 enclosure as the Pi's boot device. Two picks depending on which machine you are building:
For the Pi's USB 3.0 boot path: the Kingston A400 960GB. Rated up to 500 MB/s read on SATA 3, which is far past what USB 3.0 on a Pi will deliver anyway — the point is not peak throughput, it is having real wear-levelling and a controller designed for sustained writes. 960GB is more than any single world needs, which is exactly why it is the right size: it leaves room for versioned backups on the same drive.
For the desktop: the Crucial BX500 1TB. Same argument, native SATA, rated up to 540 MB/s read, and a terabyte of headroom for an asset library that will grow faster than you expect once you start collecting map packs.
Sizing guidance: budget 20-40 GB for a single actively-played world with a normal asset library, and multiply by however many campaigns you keep on disk. Then double it, because you want at least two full generations of backup on the same machine plus one off it. Both of these drives are cheap enough that buying twice the capacity you calculated is the correct call.
If you want the full storage-tier comparison for a Pi host, we broke it down in Best Storage for a Raspberry Pi 4 Home Server.
What if the host doubles as a game and Discord box?
Then the calculus changes, and the AMD Ryzen 7 5800X becomes worth discussing — 8 cores and 16 threads on AM4, with enough single-thread performance to game on and enough total throughput to run a stack of always-on services underneath.
The honest framing: this is not a VTT recommendation. Foundry will not saturate two of those sixteen threads at any table size a human group can sustain. It is a consolidation recommendation. If you were going to build or already own a 5800X machine that is your gaming PC, and you are willing to leave it powered on, then adding a VTT server to it costs you essentially nothing in performance and saves you an entire second device.
Not worth it if: you are buying the 5800X for this. At that point you have spent several times the Pi's cost, committed to a much higher idle draw, and coupled your game server's uptime to a machine that reboots for GPU driver updates — reintroducing the exact failure mode that started this whole discussion.
What you'll need
- An 8GB Raspberry Pi 4 Model B (verify the memory size on the listing — 4GB boards are common)
- An active-cooling case with a fan, not a passive aluminum shell
- A quality USB 3.0 to SATA enclosure and a SATA SSD, for boot and world storage
- A static DHCP lease for the host on your router, so its address never moves
- Either a forwarded port with TLS in front of it, or a reverse tunnel / relay so nothing is exposed directly
- An automated world backup job on a schedule, with at least one copy off the host
- A UPS if your power is unreliable — an unclean shutdown mid-write is the other way world files die
Perf-per-watt and perf-per-dollar
Do this arithmetic before you commit, because it is the number that actually differentiates the options.
Annual cost = average watts × 8,760 hours ÷ 1,000 × your electricity rate per kWh. Look up your rate on your own bill rather than using a national average; US residential rates vary by more than a factor of three between states, and that spread is larger than the difference between the two machines in any other dimension.
Run that formula for a single-digit-watt Pi and for whatever your desktop actually idles at — measure it with a plug meter rather than guessing, because idle draw with a discrete GPU installed is routinely double what people estimate. In most of the US, the Pi's total annual electricity cost lands in the low single-digit dollars while a GPU-equipped desktop idling continuously costs enough per year to buy another Pi. Over a three-year campaign, the "free" desktop stops being free.
The perf-per-dollar side is simpler: both machines deliver an identical experience at a four-to-six-player table, so any money spent on the faster one buys headroom you will not use unless you are consolidating other services onto it.
The most-missed step: backups and update windows
Two failure modes that hardware choice does not address:
No backups until the first loss. Foundry writes world state continuously, which means a corrupted write, a failing drive, or a bad module update can take a campaign with it. Automate a nightly copy of the world directory to a second location, keep at least a week of daily snapshots, and verify a restore once before you need it. A backup you have never restored is a hypothesis.
Updating an hour before session. Module and core updates change behavior, and the time to discover that a favorite automation module broke is not 15 minutes before six people log in. Update on a weekday well away from your session, keep the previous world backup until you have played a full session on the new version, and note which module versions you were on.
The corollary nobody plans for: the person who hosts is a single point of failure too. Document the setup — IP, ports, backup location, restore procedure — somewhere another player can reach it, so a lost weekend does not become a lost campaign.
Bottom line
Buy the 8GB Raspberry Pi 4, put it on a USB 3.0 SSD with active cooling, and give it a static lease behind your router. It costs less than a nice dinner to run for a year, it stays up when the DM's laptop does not, and it will comfortably carry a normal weekly table with a normal module stack.
Use the old i7-9700K box instead if you already own it, your world is unusually large, you need x86 tooling, or you are consolidating several always-on services — and pull the discrete GPU before you leave it running. Only consider a 5800X if the machine is doing several jobs at once and gaming is one of them. In every case, spend the storage money before you spend the CPU money.
Citations and sources
- Foundry VTT — Installation — accessed 2026-09-04
- Raspberry Pi — Raspberry Pi 4 Model B specifications — accessed 2026-09-04
- Intel — Core i7-9700K product specifications — accessed 2026-09-04
This piece is editorial synthesis based on publicly available manufacturer specifications and vendor documentation. No independent first-party benchmarking is reported; the resource-usage table describes load shape for sizing purposes, not measured results.
Related guides
- Best Storage for a Raspberry Pi 4 Home Server: microSD vs SATA SSD vs NVMe
- Self-Hosting Jellyfin on a Raspberry Pi 4 8GB: What It Can Really Do
- Best Hardware for a Home Game Server in 2026
- Ryzen 7 5800X vs Core i7-9700K for a 24/7 Game Server
- Best Budget SSDs for Homelab and Proxmox Boot Drives in 2026
- Kingston A400 960GB vs Crucial BX500 1TB
- Best Low-Power CPU for a Jellyfin Home Server: 5600G vs i7-9700K
- Best SATA SSDs for Reviving an Old PC in 2026
— Mike Perry · Last verified September 4, 2026
