Minecraft hosting benchmarks: measured JetRift results

By JetRift · Measured 3 November 2026

Our retained production sample contains 98 successful wakes with a 3.37-second median from start request to the gateway’s running state. In a separate isolated test, the deployed engine handled four and eight simulated Java players without failed joins, kicks or unexpected drops.

Measured 3 November 2026. These are our own measurements, published by JetRift. The production aggregate and the local engine test measure different things. This is not a comparison with other hosts, a maximum-player claim or an uptime guarantee.

Production wake time

The gateway records elapsed time from a start request until a server reaches its running state. We read the retained sample at 19:37 UTC on 3 November 2026. It is a rolling buffer of up to 500 successful wakes, not a dated cohort: these records do not retain individual event timestamps. Failed wakes and their durations are not included. Percentiles use the nearest-rank method; the anonymous successful durations are included in the JSON.

This includes orchestration work that a standalone engine timer misses. It does not measure your game’s download, authentication or full join-to-play time, and it cannot establish a startup success rate. The service runs on ARM64 hardware; the laptop test below is a separate environment.

Isolated real-engine test

RSS is the engine process’s resident memory, not a hosting reservation, total container memory or a full-stack total. TPS is the engine-reported tick rate sampled about every five seconds, with a target of 20. Median RSS and TPS use samples after the first 15 seconds of each phase with the expected player count: 3 idle samples and 16 samples in each player phase. Peak RSS includes every collected sample in that phase; a five-second sampler can miss brief peaks.

All four bots joined in the four-player phase and all eight joined in the eight-player phase. Both phases reported zero failed joins, kicks and unexpected drops. The final connected count in the raw bot report is zero because bots disconnect intentionally at the end of their timed run.

Hardware, settings and workload

• Host: Apple M5 laptop, 24 GiB physical memory; Colima ARM64 Linux VM with 8 virtual CPUs and about 11.7 GiB RAM. Other host work could run concurrently.
• Container limits: 2 CPUs, 3 GiB memory, no swap beyond that limit, 256 processes. No published ports or external network; all bots connect on loopback.
• Engine: Butternut 0.2.0+26.3-26.60, copied from the deployed runtime. Engine SHA-256: d8468580499d3d95f72f5c9df790756be427cfed4ea814f73fcb651289a10e45.
• World: fresh seed 42, Creative, Peaceful, view distance 8, simulation distance 6, plugins disabled, Bedrock disabled for this Java workload.
• Phases: 30 seconds idle, 90 seconds with four bots, then 90 seconds with eight. Bots join 400 ms apart and choose movement, turning, mining, chat or flying behaviors in a 28-block radius. The same world continues between phases.

Three separate fresh-world launches reported engine startup times of 596 ms, 586 ms, 652 ms. This is the engine’s own startup log timer. It excludes container launch, gateway orchestration, authentication and a player receiving the world. It is not an end-to-end wake number.

What this test does not establish

These are short synthetic workloads on one seed and one engine binary, not hours of human survival play. They do not cover large farms, mob-heavy survival, exploration across new terrain, plugins, multiple busy worlds, backups under load, Bedrock packet performance or internet latency. The idle engine has not generated the same player-visible chunks as a populated world.

The eight-player phase reuses chunks and edits from the four-player phase, so its memory or tick timing should not be interpreted as an independent scaling comparison. No customer worlds were used or stressed. Results can change with hardware, world contents, software updates and shared capacity. Check compatibility and limits before choosing a host.

The raw startup log also records an initial level.dat save error on a fresh world and a blocked Bedrock key-discovery request in the network-isolated container. The Java server continued and accepted the test clients. This benchmark does not validate world persistence or Bedrock authentication; those diagnostics are retained in the evidence rather than counted as successful checks.

Download the evidence and reproduce it

Raw samples, configuration, hashes and production aggregate (JSON) · Reproduction script (Python)

The script requires Docker, a compatible Linux Butternut binary and the JetRift swarm binary built from our source. Put the binaries and output in a directory shared with Docker. It creates temporary worlds and removes its uniquely named test containers when finished; it does not connect to the production service.

python3 resource_benchmark.py \
  --engine /path/to/butternut \
  --swarm /path/to/swarm \
  --output /path/shared/with/docker/results.json

The JSON includes the exact container image ID, engine and swarm hashes, complete server configuration and sample selection inputs. The harness uses the rust:1-bookworm image tag; to match this run, use the recorded image ID in the script and the recorded binaries. A different binary or image is a new measurement.

How sleeping and waking works · Choose hosting for your group · All guides