How to Host a Minecraft Server on a Linux VPS or Dedicated Server

The short version

A Minecraft server is a single Java process listening on TCP port 25565. Hosting one yourself takes a Linux box, a Java runtime, one jar file, and about an hour the first time. The whole procedure:

1. Pick a machine. Two decent cores and 4 GB of RAM covers a vanilla world for friends; the sizing table below scales it up.
2. Install Java 25. Current Minecraft (the 26.x game drops) refuses to start on anything older.
3. Create a dedicated minecraft system user so the server never runs as root.
4. Download a server jar: Paper for most servers, vanilla if you want stock behaviour untouched.
5. Run it once, then set eula=true in eula.txt to accept Minecraft's licence terms.
6. Set the basics in server.properties: MOTD, player cap, view distance, whitelist.
7. Wrap it in a systemd unit so it starts at boot and comes back after a crash.
8. Open 25565/tcp in the firewall, point DNS at the box, and hand out the address.

That list is the whole job. The rest of this guide walks each step on Ubuntu or Debian, then covers what separates a server that runs tonight from one still running in six months: JVM flags, whitelisting, backups, updates, and Bedrock crossplay for friends on phones and consoles.

What you need

Three resources matter, in this order: single-thread CPU performance, RAM, then disk.

The main game loop runs on one thread. Modern versions push some work elsewhere (networking, chunk loading), but the Minecraft wiki's requirements page notes that the server typically uses three cores at most. A CPU with fewer, faster cores beats one with many slow ones, and no amount of extra cores rescues a lagging tick loop. This is the single spec most hosting comparisons get wrong.

RAM depends on player count and modding. The figures below are community rules of thumb, anchored to the wiki's stated floor of 1 GB, not measurements from any one machine:

Two notes on that table. View distance moves the numbers more than player count does, because loaded chunks grow with the square of the distance. And heavy modpacks publish their own requirements; trust the pack author over any generic table, including this one.

Disk is the easy part. A fresh world is tens of megabytes; a long-running community map with sprawling exploration reaches tens of gigabytes. An NVMe drive helps when players fan out and the server streams chunks from disk, and 50 GB of space leaves room for the world plus local backups. For hardware guidance beyond Minecraft, the dedicated server sizing guide covers the general case.

For the operating system, Ubuntu LTS and Debian both do the job, and every command below runs on either. If you want help picking, Ubuntu vs Debian for a dedicated server walks the differences.

Choosing the server software

One distinction sorts the whole field: plugins run only on the server, so players join with a stock client; mods change the game itself and usually need a matching install on every player's machine. Decide which you need and the software picks itself.

The mod-loader half needs one piece of history. NeoForge split from Forge in mid-2023, and the large packs on recent versions target it; All The Mods 10 runs on NeoForge, for example. Packs pinned to 1.20.1 and earlier still run classic Forge. Fabric stays the lightweight, fast-updating loader where the performance-mod ecosystem lives. Mods do not cross loaders, and every mod must also match the game version, so the pack you choose dictates loader and version both.

The honest default: run Paper unless a specific modpack decides otherwise. It holds tick rate under load better than vanilla, its plugin ecosystem covers everything from permissions to minigames, and nobody has to touch their client. The rare reason to prefer vanilla is wanting reference behaviour with zero deviation, mostly relevant to technical redstone communities.

Set it up on Ubuntu or Debian

The steps below assume a fresh box you reach over SSH as root or with sudo. The example server lives at 203.0.113.10; substitute your own address throughout.

Step 1: Install Java 25

Minecraft's Java requirement moved twice in recent memory: 1.18 raised it to Java 17, 1.20.5 raised it to Java 21, and the 26.1 game drop (March 2026) raised it to Java 25. Anything current needs 25. If you plan to run a modpack pinned to an older game version, install the older runtime it asks for instead.

On a distribution whose repositories carry it (Ubuntu 26.04 does), one package does the job:

sudo apt update
sudo apt install openjdk-25-jre-headless

If your release predates a packaged Java 25, Adoptium's Temurin 25 builds cover Ubuntu and Debian through an apt repository. Either way, confirm what you got:

java -version

openjdk version "25.0.1" 2025-10-21
OpenJDK Runtime Environment (build 25.0.1+8)

Your exact build string will differ; the number that matters is the 25.

Step 2: Create a dedicated user

Game servers parse a lot of untrusted input from the internet. If one is ever compromised, the blast radius should be one unprivileged account, not the box:

sudo adduser --system --group --home /opt/minecraft minecraft

Everything from here happens in /opt/minecraft, owned by that user.

Step 3: Download the server jar

For Paper, copy the download link for the newest build from the Paper downloads page and fetch it as the service user:

cd /opt/minecraft
sudo -u minecraft wget -O server.jar 'https://...paste-the-build-link-here...'

For vanilla, the jar link lives on the official server download page. Both drop a single server.jar; nothing else to install.

Step 4: First run and the EULA

Run the jar once by hand. It writes its config files and exits:

sudo -u minecraft java -Xms1G -Xmx1G -jar server.jar nogui

[12:00:01 INFO]: You need to agree to the EULA in order to run the server.
Go to eula.txt for more info.

Setting the flag means you accept the Minecraft EULA, so read it once; the short version is that private and community servers are fine and selling gameplay advantages is restricted:

sudo -u minecraft sed -i 's/eula=false/eula=true/' eula.txt

Step 5: server.properties essentials

The first run also wrote server.properties. Most of its keys can wait. These cannot:

Step 6: A systemd unit that survives reboots

Put the launch command in a script so later JVM tuning edits one file:

# /opt/minecraft/start.sh
#!/bin/sh
exec /usr/bin/java -Xms4G -Xmx4G -jar /opt/minecraft/server.jar nogui

Make it executable and owned by the service user, then create the unit:

# /etc/systemd/system/minecraft.service
[Unit]
Description=Minecraft server
After=network-online.target
Wants=network-online.target

[Service]
User=minecraft
Group=minecraft
WorkingDirectory=/opt/minecraft
ExecStart=/opt/minecraft/start.sh
Restart=on-failure
RestartSec=10
TimeoutStopSec=120

[Install]
WantedBy=multi-user.target

Restart=on-failure is the line that matters: when the process dies at 3 a.m., systemd brings it back ten seconds later. On stop, systemd sends SIGTERM, the server's shutdown hook saves the world, and the generous TimeoutStopSec gives a big map time to flush before anything harsher happens. Enable and start:

sudo systemctl daemon-reload
sudo systemctl enable --now minecraft
journalctl -u minecraft -f

[12:03:11 INFO]: Starting minecraft server version 26.2
[12:03:14 INFO]: Preparing level "world"
[12:03:22 INFO]: Done (8.421s)! For help, type "help"

(Output is illustrative; your version and timings will differ.) The Done line means the server is up and listening.

Step 7: Open the firewall

On a default-deny firewall, one rule lets Java players in:

sudo ufw allow 25565/tcp comment 'Minecraft Java'

If the box has no firewall baseline yet, set one up before the server gets popular; the default firewall rules guide covers a sane starting ruleset for exactly this kind of host.

Memory sizing and Aikar's flags

Two JVM rules cover most grief. First, set -Xms equal to -Xmx so the heap never resizes mid-game. Second, never hand the JVM all the machine's RAM: the operating system and the JVM's own off-heap overhead need room, so a server with 8 GB of RAM should run a 6 GB heap at most.

Beyond sizing, the standard tuning is Aikar's flags, a G1 garbage-collector configuration documented by PaperMC as its recommended baseline. Stock G1 tends to run rare, long collections that freeze the tick loop for whole seconds; this flag set trades them for frequent short pauses players do not feel. The full start.sh for a 4 GB heap:

# /opt/minecraft/start.sh
#!/bin/sh
exec /usr/bin/java -Xms4G -Xmx4G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 \
  -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 \
  -jar /opt/minecraft/server.jar nogui

Heaps above 12 GB want a handful of different values (larger G1 regions among them); Aikar's original guidance lists the exact substitutions. Restart the service after editing and the flags are live.

Making it reachable

Players can already join by raw address and port: 203.0.113.10:25565. Nobody wants to type that, so give it a name. An A record gets you halfway; an SRV record removes the port too, so people type a clean play.example.com even if you ever move the server or change ports:

mc.example.com.                   300  IN  A    203.0.113.10
_minecraft._tcp.play.example.com. 300  IN  SRV  0 5 25565 mc.example.com.

The addresses and domains here come from the documentation ranges reserved for examples; substitute your own.

One network reality deserves plain words before you publish that address anywhere. Public game servers are among the most attacked things on the internet: a player gets banned, rents a booter for a few dollars, and your Saturday evening event goes offline. This is routine, not hypothetical, and host-level firewall rules cannot absorb volumetric floods; mitigation has to live in the network in front of you. The DDoS attack types guide explains what those attacks look like and what actually stops them. Factor it into where you host, because you cannot bolt it on afterwards.

Whitelist and first-day security

An open server collects griefers and bots within days of the address leaking. For anything that is not deliberately public, turn the whitelist on before you share the address.

Because the server runs under systemd, there is no interactive console attached, so admin commands travel over RCON. Enable it in server.properties, locally only:

enable-rcon=true
rcon.password=use-a-long-random-string-here

RCON listens on port 25575. Do not open that port in the firewall; with the default-deny setup above it stays unreachable from outside, which is exactly right. From the box itself, any RCON client works (mcrcon is a common one):

mcrcon -H 127.0.0.1 -p 'your-rcon-password' "whitelist on" "whitelist add Alex" "op Alex"

Set enforce-whitelist=true in server.properties so a reload kicks anyone not on the list. Keep the op list to people you would give SSH access, because in-game operators can run every command RCON can. And leave online-mode=true: turning it off drops account verification entirely, which invites impersonation and stolen-account joins. Bedrock crossplay does not need it off either, as the Geyser section shows.

The box itself needs the same care as any internet-facing Linux host: key-only SSH, unattended security updates, no stray services. The Linux server hardening checklist is the companion piece for that layer.

Backups

The world lives in the world directory (Paper splits dimensions into world_nether and world_the_end alongside it). Copying files while the server writes them risks a corrupt snapshot, so the simple reliable pattern stops the service around a nightly tar:

sudo systemctl stop minecraft
sudo tar -C /opt/minecraft -czf /var/backups/minecraft-$(date +%F).tar.gz \
  world world_nether world_the_end server.properties
sudo systemctl start minecraft

Run it from cron at an hour your players sleep; the gap is under a minute for most worlds. If any downtime is unacceptable, the no-stop variant issues save-off and save-all over RCON, copies the files, then save-on. Either way, ship the archives somewhere off the machine, because backups on the disk that fails are not backups. Test a restore once by unpacking into a scratch directory and booting a throwaway server against it; the first time you learn a backup is broken should not be the day you need it.

Updating

Minecraft now ships several game drops a year under calendar versioning (26.1, 26.2, and so on), plus hotfixes between them, so updates are a routine, not an event. The mechanics are pleasantly dull: back up, download the new jar for your server software, replace server.jar, restart the service. World data upgrades in place when the new version boots it.

The order of operations is where people get burned. Update the server software only after your plugins or mods support the new game version; Paper publishes builds per version, and a plugin that lags a game drop behind will refuse to load or misbehave. Hold major upgrades until your load-bearing plugins are ready, and keep taking the hotfix builds for your current version in the meantime, since those carry the security fixes.

Bedrock crossplay with Geyser

Java and Bedrock are separate games with incompatible protocols, and the friends most likely to ask about joining are on phones, consoles, or the Windows Bedrock app. Geyser bridges the gap: it accepts Bedrock connections and translates them to the Java protocol live. On a Paper server it is two jars dropped into plugins/: Geyser-Spigot, plus Floodgate so Bedrock players can join without owning a Java account. In Geyser's config, set auth-type: floodgate to switch verification over.

Bedrock speaks UDP on its own port, so open it alongside the Java rule:

sudo ufw allow 19132/udp comment 'Minecraft Bedrock (Geyser)'

Phones and Windows join by adding a server with your address and port 19132. Consoles are the awkward case: their server list only shows official partners, so console players need a workaround such as BedrockConnect. Floodgate marks its players with a leading . in the username, and a translation layer is never perfect (a few blocks and movement behaviours differ at the margins), but everyday survival crossplay works well. SRV records do not apply here; Bedrock clients never look them up.

FAQ

How much RAM does a Minecraft server need?

The Minecraft wiki puts the floor at 1 GB of heap, and 2 GB runs a vanilla world for a handful of friends without hiccups. A small public Paper server with a few plugins sits comfortably at 4 GB, and heavy modpacks state their own requirements, usually 8 GB or more. More is not automatically better: garbage collection pauses grow with heap size, so match the allocation to the workload and leave a couple of gigabytes for the operating system.

What Java version does a Minecraft server need?

It depends on the game version, and getting it wrong stops the server at startup. The 26.1 game drop from March 2026 raised the requirement to Java 25, so anything current needs that. The 1.20.5 through 1.21.x line needs Java 21, and 1.18 through 1.20.4 needs Java 17. Modpacks pinned to older versions inherit the older requirement, so check the pack before you install a runtime.

Can Bedrock players join a Java server?

Yes, through Geyser, which translates the Bedrock protocol to the Java protocol at the network edge. Add Floodgate and Bedrock players do not even need a Java account. You open UDP port 19132 alongside the Java port, and phones and PCs join by address and port. Consoles need an extra step, such as BedrockConnect, because their server list is locked to official partners. A few gameplay details differ across the translation layer, but normal survival play works.

Why can't my friends connect to my server?

Work down the chain. Check the server is running with systemctl status and the log shows the Done message. Check the firewall actually allows 25565/tcp. Check they are using the right address, and if you set up an SRV record, test it before blaming anything else. If someone on a cracked launcher is rejected while everyone else gets in, that is online-mode doing its job, not a fault.

Do I need Paper, or is vanilla fine?

Vanilla is fine for a small stock-survival world; it is the reference implementation and needs no explanation. Paper earns its place the moment you want better performance under load or any plugin, because plugins run server-side and players join with an unmodified client. Mods are the step beyond that: they need Fabric or NeoForge on the server and a matching install on every player's client. You can move a vanilla world onto Paper by pointing the new jar at the same directory; take a backup first.

Deploying on Serverside

A Minecraft server is a long-running, latency-sensitive process that strangers will eventually attack, which makes the network it sits on part of the spec. Serverside runs its own network (AS55285) with always-on DDoS mitigation in front of every server, so the booter aimed at your world hits the mitigation layer instead of your tick loop, and provisioning is sub-minute, so the box exists before you have finished reading the EULA.

The honest fit guidance follows the sizing table. A cloud VPS covers a vanilla or small Paper world for friends: a few cores, 4 to 8 GB of RAM, done. Once you are hosting a real community or a heavy NeoForge modpack, the single-thread clock speed and RAM headroom of a dedicated server is what keeps 20 ticks per second under load, with no neighbours sharing the cores your game loop runs on.