Vault Hunters 3rd Edition (VH3) is not a casual modpack. Version 3.21.7 lists 168 mods in its manifest, Create and Sophisticated Backpacks among them, and they all compete for CPU time while a Vault dimension loads. It runs on Forge 40.3.11 for Minecraft 1.18.2, with Java 17. Most hosts will struggle with it. Here is how to set up and run it correctly.
Minimum vs. Recommended Hardware
| Spec | Bare Minimum | Recommended (Space-Node) |
|---|---|---|
| CPU | 4 cores @ 3.5 GHz | Ryzen 9 9950X (5.7 GHz boost) |
| RAM | 10 GB | 14 to 16 GB |
| Storage | SSD | NVMe SSD |
| Network | 100 Mbps | 1 Gbps |
Vault dimensions are generated and saved all the time, so VH3 leans hard on disk I/O. Run it on an SSD, ideally NVMe.
JVM Arguments for VH3
VH3 runs on Java 17, which is what the pack's own setup script (vh-setup-unix.sh) asks for. If your server starts through Forge's run.sh or that setup script, put the JVM arguments in user_jvm_args.txt, one per line, as below. Otherwise set them in the Startup tab of the panel.
-Xmx14G
-Xms14G
-XX:+UseZGC
-XX:+AlwaysPreTouch
-XX:+DisableExplicitGC
-Dforge.readTimeout=240
Leave out -XX:+ZGenerational. Generational ZGC arrived in Java 21, and Java 17 refuses to start with that flag. Plain ZGC works on Java 17.
-Dforge.readTimeout=240 raises Forge's server-side network read timeout from its default of 30 seconds to 240. Forge 1.18.2 reads forge.readTimeout; the older fml.readTimeout name does nothing on this version. VH3's vault dimension generation is slow, and the longer timeout gives connections more slack while it runs.
Server Configuration for VH3
In server.properties:
simulation-distance=5
view-distance=8
max-tick-time=120000
difficulty=normal
max-tick-time=120000 prevents the server from crashing when vault dimension initialisation takes longer than the default 60-second watchdog timeout. This does not remove the safety check. It gives VH3's slow dimension loading more time before the watchdog steps in.
Expected Player Count Limitations
VH3 is fundamentally designed for small groups:
- 1 to 5 players: Smooth and stable with 10 to 12 GB RAM
- 5 to 10 players: Requires 14 to 16 GB; vault runs should be staggered
- 10+ players: Only on dedicated hardware; simultaneous vault runs will cause severe lag
The vault dimension loading sequence is CPU-bound on the main thread. When two players enter different vaults simultaneously on the same server, the load compounds multiplicatively. Server-side rules about one vault open at a time dramatically improve quality of life.
Common VH3-Specific Issues
Vault crash on entry: Usually RAM exhaustion. Increase to 14 GB and set -XX:+AlwaysPreTouch.
World save lag: VH3 vault worlds are large, and every autosave writes them to disk. On a SATA SSD an autosave can pause the whole server for a moment; on NVMe the pause is much shorter.
Space-Node's Minecraft plans include NVMe storage and AMD Ryzen 9 CPUs. If a vault crash keeps coming back, send the newest file from the crash-reports folder to our support in live chat (08:00 to 20:00 UTC).