All the Mods server: ATM10 and ATM9 setup

An All the Mods server is a big modded server with a few specific habits. ATM10 runs on NeoForge for Minecraft 1.21.1 with Java 21 and well over 400 mods; ATM9 runs on Forge for 1.20.1 with Java 17 or newer. Both ship a server files zip on the pack's CurseForge page with a start script that installs the loader on first run, and a user_jvm_args.txt that sets memory - the ATM10 server files set -Xmx8G. That is the realistic minimum: plan for 8 GB for a few players and 10 to 12 GB for a busy group, expect the first start to take several minutes and later starts two or three, and budget most of your effort for the things that make big packs lag over time - force-loaded chunks, automated factories, and terrain generated on the fly.

The general modded-server material - Java versions, reading crash reports, client-only mods - is in running a modded server without the crashes. This guide covers what is specific to running an ATM pack.

Which pack, and what it needs#

The All the Mods team publishes several packs. The ones people usually mean:

The exact loader version is pinned by each pack release. Use the one the server files install; do not "upgrade" NeoForge or Forge independently of the pack.

The pack is large in every dimension: hundreds of mods, more than a gigabyte of server files, and a world that grows fast because the pack adds dimensions, structures and ore generation. Disk space matters more than on vanilla - see the table below.

Getting the server files onto a server#

On the pack's CurseForge page, each release has a separate server files download (look under the file's additional files, typically named something like ServerFiles-<version>.zip). Do not try to build a server from the client pack: the server files have client-only mods removed and the start scripts included.

1. Download the server files for exactly the pack version your players will use.
2. Unzip into the server's root folder. You get mods/, config/, defaultconfigs/, kubejs/ and other folders, plus startserver.sh and startserver.bat, and user_jvm_args.txt.
3. Run startserver.sh. On first run it downloads and installs the loader and its libraries, writes a default server.properties, and starts the server.
4. Accept the EULA if asked (eula=true in eula.txt) and start again.
5. Wait. The first start generates configs and the world and is slow.

$ unzip ServerFiles-<version>.zip -d /srv/atm10$ cd /srv/atm10$ chmod +x startserver.sh$ ./startserver.sh

On a panel, the same steps happen in the file manager and console: upload the zip, unpack it in place, and set the startup variables so the server launches the installed loader rather than a plain server jar. The installed loader writes its own launch arguments file (under libraries/) that the start script uses; NeoForge server setup explains how those files fit together.

Memory, CPU and disk#

The ATM10 server files set -Xms4G -Xmx8G in user_jvm_args.txt, and that is the floor, not the comfortable figure. From running these packs:

The gap between the heap and the container limit is not optional. Java uses memory outside the heap - metaspace for hundreds of mods' classes, thread stacks, direct buffers - and on a pack this size that overhead is a gigabyte or two. A server with -Xmx equal to its container limit is killed from outside with no crash report, usually during chunk generation. How much RAM a Minecraft server needs explains the arithmetic, and JVM flags covers the garbage collector side.

On RE:NODE plans, that means the 10 GB tier for a small group with an 8 GB heap, and the 14 GB tier for a busy server with a 12 GB heap. CPU scales with the tier, which matters as much as memory here - a big pack is limited by single-thread tick speed long before it runs out of heap.

Disk:

• Server files: 1.3 GB or so unpacked, more after first start creates libraries.
• World: a few GB for a well-explored mature world; much more if players fly around generating terrain in every dimension.
• Backups: multiply the world by the number you keep.

Twenty gigabytes is tight for a long-lived ATM server; plan more.

Startup time and the watchdog#

A big pack loads every mod, every recipe and every registry before the world opens. Several minutes on first start and two or three on later starts is normal on good hardware.

Two settings in server.properties matter for big packs:

max-tick-time=180000allow-flight=true

max-tick-time is the vanilla watchdog: if a single tick takes longer than this many milliseconds, the server kills itself and writes a thread dump. The default 60000 (one minute) is usually fine during play but can trip during heavy world generation or a large teleport on a big pack. Raising it to three minutes gives slow operations room; setting -1 disables the watchdog completely, which means a truly hung server hangs forever. ATM packs may also include a mod-level watchdog setting in their configs.

allow-flight=true stops vanilla kicking players for "flying", which jetpacks, flight rings and creative-flight items trigger constantly. Every modded server needs it. server.properties explained has the rest of the file.

Chunk loading and why ATM servers slow down over time#

A new ATM world runs well. Six weeks later the same server with the same players lags. The reason is almost always chunk loading.

ATM packs include chunk claiming and loading, usually through FTB Chunks and FTB Teams. Players claim their base and force-load it so their machines run while they are offline. Every force-loaded chunk ticks forever - every machine, every farm, every pipe network - whether anyone is online or not. Twenty players, each force-loading a base of nine chunks full of machines, is a server permanently running twenty factories.

What to do:

• Set a per-player force-load limit in the FTB Chunks server config - small numbers, like four to nine chunks per player, are normal on busy servers.
• Review force-loaded chunks periodically. Players who left still have bases ticking.
• Ask builders to keep machines compact. A base spread over forty chunks cannot be force-loaded affordably.
• Prefer offline-tolerant designs. A lot of machines can run while players are online and catch up on demand instead of ticking all night.

The other slow-growth cost is the content of those chunks. The heavy hitters in a mature ATM world are large automated setups: AE2 networks with many crafting CPUs and interfaces, Mekanism factories and digital miners, mob farms with grinding mods, and item pipes moving large volumes. All of them are legitimate, all of them cost ticks, and all of them belong in a spark profile before they belong in an argument. Reading a spark report works the same on NeoForge; spark is often already in the pack.

Pre-generating the world#

Terrain generation is the most expensive thing a modded server does, and ATM packs generate a lot: extra ores, modded structures, several extra dimensions. Players exploring on elytra or jetpacks generate chunks faster than the server can comfortably handle, and the whole server stutters while they do.

Pre-generation moves that cost to a time when nobody is playing. Chunky has NeoForge and Forge builds and is often already included; if not, add it to the server only (it is server-side).

/chunky world minecraft:overworld/chunky center 0 0/chunky radius 5000/chunky start

A 5,000-block radius on a big pack takes many hours. Run it overnight with nobody online, set a world border to match, and repeat for the Nether and any dimension players spend time in. World borders and pre-generation covers how long it takes and how big the files get.

Leave mining dimensions that are meant to be reset ungenerated; they are temporary by design.

Updating the pack without losing the world#

ATM packs update often, and updates are mostly mod updates and config changes, not new worlds. A safe procedure:

1. Read the changelog. Look for removed mods - blocks from a removed mod vanish from the world - and for notes that say a config folder must be replaced.
2. Stop the server cleanly and take a full backup.
3. From the new server files, replace mods/, config/, defaultconfigs/, kubejs/ and any other pack folders the release notes mention. Delete the old mods/ first; do not copy over it, or removed and renamed jars stay behind.
4. Keep world/, server.properties, ops.json, whitelist.json, banned-players.json and your own user_jvm_args.txt memory settings.
5. If the loader version changed, run the start script so it installs the new loader.
6. Start, watch the log, join, and check the main bases before telling players.

If you changed pack configs yourself, keep a list. Replacing config/ wipes your changes; the list is how you put them back. What to do when a mod update breaks is the recovery plan.

Errors ATM servers actually hit#

The server stops during the first start with no error. The log ends mid-line and there is no crash report. That is almost always the process being killed from outside for exceeding its memory limit, because -Xmx was set to the whole plan. Lower the heap so there is headroom.

"Mod rejections" or a list of missing mods when players join. The client and server are on different pack versions, or a player added a mod that also needs to be on the server. Compare versions first; most cases are a launcher that auto-updated the client before the server was updated.

The server crashes when a player enters a particular area. A block entity in that chunk is crashing on tick. The crash report names the block and coordinates. Some packs include a setting to remove erroring block entities instead of crashing; otherwise, restore the region from a backup or remove the block with an editor. Chunk errors and world corruption covers the tools.

`Can't keep up!` warnings during exploration. Chunk generation is falling behind. Pre-generate, lower view distance, and limit how fast players can travel through new terrain.

Startup hangs at the same mod every time. A config file for that mod is corrupted or from a different version. Move that mod's config out of config/ and let it regenerate. Crash reports explained shows how to read where it stopped.

On RE:NODE the Minecraft line ships Paper, so an ATM server is your own install: there is no one-click modpack installer and nothing on the panel reads a CurseForge pack. What helps is that the file manager unpacks the server files zip in place, the console shows the long first start unfiltered, and backup slots on every plan restore with a button. If the server reaches its memory limit it is stopped and restarted clean rather than left to swap - which is why the heap must leave room below the plan.

FAQ#

How much RAM does an All the Mods 10 server need?

At least 8 GB of heap, which is what the server files set, inside a plan with a gigabyte or two more than that. For more than a handful of players or a mature world, a 10 to 12 GB heap is more comfortable.

Why does my ATM server take so long to start?

It loads hundreds of mods, every recipe and every registry before opening the world. Several minutes on the first start and two or three afterwards is normal. A start that takes much longer than usual is often a mod stuck on a network check or a corrupted config; the log shows where it stopped.

Can I add mods to an All the Mods server?

Yes, as long as players add the same mods for anything with blocks, items or entities. Server-only mods such as Chunky need nothing on the client. Adding mods means your server no longer matches the stock pack, so keep a list for updates.

Why does my server get slower every week?

Usually force-loaded chunks and growing factories. Every claimed and force-loaded base ticks all the time. Limit force-loading per player, review old claims, and profile with spark to find the factory doing the most work.

Do I need to pre-generate the world?

Strongly recommended. Terrain generation on a large pack is expensive and causes stutter for everyone while players explore. Pre-generate a few thousand blocks around spawn overnight and set a world border to match.