9 min read

How to Set Up a Paper Minecraft Server (Java)

Set up a Java Paper server step by step — install a matching JDK, run the jar, tune server.properties, keep it online, and let friends connect.

How to Set Up a Paper Minecraft Server (Java)

A Paper server comes down to seven steps in order: install a JDK that matches your drop, drop the Paper jar in an empty folder, launch it with a java command, clear the stop it throws on the first run, edit a handful of server.properties keys, keep the process running as a service, and open a path for friends to connect. Paper is the right base because it runs leaner than vanilla and it's what the plugin ecosystem targets — so once this is up you can move straight on to adding plugins without redoing anything.

Settle one thing before you download anything: which drop to target. As of September 2026, Paper's stable builds are for 26.2, while its builds for the brand-new 26.3 (out September 15) are still experimental, so choose the newest stable Paper build that your plugins support. Use 26.1 only when a plugin or other dependency requires it, and check the live 26.1 server list, 26.2 server list or 26.3 server list to see what is running.

Step 1: Install a matching JDK

Paper won't start without the right Java, and "right" means the major version PaperMC lists for the drop you picked. The current Getting Started page states Paper requires at least Java 25 for the newest builds, and 26.1 and 26.2 need Java 25 too; only the 1.21-era versions before the 26.x line list Java 21. That number is real-world and shifts over time, so don't memorize it — check the PaperMC downloads page for the drop you're building and install that JDK major version. A Temurin (Adoptium) build is a safe choice on any OS.

Verify it from a terminal before going further:

java -version

If that prints the major version PaperMC asked for, you're set. If it prints an older one, or "command not found," fix it now — a mismatched JDK is the single most common reason a fresh server refuses to boot, and the error it throws (UnsupportedClassVersionError) doesn't make the cause obvious.

Step 2: Download Paper into an empty folder

Go to papermc.io/downloads/paper, choose the drop you settled on (the page headlines its newest stable version and keeps brand-new versions behind an experimental toggle), pick the latest build, and download the server jar. What you get is a "Paperclip" launcher — a small jar that patches and downloads the real server on first run rather than shipping it whole. That's normal; let it do its thing.

Make a dedicated empty folder for the server and save the jar there. Rename it to something short like paper.jar so your run command stays readable. Keep this folder clean — everything the server creates (the world, configs, logs) lands here, and you'll be backing it up later, so you don't want random files mixed in.

Step 3: Run it from the terminal

Open a terminal in that folder and start the server:

java -Xms4G -Xmx4G -jar paper.jar --nogui

-Xmx is the memory ceiling (the max heap), -Xms is the starting heap, and the standard advice is to set them equal so the JVM grabs the whole heap up front. --nogui disables vanilla's pop-up window so you don't get two interfaces fighting on the command line — Paper accepts both --nogui and a bare nogui, so either works.

Don't hand the whole machine to -Xmx. Leave roughly 1–1.5GB for the operating system and Java's own overhead; on an 8GB box that means around 6.5GB to the server, not 8. How much you actually need depends on the gamemode more than the player count — how much RAM a 20-player server needs breaks down the tiers. Once the server is stable, the GC-tuning set everyone calls "Aikar's flags" is worth adding to the command, but plain -Xms/-Xmx is fine to get going.

Step 4: The first run writes eula.txt, then stops

The first launch stops almost immediately and prints:

You need to agree to the EULA in order to run the server. Go to eula.txt for more info.

This is expected, not a crash. The server writes a file called eula.txt into the folder and shuts down. Open that file, change eula=false to eula=true, save it, and run the same java command again. This time it boots fully, generates the world, and reaches Done in the console. People only trip here by editing the wrong line or forgetting to save.

Step 5: Tune the keys that matter in server.properties

That first successful boot also writes server.properties. Most of it you can leave alone; these are the keys worth setting, shown with their defaults:

server-port=25565
max-players=20
online-mode=true
view-distance=10
motd=A Minecraft Server

A few notes that save trouble:

  • online-mode=true verifies every player against Mojang's account database. Keep it true. Setting it to false lets anyone log in under any name, which is how servers get griefed by impersonators.
  • server-port=25565 is the Java default. Leave it at 25565 unless you have a specific reason to change it — the port shows up again in every connection step below. (Bedrock's default is 19132 over UDP, for contrast, but that's a different setup.)
  • view-distance=10 is generous. Dropping it to 8 noticeably eases load on a busy server with little visible difference to players.

Edit these, save, and restart the server to apply them — changes don't take effect live.

Step 6: Keep the server running

Closing the terminal kills the server, so you need it running on its own. Two standard patterns handle that; the simpler one comes first.

A detachable session (screen or tmux)

Good for a home box or quick testing. Start the server inside a named screen session:

screen -S Paper
java -Xms4G -Xmx4G -jar paper.jar --nogui

Detach with Ctrl+A then D — the server keeps running in the background — and reattach later with screen -r Paper to reach the console and type commands like stop. tmux does the same job if you prefer it.

A systemd service (proper uptime)

On a Linux host you want a systemd unit so the server starts on boot and restarts if it crashes. A unit at /etc/systemd/system/minecraft.service running under a dedicated minecraft user looks like this — adapt the paths and heap to your box:

[Unit]
Description=Paper Minecraft server
After=network.target
Wants=network-online.target
[Service]
Type=simple
User=minecraft
WorkingDirectory=/opt/minecraft/paper/
ExecStart=/usr/bin/java -Xmx4G -Xms4G -jar server.jar nogui
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target

Manage it with systemctl start minecraft, stop, restart, and status, and read logs with journalctl -u minecraft. The one refinement worth adding: send the console stop command on shutdown and set a generous TimeoutStopSec of 60–90 seconds, so the world finishes saving before systemd kills the process. A hard kill mid-save is how worlds get corrupted, which is also why a real backup routine matters from day one.

Step 7: Let friends connect

How a friend joins depends entirely on where they are.

  • Same network (LAN): they add the host machine's internal IP plus the port — 192.168.1.2:25565 — under Multiplayer -> Add Server. No router changes needed.
  • Remote, with router access: port forward external port 25565 to the server's internal IP, and friends connect to your public IP. This is the traditional route and the one with the most ways to get it slightly wrong.
  • Remote, no router access: a tunnel like playit.gg gives you a public address without touching the router, or a private mesh like Tailscale puts every device on one tailnet — install it on the host and each friend's machine, and they connect to the host's 100.x.y.z address or its MagicDNS name with no port forwarding at all. Both routes are walked through in running a server without port forwarding.

Whichever path you pick, your friends' clients have to be on the same drop as the server. If someone on a different version tries to join, they'll get kicked with "Outdated client!" (their game is behind) or "Outdated server!" (yours is) — the fix is matching the client to whatever version the server runs.

FAQ

How do I run server commands without the GUI window?

Type them into the same terminal or session the server runs in. stop shuts it down cleanly, op <name> grants operator status, and say <text> broadcasts to everyone. If you started it under screen, reattach with screen -r Paper first; under systemd, you'll want a console-attach setup or an RCON client, since journalctl only shows output — it doesn't take input.

The server starts but nobody outside my house can join — what's wrong?

Almost always the port isn't reachable from outside. Confirm the server itself is fine by connecting from another machine on the same network using the internal IP and 25565. If that works but remote players time out, the problem sits between your router and the internet: port forwarding isn't set up, your ISP uses CGNAT (which makes plain port forwarding impossible), or a firewall blocks 25565. A tunnel or Tailscale sidesteps all three.

Can I switch this server to 26.3 later?

Yes, but wait until Paper marks 26.3 stable. To move, stop the server, swap in the 26.3 Paper jar (it wants Java 25, the same as 26.2, so there's no new JDK to install), and restart — your world and configs carry over. Because 26.3 runs network protocol 777 against 26.2's 776, every player has to update at the same time, so plan the switch for when your regulars can all jump together.

Do I need a static IP or a domain for friends to keep connecting?

Not to start. On a LAN the internal IP is enough. For remote play, the catch is that most home connections have a public IP that changes occasionally, so a forwarded address can quietly stop working — a dynamic-DNS hostname or a tunnel's fixed address solves that. Tailscale avoids it entirely, since the host's 100.x.y.z tailnet address stays put no matter what your ISP does.