A Minecraft Server That Costs 5 Watts
One of the most common questions I see in homelab communities is whether a Raspberry Pi can run a Minecraft server. The honest answer: it depends on which Pi and how many players you expect. A Pi 4 can do it. A Pi 5 can do it properly. Neither will compete with a dedicated x86 machine, but for a small group of friends or a family server, a Pi is a genuinely practical option that runs 24/7 on about 5 watts of power.
I run a stack of Pis across my homelab, mostly Pi 4s plus a Pi 5, for various services. This guide gives you the practical picture for both the Pi 4 and the Pi 5: what works, what does not, and the specific optimisations that make the difference between a playable server and a slideshow.
This is a server administration tutorial. You will install an operating system, configure Java, tune performance parameters, and set up a systemd service. If you are doing this with a young person, that is great. They will learn more about how computers work from this one project than from a year of ICT lessons.
Pi 4 vs Pi 5: Which One Should You Use?
Let me be direct about what each Pi can handle:
Raspberry Pi 4 (4 GB or 8 GB)
- Realistic player count: 2-4 players
- Performance: Playable but not smooth. Expect occasional lag spikes, especially when players explore new chunks or lots of entities are active.
- RAM: The 4 GB model is tight. You can allocate 2 GB to Minecraft, leaving 2 GB for the OS, but it is the minimum. The 8 GB model gives you more breathing room.
- Key limitation: The Cortex-A72 CPU is noticeably slower per-core than the Pi 5. Minecraft’s world ticking is single-threaded, so raw clock speed matters.
Raspberry Pi 5 (4 GB or 8 GB)
- Realistic player count: 5-8 players
- Performance: Genuinely decent. Raspberry Pi rates the Pi 5’s Cortex-A76 CPU at two to three times the performance of the Pi 4’s. This makes a real difference in TPS stability.
- RAM: The 8 GB model is ideal. Allocate 4 GB to Minecraft, keep 4 GB for the OS and disk cache.
- Key advantage: Native PCIe support means you can use an NVMe SSD without USB bottlenecks. This dramatically improves chunk loading.
If you are buying a Pi specifically for this project, get the Pi 5 with 8 GB. The price difference over a Pi 4 is small, and the performance difference is significant. The Pi 4 works, but you will be fighting its limitations from day one. The Pi 5 gives you headroom to actually enjoy the result.
Prerequisites
You will need:
- Raspberry Pi 4 (4 GB+) or Pi 5 (4 GB+)
- A quality power supply (official Pi PSU recommended, under-voltage causes throttling and crashes)
- Storage: An SSD is strongly recommended. More on this below.
- Raspberry Pi OS (64-bit) or Ubuntu Server 26.04 or 24.04 (arm64) installed and updated
- SSH access to the Pi (you will not want a monitor and keyboard attached permanently)
- A wired Ethernet connection (Wi-Fi adds latency and is unreliable for a game server)
The SSD Question: Do Not Skip This
This is the single most impactful upgrade you can make. Minecraft servers are heavily I/O dependent. Every chunk load, every world save, every player interaction that modifies blocks hits the disk. An SD card is orders of magnitude slower than an SSD for random read/write operations.
Pi 5: Use an NVMe SSD via the official Pi 5 M.2 HAT or a compatible base board. The Pi 5 has a native PCIe lane, so you get proper NVMe speeds. Even a small NVMe drive transforms the experience.
Pi 4: Use a USB 3.0 SSD (a SATA SSD in a USB enclosure works well). Boot from it if possible, or at minimum put the Minecraft server files on it. The Pi 4 does not have native PCIe, so USB 3.0 is your best option. Even a USB SSD is dramatically faster than an SD card.
If you insist on running from an SD card, use the fastest one you can find (A2 rated, minimum) and accept that chunk loading will be noticeably slower. You will also wear out the SD card faster due to the constant writes. SSDs handle write endurance vastly better than flash cards. I have killed two SD cards running services that write frequently. An SSD costs a few pounds more and lasts years.
Step 1: Update the System and Install Java 25
SSH into your Pi and update everything first:
sudo apt update && sudo apt upgrade -y
Current Minecraft releases (the 26.x versions) and the Paper builds for them need Java 25. Install it:
sudo apt install -y openjdk-25-jre-headless
Verify:
java -version
You should see OpenJDK 25 in the output. The openjdk-25-jre-headless package is in the standard repositories for Raspberry Pi OS based on Debian 13 (Trixie), Ubuntu 26.04 and Ubuntu 24.04. If you are deliberately running an older Minecraft version, check its Java requirement: the 1.21.x releases need Java 21 (openjdk-21-jre-headless).
Step 2: Create a Dedicated User and Directory
sudo useradd -r -m -d /opt/minecraft -s /bin/bash minecraft
sudo mkdir -p /opt/minecraft/server
sudo chown -R minecraft:minecraft /opt/minecraft
If your SSD is mounted separately (e.g., at /mnt/ssd), put the server there instead:
sudo mkdir -p /mnt/ssd/minecraft/server
sudo ln -s /mnt/ssd/minecraft /opt/minecraft
sudo chown -R minecraft:minecraft /mnt/ssd/minecraft
Step 3: Download PaperMC
Do not use the vanilla Minecraft server on a Pi. PaperMC is essential here. It includes performance optimisations that make a genuine difference on ARM hardware: async chunk loading, better entity management, and reduced memory overhead. The vanilla server is workable on x86 with plenty of RAM but struggles on the Pi’s constrained resources.
Paper’s download API does not accept “LATEST” in a URL, so older one-line download commands now return a 404. Instead, ask the current API (PaperMC’s Fill v3) for the newest stable build of the version you want, then download that:
sudo apt install -y jq
# The server version must match the Minecraft version your players use.
# The current versions are listed at https://papermc.io/downloads/paper
VERSION=26.2
UA="minecraft-pi-setup (you@example.com)" # PaperMC asks for a descriptive User-Agent
URL=$(curl -s -A "$UA" "https://fill.papermc.io/v3/projects/paper/versions/$VERSION/builds" \
| jq -r 'first(.[] | select(.channel == "STABLE")) | .downloads."server:default".url')
echo "$URL"
sudo -u minecraft wget -O /opt/minecraft/server/server.jar "$URL"
If echo prints null or nothing, that version has no stable build yet (brand-new versions start on the beta channel): use the previous version, or wait. At the time of writing (October 2026), 26.2 is the newest version with stable Paper builds.
Step 4: Initial Setup and EULA
Run the server once to generate config files:
sudo -u minecraft bash -c 'cd /opt/minecraft/server && java -Xmx2G -Xms1G -jar server.jar --nogui'
It will exit with an EULA notice. Accept it:
sudo -u minecraft sed -i 's/eula=false/eula=true/' /opt/minecraft/server/eula.txt
Step 5: Optimise server.properties for Pi Hardware
This is where a Pi setup diverges from a standard server. You need to reduce the workload to match the hardware:
sudo -u minecraft tee /opt/minecraft/server/server.properties > /dev/null <<'EOF'
# Server basics
server-port=25565
motd=Pi Minecraft Server
max-players=8
difficulty=normal
gamemode=survival
level-name=world
# Security
white-list=true
enforce-whitelist=true
online-mode=true
enable-command-block=false
# Performance (tuned for Pi)
view-distance=6
simulation-distance=4
max-tick-time=60000
network-compression-threshold=256
entity-broadcast-range-percentage=75
# Misc
enable-rcon=false
spawn-protection=16
EOF
The critical changes from default:
- view-distance=6 (default 10) - Each chunk costs CPU and RAM. Reducing from 10 to 6 cuts the loaded area by roughly 64%. This is the single biggest performance lever.
- simulation-distance=4 (default 8) - Only actively simulate entities within 4 chunks. Massively reduces CPU load.
- entity-broadcast-range-percentage=75 - Reduces the range at which entities are sent to clients. Less network traffic, less rendering overhead.
- max-players=8 - Be honest about what the hardware can handle. You can increase this later if performance allows.
Step 6: Tune PaperMC Configuration
PaperMC generates additional config files after first run. These matter on a Pi:
In config/paper-global.yml, ensure async chunk loading is enabled (it should be by default in modern Paper):
chunk-system:
io-threads: 2
worker-threads: 2
Entity activation ranges live in spigot.yml (Paper reads Spigot’s settings), under world-settings: > default:. Reduce them:
entity-activation-range:
animals: 16
monsters: 24
raiders: 48
misc: 8
water: 8
villagers: 16
flying-monsters: 32
These values tell the server to only run AI/pathfinding for entities within those block ranges of a player. Entities outside these ranges essentially freeze until a player gets close. On a Pi, this saves significant CPU cycles.
In config/paper-world-defaults.yml you can also set tick-rates.mob-spawner to 2 (from default 1) and entities.behavior.disable-chest-cat-detection to true for minor CPU savings. These are small individually, but on constrained hardware, they add up.
Step 7: Allocate RAM
RAM allocation depends on your Pi model:
- Pi 4 (4 GB):
-Xmx2G -Xms1G- Leaves 2 GB for the OS and disk cache. - Pi 4 (8 GB):
-Xmx3G -Xms2G- More comfortable but the CPU is still the bottleneck. - Pi 5 (4 GB):
-Xmx2G -Xms1G- Same constraints as Pi 4 4 GB, but the faster CPU makes better use of it. - Pi 5 (8 GB):
-Xmx4G -Xms2G- The sweet spot. Enough for the server to be comfortable without starving the OS.
Do not allocate more than half the Pi's total RAM to Java. The OS needs memory for disk caching, and on a Pi running from any storage medium, that cache is important for performance. Java's garbage collector also uses memory outside the heap. Over-allocating causes the OOM killer to step in, and it does not care about your world save in progress.
Step 8: Create the systemd Service
Same principle as any server: never run it from a terminal session.
sudo tee /etc/systemd/system/minecraft.service > /dev/null <<'EOF'
[Unit]
Description=Minecraft Server (PaperMC on Raspberry Pi)
After=network.target
Wants=network-online.target
[Service]
User=minecraft
Group=minecraft
WorkingDirectory=/opt/minecraft/server
ExecStart=/usr/bin/java -Xmx4G -Xms2G \
-XX:+UseG1GC \
-XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 \
-XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC \
-XX:G1NewSizePercent=30 \
-XX:G1MaxNewSizePercent=40 \
-XX:G1HeapRegionSize=8M \
-XX:G1ReservePercent=20 \
-XX:G1MixedGCCountTarget=4 \
-XX:InitiatingHeapOccupancyPercent=15 \
-XX:G1MixedGCLiveThresholdPercent=90 \
-XX:G1RSetUpdatingPauseTimePercent=5 \
-XX:SurvivorRatio=32 \
-XX:+PerfDisableSharedMem \
-XX:MaxTenuringThreshold=1 \
-jar server.jar --nogui
ExecStop=/bin/kill -SIGINT $MAINPID
TimeoutStopSec=30
Restart=on-failure
RestartSec=10
StandardInput=null
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
EOF
Adjust the -Xmx and -Xms values for your Pi model (see Step 7 above). The additional JVM flags are Aikar's recommended garbage collection flags, widely used in the Minecraft server community. They tune Java's G1 garbage collector to minimise pause times, which translates directly to fewer lag spikes in-game.
Enable and start:
sudo systemctl daemon-reload
sudo systemctl enable minecraft.service
sudo systemctl start minecraft.service
sudo systemctl status minecraft.service
Step 9: Firewall and Connecting
Open the Minecraft port:
sudo ufw allow 25565/tcp comment 'Minecraft Server'
Connect from Minecraft Java Edition using the Pi's IP address (find it with hostname -I). The server takes longer to start on a Pi than on x86 hardware. Give it 60-90 seconds before trying to connect. Watch the logs to see when it reports "Done":
sudo journalctl -u minecraft.service -f
Realistic Performance Expectations
These are rough expectations, not measured benchmarks: player behaviour, world type and plugins change the picture a lot, so measure your own server with /tps.
- Pi 5 (8 GB, NVMe SSD): The comfortable option for a handful of players doing normal survival activities. Expect TPS to dip as you approach 7-8 players, especially if they are exploring new terrain simultaneously.
- Pi 5 (4 GB, NVMe SSD): Comfortable with 3-4 players. Starts struggling at 5+.
- Pi 4 (8 GB, USB SSD): Suited to 2-4 players. New chunk generation causes noticeable lag. TNT cannons and large redstone machines will tank performance.
- Pi 4 (4 GB, SD card): Technically works for 1-2 players. Not a good experience. Chunk loading is painful.
Things that will hurt performance regardless of Pi model:
- Large numbers of entities (mob farms, lots of item drops)
- Complex redstone machines running continuously
- Multiple players exploring in different directions simultaneously (forces the server to generate and load chunks across multiple regions)
- Running other services on the same Pi alongside Minecraft
Pre-generate your world using a PaperMC plugin like Chunky. This creates all the chunks in advance so the server never has to generate them on the fly when players explore. On a Pi, this eliminates the worst lag spikes. Run the pre-generation overnight when no one is playing.
Monitoring and Maintenance
Check TPS in-game by typing /tps (PaperMC command). You want all three numbers at or near 20.0. If they are consistently below 18, reduce view-distance or simulation-distance further.
Monitor the Pi's temperature:
vcgencmd measure_temp
If it is above 80 degrees C under load, you need better cooling. The Pi 5 runs hot under sustained CPU load. An active cooler (fan) or a well-ventilated aluminium case is not optional for a 24/7 server workload.
Set up automatic backups of the world directory. A simple cron job works:
sudo -u minecraft mkdir -p /opt/minecraft/backups
sudo -u minecraft crontab -e
Add:
0 4 * * * tar -czf /opt/minecraft/backups/world-$(date +\%Y\%m\%d).tar.gz -C /opt/minecraft/server world
This creates a compressed backup of the world at 4 AM daily. Keep a week's worth and rotate out old ones to avoid filling your storage.
Next Steps
- Minecraft on Ubuntu 24.04 - If you want to run a larger server on proper hardware, this covers the full setup on x86.
- Minecraft in Docker - Containerise the server for easier management and the ability to run multiple instances.
- Pi 5 as a Docker Host - Use the same Pi for other self-hosted services alongside Minecraft.
- Set up Tailscale on Linux - Let friends connect to your Pi server without port forwarding.
A Raspberry Pi running a server is a legitimate homelab. You are managing a Linux system, configuring a Java application, tuning performance within hardware constraints, and setting up automated backups. These are real skills. When someone in an interview asks "tell me about a time you troubleshot a performance issue," a story about profiling TPS drops on a resource-constrained ARM device and tuning JVM garbage collection parameters is a better answer than most candidates give.
Key Takeaways
- The Pi 5 (8 GB) is the minimum for a comfortable Minecraft server experience with 5-8 players. The Pi 4 works for 2-4 players but requires aggressive tuning.
- An SSD is not optional. The difference between SD card and SSD for chunk loading is enormous. Use NVMe on Pi 5, USB SSD on Pi 4.
- Use PaperMC, not the vanilla server. The performance optimisations are essential on ARM hardware.
- Reduce view-distance to 6 and simulation-distance to 4. These two settings have more impact than any other tuning.
- Never allocate more than half the Pi's total RAM to Java. The OS and disk cache need the rest.
- Pre-generate the world with Chunky to eliminate lag spikes from on-the-fly chunk generation.
- Use active cooling on the Pi 5. A server workload will thermal throttle without it.
Related Guides
If you found this useful, these guides continue the journey:
- Minecraft Server in Docker -- Run your Minecraft server in a container for easy management and portability.
- Minecraft Server on Ubuntu -- Set up a dedicated Minecraft server on Ubuntu Linux.
- Minecraft Server on Windows -- Get a Minecraft server running on a spare Windows PC in minutes.
- Raspberry Pi 5 Homelab Guide -- Make the most of your Pi 5 as a homelab workhorse.
- Install Docker on Raspberry Pi -- Get Docker running on your Raspberry Pi.
RTFM Apparel · printed in the UK

ReadTheManual is run, written and curated by Eric Lonsdale.
Eric has over 20 years of professional experience in IT infrastructure, cloud architecture, and cybersecurity, but started with PCs long before that.
He built his first machine from parts bought off tables at the local college campus, hoping they worked. He learned on BBC Micros and Atari units in the early 90s, and has built almost every PC he’s used between 1995 and now.
From helpdesk to infrastructure architect, Eric has worked across enterprise datacentres, Azure environments, and security operations. He’s managed teams, trained engineers, and spent two decades solving the problems this site teaches you to solve.
ReadTheManual exists because Eric believes the best way to learn IT is to build things, break things, and actually read the manual. Every guide on this site runs on infrastructure he owns and maintains.
Enjoyed this guide?
New articles on Linux, homelab, cloud, and automation every 2 days. No spam, unsubscribe anytime.







