What came back in our ATM10 restore test.

The test setup

On September 11, 2026, we tested the official ATM10 8.1 server distribution with Minecraft 1.21.1 and NeoForge 21.1.249. This was a disposable local world, manually bootstrapped from the publisher’s server ZIP, running in an ARM64 Linux Docker VM. No players were connected.

Java had a 12 GiB heap limit, the container had 13 GiB of total memory and a four-CPU ceiling. Those are test settings, not minimum requirements or a benchmark for a commercial hosting node.

A backed-up settings change

The server reached a healthy state and answered RCON. We confirmed authenticated Minecraft access and the whitelist remained enabled. GolemHost’s node code stopped it, created a complete archive, calculated its SHA-256 checksum, changed PvP, and started it again. We then restored the earlier archive and verified the original setting and a marker file returned.

The first full archive was approximately 1.39 GB. Stopping, archiving and saving the PvP change took 35 seconds before startup began. Restoration through a healthy restart took 116 seconds in that run. A developed world, a different disk or a busy host can take much longer.

Checking progress inside Minecraft

We placed a diamond block at 0, 150, 0 in the disposable world and confirmed it through Minecraft’s own block condition. After snapshotting, we replaced it with gold and confirmed that change. We restored the snapshot, waited for the server and the test chunk to load, and queried the block again. The diamond block was back.

These are destructive test commands: use a disposable world, since they replace the block at the given coordinates. A responsive server can still be loading a particular chunk; wait for that chunk before interpreting a failed block check.

setblock 0 150 0 minecraft:diamond_block replace
execute if block 0 150 0 minecraft:diamond_block
# Take and verify the backup before changing the block.

The next verification gates

This demonstrates local recovery of an actual world block and supported settings on the pinned pack. It does not establish recovery of every kind of modded progress, multiplayer performance or production availability.

Before paid hosting opens, we still need the automated CurseForge installation path, player inventories and team progress checked with real clients, concurrent-world load tests, and a restore from offsite storage onto a replacement node. The public dashboard demo remains a simulation. The paid pilot stays closed until those operational checks and the live service integrations are complete.