The complete Minecraft server administration guide for 1.21.4

Running a Minecraft server is not one job. It is a stack of small jobs that arrive in order: pick the software, get it online, make it secure, keep it fast, and make sure a single bad night cannot delete months of work. Most people do the first job well and discover the others the hard way.

This is the umbrella reference for all of it. It walks the full lifecycle of a Minecraft Java 1.21.4 server, from choosing between vanilla and Paper down to the backup routine that lets you sleep. Each section is deep enough to act on, but where a topic deserves its own full treatment, this guide hands off to the focused article rather than repeating it.

Read this top to bottom once to build the mental model, then come back to individual sections as you actually need them. Every command, file name, and permission number here is accurate to Java Edition 1.21.4.

Choosing your server software and where it runs

Before you download anything, two decisions shape everything that follows: what server software you run, and whose hardware it runs on. Getting these right up front saves a painful migration later.

Vanilla vs Paper vs Fabric

The server jar you pick decides your performance ceiling and what you can extend the server with. There is no single best answer, only the right answer for your group.

• Vanilla is Mojang's official server jar. It is the reference behavior: every mechanic works exactly as the game intends, and it always supports the newest version on day one. The tradeoff is that it is single-threaded for most of the tick loop and has no plugin or mod system. Good for a tiny group that wants pure survival and nothing else.
• Paper is a drop-in replacement for the vanilla jar built on Spigot. It keeps vanilla gameplay almost identically but adds hundreds of performance optimizations, async chunk loading, and a mature plugin API (Bukkit/Spigot/Paper plugins). For most multiplayer survival and minigame servers, Paper is the default choice. It does not run Fabric or Forge mods, only server-side plugins.
• Fabric is a lightweight mod loader. You run the Fabric server jar and add mods that change actual game content, plus performance mods like Lithium and Krypton. Fabric mods are usually client-and-server, so players often need the matching mods installed too. This is the path for modpacks and content mods, not for plugin-style server admin tools.

A simple rule: if everyone joins with a vanilla client and you want speed plus admin tools, run Paper. If you are running a content modpack, run Fabric (or Forge/NeoForge for those ecosystems). If your group is three friends and you want zero moving parts, vanilla is fine. The server setup guide covers switching from vanilla to Paper as a drop-in step.

Self-hosting vs a hosting provider

The second decision is whose machine runs the server 24/7.

• Self-hosting on a home PC or spare box costs nothing extra and gives you total control. The downsides are real: your machine has to stay on, your home internet upload becomes the bottleneck, and you have to deal with port forwarding yourself. It is the right call for 2 to 5 friends doing occasional sessions, or for testing a modpack before committing money.
• A hosting provider rents you a slice of a datacenter machine with a control panel, an address to share, and usually automated backups. It removes the port forwarding problem entirely and gives you real uptime. You pay monthly, and you trust someone else's hardware. This is the right call once you have more than about five regular players, want the server up when your PC is off, or have a slow home upload.

Neither is more legitimate than the other. Self-hosting is a fine way to learn, and you can always migrate the world folder to a host later by uploading it through the panel.

Hardware and RAM by player count

The single number people obsess over is RAM, and it matters, but it is not the whole story. CPU single-thread performance often limits tick rate before memory does, especially on vanilla. Still, here is a realistic starting point for how much memory to allocate to the server process:

• 2 to 4 players, vanilla: 2 to 3 GB
• 2 to 5 players, vanilla plus a few plugins: 3 to 4 GB
• 5 to 10 players, Paper or light mods: 4 to 6 GB
• 10 or more players, vanilla or Paper: 6 to 8 GB
• Any player count on a large modpack: 6 to 12 GB

These are allocations for the Java process, not your total system RAM. Leave at least 1 to 2 GB free for the operating system, and never allocate more than about 75 percent of physical memory. Over-allocating RAM does not make the server faster and can make garbage collection pauses worse. The full breakdown, including why modpacks need so much more and how to read garbage collection logs, is in how much RAM your server needs.

Setting up the server

With the software and host decided, getting the server online is a short, ordered checklist. Do the steps in order, because each one generates files the next step needs.

Install the correct Java version

Minecraft 1.21.4 requires Java 21. Older Java will refuse to launch the jar. Download a Java 21 runtime from Adoptium (the Temurin build is the standard free choice), install it, and verify from a terminal:

java -version

You want to see a version line starting with 21. If it shows an older number, you have multiple Java installs and need to point your startup script at the Java 21 binary directly with its full path.

Download the server jar and accept the EULA

Get the official 1.21.4 server jar from minecraft.net/en-us/download/server. It is a single roughly 50 MB file. Never download "server jars" from third-party sites; the official URL is the only safe source.

Put server.jar in a dedicated empty folder, for example C:\MinecraftServer\ or ~/minecraft-server/, then run it once:

java -jar server.jar nogui

The server exits immediately and writes a file called eula.txt. Open it, change eula=false to eula=true, and save. This is a legal acknowledgement that you have read Mojang's End User License Agreement. The server will not start until you do this.

First launch and connecting

Run the jar again. This time it generates the world (a one-time process that can take a minute) and creates server.properties, the world/ folder, and the player data files. When the console prints Done, the server is live.

1. Connect locally by joining localhost or 127.0.0.1 from a Minecraft client on the same machine, to confirm the server works at all.
2. Connect from your LAN using the server PC's local IPv4 address (find it with ipconfig on Windows or ip addr on Linux; it usually starts with 192.168.).
3. Open the server to the internet with port forwarding.

Port forwarding is the step where most self-hosted servers quietly die, because by default your router does not pass external traffic to your server PC. You create a rule in your router admin page forwarding port 25565 (TCP) to your server's local IP, then share your public IP with friends. The full walkthrough, including dynamic IP handling and tunnel alternatives like Playit.gg for restricted networks, lives in the server setup guide. It is the one part of setup worth following step by step.

One placement rule while you are here: never put the server folder inside a synced location like OneDrive, Dropbox, or iCloud Drive. The cloud client tries to sync world files while the server is writing to them, which corrupts the world. Keep the server on a local, non-synced disk and let your backup routine make copies deliberately.

Configuring server.properties

server.properties is the main config file, sitting next to the jar. The server reads it once at startup, so almost every change needs a restart to take effect. The exceptions are the /whitelist commands and /difficulty, which change behavior live and also rewrite the file. Keys are kebab-case, values are key=value with no spaces around the =, and an empty value means "unset" rather than zero.

You do not need to understand all fifty-odd settings. A handful carry most of the weight, and the rest can stay at their defaults. The full line-by-line reference is in server.properties explained; here is the shortlist that actually changes how your server feels.

The performance levers

view-distance=10
simulation-distance=10
max-players=20
network-compression-threshold=256

• view-distance is how many chunks the server sends to each player in every direction. Chunk count grows with the square of the radius, so going from 10 to 16 nearly triples the loaded area per player. It is your biggest memory and bandwidth lever. For 1 to 5 players you can run 12 comfortably; on a crowded server drop to 8.
• simulation-distance is how far from a player the world actually ticks: crops grow, mobs move, redstone runs. Chunks between simulation distance and view distance are visible but frozen. Lowering this helps tick lag far more than lowering view distance, because it cuts entity and block updates rather than just rendering data. A common tuning is view-distance=12 with simulation-distance=8. The full explanation of the two is in render vs simulation distance.
• max-players is a cap, not a performance setting. What costs resources is what players do, not the slot count. Set it to your real group size.

Identity and gameplay

gamemode=survival
difficulty=normal
hardcore=false
pvp=true
allow-nether=true
spawn-protection=16

• difficulty ships as easy. Most survival servers want normal or hard. This one has a live command, /difficulty hard.
• spawn-protection is a square radius around world spawn that only ops can modify. It protects blocks but not chests, and it confuses new players who cannot dig at spawn. Many servers set it to 0 and protect spawn with a plugin instead.
• hardcore=true locks difficulty to hard and sends dead players to spectator permanently. Be sure before enabling it on a long-term world.

The settings that touch security

online-mode=true
white-list=false
enforce-whitelist=false
op-permission-level=4
enable-command-block=false
enforce-secure-profile=true

These five lines are the difference between a private friends server and an open door. They get their own full section below, because security is where new admins make the most expensive mistakes.

Players, permissions, and security

This is the section to read twice. A misconfigured server runs slow; an insecure server gets griefed, and there is rarely an undo. The good news is that the safe defaults are simple, and the dangerous settings are few and clearly marked.

The whitelist is your front door

For any private server, the whitelist is the right tool. It blocks anyone not on the list from joining, full stop. Enable it from the console:

whitelist on
whitelist add PlayerName
whitelist reload

whitelist on sets white-list=true. Pair it with enforce-whitelist=true so that anyone online but not on the list is kicked the moment you reload it, not just blocked at the next join. The whitelist stores entries in whitelist.json by UUID, so it survives a player changing their username. Full setup, including how to run a whitelist alongside a public spawn, is in the whitelist and permissions guide.

Operator permission levels 1 to 4

When you /op a player you grant them an operator level, and that number decides how much power they get. The levels are cumulative:

• Level 1: can bypass spawn protection. Almost no special commands.
• Level 2: can use most cheat commands (/gamemode, /give, /tp, /time, /weather) and command blocks. This is the typical "trusted builder" level.
• Level 3: adds player management: /kick, /ban, /op, /deop, /whitelist. This is the moderator level.
• Level 4: everything, including /stop, /save-off, and server-controlling commands. This is the owner level.

The op-permission-level property sets what a plain /op grants, defaulting to 4. On a friends server that default is fine. On anything public, set it lower so a compromised or careless moderator account cannot shut the server down or disable saving. You set a specific level per player by editing ops.json directly:

[
  {
    "uuid": "069a79f4-44e9-4726-a5be-fca90e38aaf5",
    "name": "Notch",
    "level": 4,
    "bypassesPlayerLimit": false
  }
]

Edit ops.json with the server stopped, then start it, or use /op and /deop live for level changes at the default level. The permission tiers and exactly which command sits at which level are detailed in the whitelist and permissions guide.

Banning and kicking

The moderation commands are straightforward and work from console or in-game at the right op level:

kick PlayerName Reason here     # remove without ban
ban PlayerName Reason here      # ban by name, writes banned-players.json
ban-ip 203.0.113.5              # ban an IP, writes banned-ips.json
pardon PlayerName               # unban a player
pardon-ip 203.0.113.5           # unban an IP
banlist                         # show current bans

Name bans store the player's UUID, so a username change does not dodge them. IP bans are blunt: they catch everyone behind that address, which can include a whole household or a shared network, so use them for persistent attackers rather than first offenses.

The real danger: online-mode=false

online-mode=true makes the server verify every joining player against Mojang's authentication servers. Leave it on. This is the single most important security setting on the file.

When you set online-mode=false, the server stops checking accounts. Anyone can join with any username they type, including the names of your operators. Someone can log in as your admin account, inherit its op level, and do whatever that level allows. Player data also becomes tied to unverified names rather than stable UUIDs, so identity itself stops being reliable. There is no plugin that fully fixes an open offline-mode server, only ones that paper over it with passwords.

There are exactly two legitimate reasons to run offline mode:

1. You are behind a proxy like Velocity or BungeeCord that performs the Mojang verification itself before forwarding the connection. The backend servers run offline mode because the proxy already authenticated the player.
2. You are running a Geyser crossplay setup where Floodgate authenticates Bedrock players, covered in the crossplay section below.

Outside those two cases, offline mode on an internet-facing server is an open invitation. If a guide tells you to disable online mode "so your friend without an account can join," it is telling you to make the server impersonatable.

Slowing down brute-force and abuse

Even with online mode on, a public address attracts noise: connection floods, bot scanners, and spam. A few defenses help:

• rate-limit in server.properties sets a packet-per-tick threshold above which a player is kicked. It defaults to 0 (off). Setting a sane value like 300 on a busy public server adds a cheap layer against packet floods without affecting normal play.
• network-compression-threshold at its default of 256 is fine; do not disable compression on a public server.
• enforce-secure-profile=true requires Mojang-signed chat keys and should stay on unless a mod needs it off.
• A proxy or firewall in front of the server is the real answer for a server under active attack. Rate limiting at the network layer beats anything server.properties can do alone.

For private servers, the whitelist makes most of this moot: an attacker who is not on the list never gets past the join check.

Performance tuning, in brief

Performance has two halves: the Java runtime, and the work the server has to do. This hub points at the deep guides rather than repeating them, because both topics are large enough to deserve their own articles.

The Java side is JVM flags. The vanilla default garbage collector causes periodic freeze-stutters as it pauses the whole server to clean memory. Aikar's tuned G1GC flags dramatically reduce those pauses, and they belong in every startup script. The complete, copy-paste flag set with an explanation of what each option does is in JVM flags for 1.21.4. Do not hand-tune these; use the published set as-is and only change -Xmx.

The world side is chunk pre-generation. Most server lag spikes happen when players walk into ungenerated terrain and the server has to build new chunks on the fly while also serving everyone else. Pre-generating a reasonable radius around spawn ahead of time moves that expensive work to a quiet moment and makes exploration smooth. The how-to, including the tools and sensible radius choices, is in pre-generating chunks.

Beyond those two, switching from vanilla to Paper (or adding Lithium on Fabric) is the highest-leverage single change for tick rate, which is why software choice was the first decision in this guide. When something does stutter despite all this, the diagnostic process is in fixing lag and stutters.

Crossplay with Bedrock players

If some of your group plays on phones, consoles, or the Windows 10/11 Bedrock edition, they cannot join a Java server directly, because the two editions speak different network protocols. The bridge is Geyser, a proxy that translates Bedrock connections into Java ones, paired with Floodgate, which lets Bedrock players join without owning a Java account.

The short version: Geyser runs either as a plugin on your Paper server or as a standalone proxy, listening on the Bedrock default UDP port 19132. Bedrock players add your server using that address and port, and Geyser presents them to your Java server as if they were Java clients. Floodgate handles their authentication against Microsoft's Bedrock servers, which is the legitimate reason a Geyser setup runs with Java-side online mode adjusted: Floodgate, not an open door, is verifying those players.

This is a brief pointer, not the full setup. The complete walkthrough, including the Paper plugin path, the standalone path, prefix handling for Bedrock usernames, and the port forwarding for UDP 19132, is in the Geyser crossplay guide.

Maintenance: backups, updates, and ongoing care

Setup is a day. Maintenance is forever, and it is what separates a server that lasts a year from one that ends with "I think the world got corrupted." This section is the operational heart of administration.

Backups: the one thing you cannot skip

A backup is a copy of your world/ folder (plus your config and player data) taken at a known-good moment and stored somewhere the live server cannot touch. The reason to obsess over this is simple: world corruption from a power cut, a bad shutdown, or a buggy plugin is unrecoverable without one, and griefing on a shared server is far easier to undo with a rollback than by hand.

The critical technique is flushing the world to disk before you copy it. A running server keeps recent changes in memory, so copying the files mid-write captures a half-written, possibly corrupt world. The safe sequence from the console is:

save-off          # stop the server writing to the world files
save-all flush    # force everything in memory to disk now

With saving paused and flushed, copy the world/ folder somewhere safe, then re-enable writes:

save-on           # resume normal saving

That save-off, save-all flush, copy, save-on cycle is the backbone of every safe backup, automated or manual. The full routine, including what else to back up beyond the world, retention schedules, and off-machine copies, is in the backup guide.

Automating backups

Doing the flush-and-copy by hand works, but humans forget. Automate it so it runs whether or not you remember:

• On a self-hosted Linux box, a shell script triggered by cron can send the save commands to the server console (through a tool like screen, tmux, or RCON), copy the world, and prune old backups. Daily is a sane baseline; hourly for an active server.
• On Windows, Task Scheduler runs the same logic in a batch or PowerShell script.
• On a managed host, the control panel almost certainly has scheduled backups built in. Turn them on, set a retention count, and verify one actually downloads.

Always keep at least one recent backup off the server machine: a different disk, a NAS, or cloud storage. A backup sitting on the same drive as the world dies with that drive. The automation patterns and a ready-to-adapt script are in the backup guide.

Restoring from a backup

When you do need to roll back, the process is deliberate and not to be rushed:

1. Stop the server with stop. Never restore over a running server.
2. Move the current world aside rather than deleting it. Rename world to world-broken-2026-06-17 so you can investigate later or recover anything the backup missed.
3. Copy the backup into place as world.
4. Start the server and verify in-game before letting players back on.

The keep-the-broken-copy step matters. Sometimes the "corruption" was one chunk and you can salvage recent progress from the broken world after the fact.

Updating the server safely

When a new patch ships, do not just overwrite the jar and hope. Updates are exactly when an untested change meets your only copy of the world.

1. Read the changelog for the new version and, on Paper or Fabric, confirm your plugins and mods support it. A modded server that updates before its mods do will fail to load, sometimes after mangling world data.
2. Take a fresh backup with the flush sequence above. This is non-negotiable.
3. Test on a copy if you can: spin up the new jar against a copy of the world in a separate folder and confirm it loads cleanly.
4. Replace the jar, keeping the old one nearby so you can roll back the binary as fast as the world.
5. Start, watch the console for errors, and only then announce the update.

For modded servers especially, the order is: backup, then update mods and the loader together, then test, then go live. Updating piecemeal is how mod-version mismatches eat worlds.

Managing datapacks, plugins, and mods

How you extend the server depends on the jar you chose, and each path has its own discipline.

• Datapacks are vanilla-compatible and drop into world/datapacks/. They change loot, recipes, advancements, and functions without any mod loader, which makes them the safest way to customize a vanilla or Paper server. After adding one, run /reload or restart, then /datapack list to confirm it loaded. The install steps and gotchas are in how to install datapacks. Note that command-block-heavy datapacks may need enable-command-block=true.
• Plugins (Paper/Spigot/Bukkit) go in the plugins/ folder. They are server-side only, so players join with a vanilla client. Add them one at a time, restart, and check the console: a single incompatible plugin can stop the whole server from starting. Match every plugin to your exact Minecraft version.
• Mods (Fabric/Forge/NeoForge) go in the mods/ folder and usually require matching client-side mods, so coordinate versions with your players. Performance mods like Lithium are an exception; they are server-side and need nothing from the client. The Fabric workflow is in how to install Fabric mods, and a curated performance set is in Fabric performance mods.

The golden rule across all three: add one thing, restart, verify, then add the next. When something breaks, you want to know exactly which addition did it.

Monitoring TPS and health

A server that feels fine to you might be quietly struggling for a player exploring at the edge of the loaded area. Make health observable instead of guessing:

• /tick query in vanilla 1.21.4 reports the current tick rate and any tick freezing. On Paper, /tps gives a rolling 1, 5, and 15 minute average. Sustained TPS under 18 is the cue to investigate.
• /forge tps or Spark (a profiling plugin/mod) breaks down where tick time actually goes, which beats guessing. Spark works on Paper and Fabric and is the standard tool for finding the laggy chunk or entity.
• Watch entity counts. A common cause of slow TPS is an item or mob buildup: a broken farm spilling items, or a mob cap saturated near an unlit area. Tools like Spark or the /mobcap style commands on Paper surface this.
• Watch the logs. The logs/latest.log file records errors, crashes, and warnings. When something misbehaves, the log usually said why. Keep an eye on it after any change.

Your first-week checklist

Use this as the order of operations for a brand-new server. Each item links to the section or guide that explains it in full.

1. Pick your software (vanilla, Paper, or Fabric) and decide self-host vs a host.
2. Install Java 21 and verify with java -version.
3. Download the official server jar, accept the EULA, and do the first launch.
4. Set up port forwarding (self-host) or note your panel address (host), and confirm a friend can connect.
5. Tune server.properties: set difficulty, pick view-distance and simulation-distance consciously, and decide on spawn-protection.
6. Lock the door: confirm online-mode=true, enable the whitelist, and add your players.
7. Set op levels deliberately rather than handing everyone level 4. Use level 2 for builders, level 3 for moderators.
8. Add Aikar's JVM flags to your startup script.
9. Pre-generate a reasonable radius of chunks around spawn before opening up.
10. Set up automated backups with the flush sequence, and store one copy off-machine.
11. Restore a backup once into a test folder to prove the routine works.
12. Add plugins, mods, or datapacks one at a time, restarting and verifying between each.
13. Check TPS with /tick query or /tps under real player load, and tune simulation distance if it dips.

If you do these thirteen things in order, you will have skipped every common way a new server falls over.

Frequently asked questions

Do I need a static IP to run a server? No. Most home connections have a dynamic public IP that changes occasionally. A free dynamic DNS service like No-IP gives you a fixed hostname that tracks the changing IP, which is more reliable to share than a raw IP. A managed host gives you a stable address by default.

How much RAM should I give the server? Start with the table in the choosing section above: 2 to 4 GB for small vanilla groups, 6 GB or more for ten players or a modpack. Do not over-allocate; more RAM than the server uses just makes garbage collection pauses longer. The full reasoning is in how much RAM your server needs.

Is it safe to set online-mode=false so a friend without an account can join? No. On an internet-facing server, offline mode lets anyone join under any name, including your operator names, and there is no real fix. The only legitimate uses are behind a verifying proxy or with Floodgate in a Geyser crossplay setup.

Vanilla, Paper, or Fabric: which should I run? Paper for vanilla-style multiplayer that wants speed and admin plugins; Fabric for content mods and modpacks; vanilla for a tiny group that wants zero moving parts. You can start vanilla and swap to Paper as a drop-in later.

How often should I back up? Daily is a reasonable baseline for a casual server, hourly for an active one. Always flush with save-off and save-all flush before copying, keep multiple dated copies, and store at least one off the server machine. See the backup guide.

My server lags. Where do I start? Check TPS first with /tick query or /tps. If it is low, lower simulation-distance, confirm you have Aikar's JVM flags, pre-generate chunks around spawn, and profile with Spark to find the specific culprit. The full process is in fixing lag and stutters.

Do I need to restart the server after editing server.properties? Yes, for almost everything. The file is read once at startup. The only live exceptions are the /difficulty command and the /whitelist family of commands, which both change behavior immediately and rewrite the file.

How do I update to a new Minecraft version without breaking my world? Back up first, confirm your plugins and mods support the new version, test the new jar against a copy of the world, then replace the jar and watch the console on first launch. Never overwrite the jar without a fresh backup in hand.

Where to go next

This guide is the map. The focused articles are the territory:

• How to set up a server (with port forwarding)
• server.properties explained, setting by setting
• Whitelist, ops, and permission levels
• Backups: routine, automation, and restoring
• Crossplay with Geyser and Floodgate
• How much RAM your server actually needs
• JVM flags for 1.21.4
• Pre-generating chunks for smooth exploration

Run a server long enough and administration stops feeling like a chore and starts feeling like its own quiet hobby: a healthy TPS graph, a backup that restored clean, a config tuned to exactly your group. Set the foundation right with this guide, lean on the focused ones as you go, and the server will outlast the version it started on.

---

Updated for Minecraft Java Edition 1.21.4 on June 17, 2026. As new versions ship, defaults, commands, and permission tiers are re-verified and this reference is updated.