Work lost on a server usually doesn't come from a technical fault — it comes from giving someone more authority than you meant to. This article covers protecting your server in three layers: who can join, what they can do once in, and what happens when it goes wrong.

Layer 1: who can join

The simplest and most effective protection. With the whitelist on, only players you've added can join; even if the address leaks, nobody else gets in.

Here's the mistake people make: they fill the list but never turn on the switch in Settings. While that switch is off the names on the list mean nothing and the server stays open to everyone. The two work together.

There's also an enforce option: with it on, a player you remove from the list is dropped from the game if they're connected at that moment; with it off, the change only takes effect the next time they try to join. If you ever need to remove someone in a hurry, having this on does the job.

The Allow cracked logins option in Settings is the one security item worth understanding: turning it on means Java accounts are not verified, so somebody can join under another person's name. In a group with unlicensed players it may be necessary; if so, make sure your permission plugins work by player identity (UUID) rather than by name.

Layer 2: what they can do once in

Operator (OP) rights go further than people assume. The limit is set by the operator permission level in Settings, and the default is the highest one: command blocks, kicking players, even stopping the server. Handing out OP so someone "can help" is the most common way to lose a server.

What you usually need isn't OP but scoped permissions: one person who can only kick, another who can only claim regions. That takes a permission-management plugin; if you run plugin-family software (Paper, Purpur, Spigot, CraftBukkit) you can install one from the store inside the panel with a single click. We cover installing them in the plugin installation article.

The second tool against griefing is a region protection plugin: you lock spawn, shared builds and storage against everyone but named players. Small groups of friends rarely need it; a server open to everyone almost always does.

Layer 3: when it goes wrong

This is the most neglected layer and the most useful one, because the first two will eventually be breached.

  • File Protection is on for every server, free, and cannot be turned off. An automatic backup is taken every day and, while your server runs, a restore point is created roughly every half hour. On a bad day you lose at most the last half hour.
  • Before any big change — a new plugin, a version change, a new admin — take a manual backup from the panel. Manual backups are kept separately from the automatic one and are not deleted.
  • When something happens, read the console first: who ran which command is written there. Why the server shut down is stated in one line in the History section.

Bans: the name or the connection?

A name ban blocks the person; an IP ban blocks that connection. You issue an IP ban by typing the address into the Bans tab. An IP ban is a last resort: it also affects other players connecting from the same house. It makes sense when the same person keeps returning under new names — not on a first complaint.

If you banned someone by mistake you can remove them from the same list; the ban list keeps the reason and the date.

What to set up, by situation

  • Just you and your friends: whitelist on, enforce on, OP only for you. No plugin needed.
  • A small community: whitelist on, one or two people at a lower permission level, region protection at spawn.
  • Open to everyone: whitelist off; keep order with a permission plugin, region protection and the ban list. Take manual backups more often.

Common mistakes

  • Filling the whitelist and never turning on the switch in Settings.
  • Granting permanent OP for temporary help and forgetting to take it back.
  • Editing ops.json or whitelist.json by hand while the server runs — Minecraft holds those lists in memory and writes over the file, so your change is lost.
  • Sharing the address somewhere public while leaving the whitelist off.
  • Not taking a manual backup before a big change.