Hosting

Server Setup

Want to host Thunder for your group? Here is how to get a server running without making a meal of it. Give the server at least 8 GB of memory, whichever route you take.

Panel hosting

Use the published pterodactyl.json egg, keep the packwiz URL in place, and switch Auto Update on if you want the server to follow the published pack.

Standalone Linux

If you have curl, the Linux installer gets you most of the way there in one command and can fetch a local Temurin 21 runtime if Java is missing.

Standalone Windows

Run the PowerShell installer in an empty folder and it will even fetch Temurin 21 for you if Java is missing.

The short version

The scripts do the boring bits for you

The official install and startup scripts fetch Forge, pull in packwiz-installer-bootstrap, and keep the server aligned with the published metadata. That means far less manual copying and far fewer "which mods do I need?" headaches.

Pterodactyl and Pelican

Import the egg and let it get on with it

Import the egg

Download pterodactyl.json from the latest stable Thunder release and import it through your panel.

Create the server

Pick Java 21, keep the supplied packwiz URL, and allocate at least 8 GB of panel memory, with more if you expect a busy server. The startup script will derive a heap from that automatically unless you fill in Exact JVM Memory.

Start it

The egg installs Forge and does the first pack sync. After that, startup leaves your mod set alone unless you switch Auto Update on.

Standalone Linux

Bootstrap a server with one command

You need curl and a normal Linux userspace with tar and gzip. If Java 17 or 21 is missing, the installer fetches a local Temurin 21 runtime for you.

mkdir thunder-server && cd thunder-server && curl -sSfL -O https://github.com/rooneyj9005/Thunder/releases/latest/download/install.sh -O https://github.com/rooneyj9005/Thunder/releases/latest/download/functions.sh && bash install.sh

Accept the EULA with echo eula=true > eula.txt, then start the server with bash startup.sh. Left to itself the heap takes 75 per cent of whatever memory the script finds, and claims it at startup rather than creeping up on it over hours, so on a machine you share with anything else say what the server gets: bash startup.sh --memory 8192 sizes the heap from a total allocation and holds back what the JVM needs outside it, while bash startup.sh --jvm-memory 7168 pins the heap exactly.

Standalone Windows

Run the PowerShell installer in an empty folder

If Java 17 or 21 is missing, the script downloads Temurin 21 automatically before installing the rest of the server.

Invoke-WebRequest -Uri https://github.com/rooneyj9005/Thunder/releases/latest/download/install.ps1 -OutFile install.ps1
Invoke-WebRequest -Uri https://github.com/rooneyj9005/Thunder/releases/latest/download/functions.ps1 -OutFile functions.ps1
.\install.ps1
Set-Content -LiteralPath eula.txt -Value "eula=true" -Encoding ASCII
.\startup.ps1

That gives you the same general flow as Linux without needing a separate Java install first. Memory behaves the same way, the same 75 per cent default included: .\startup.ps1 -MemoryMiB 8192 derives a heap from the total server allocation, while .\startup.ps1 -JvmMemoryMiB 7168 pins the heap exactly.

Keeping up to date

Your server updates when you say so

Sync is off by default, so restarting will not change your mod set. No surprises mid-session.

To update once, run the bundled script from the server folder. On Linux that is PACKWIZ_SIDE=server bash tools/update.sh. On Windows it is .\tools\update.ps1 -PackwizSide server.

To sync on every start instead, set PACKWIZ_AUTO_UPDATE=true, or switch Auto Update on in your panel. Players update separately: they download the new .mrpack and use Update from file.

Good to know

Where the metadata lives

The public docs live on thunder.john.rooney.scot, but the packwiz metadata itself is served separately from packwiz.thunder.john.rooney.scot. That split is deliberate. The docs explain things. The packwiz host keeps sync and update tooling pointed at a stable source.

Packwiz behaviour

What it actually manages

Thunder uses exact indexed paths, not folder-wide management.

If a specific path is listed in index.toml, packwiz can restore the pack version of that exact file on sync.
If another file sits next to it but is not indexed, packwiz generally leaves that file alone.
So "this folder contains managed files" is not the same thing as "everything in this folder belongs to the pack".
Two indexed files are only ever written once: servers.dat and config/logbegone.toml. Sync leaves them alone after the first install, so your edits there survive updates.

If you disable updates and customise pack-managed files, you are effectively keeping a local fork. That can be perfectly reasonable, but it stops being the official pack state.