Minecraft server commands: a console and operator cheat sheet

Most of what you need to run a Minecraft server is about twenty commands, and they behave slightly differently in the server console than they do in chat: no leading slash, no player position, and a permission level that is always the maximum. This is the reference for those twenty, plus the target selectors that turn one command into a hundred, the execute syntax that everything modern is built on, and the gamerules with their real defaults. It applies to a vanilla server and to Paper, which is what RE:NODE's Minecraft line runs; where Paper adds something useful it is marked.

The console is not a chat box#

The panel console is the server process's standard input. Whatever you type is handed to the server as a command directly, so the leading / that a player types in chat is not needed and on most builds is an error. Type list, not /list.

Three other things follow from that:

• The console is permission level 4 and cannot be demoted. It is not a player, so plugin permissions do not apply to it either. Anything a LuckPerms group denies, the console can still do. That makes it the way back in when you lock yourself out of your own permission tree - see the LuckPerms guide for the tree that gets you there.
• The console has a position, and it is not where you are. Commands run from the console execute at the spawn point of the overworld. @p therefore means "the player nearest spawn", not "the player nearest me", and @s is invalid because the console is not an entity. Name the player, or use execute as @a at @s run ....
• Command output is the console's output. Errors appear in the same stream as everything else, so a failed command scrolls past among the plugin chatter. Reading the console covers how to filter that.

When a command is wrong, the server prints the input back with a marker showing where it gave up:

Unknown or incomplete command, see below for errorgamemode creativ<--[HERE]

That marker is precise. If it points at a player name, the player is not online or the name is misspelled; if it points at the space after a complete-looking command, an argument is missing.

Operator levels and who can run what#

op <player> gives level 4 by default, which is everything. The levels exist anyway, they are stored per operator, and they are worth using.

Operators are stored in ops.json in the server root, and you can edit the level there directly with the server stopped:

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

Two server.properties keys control the defaults: op-permission-level (default 4) is the level /op hands out, and function-permission-level (default 2) is the level datapack functions and command blocks run at. enable-command-block is false by default, and leaving it that way is a reasonable security decision on a public server, because a command block is a level 2 command executor that any builder with the right permission can place. Every key in that file is covered in server.properties explained.

On a server with plugins, operator status is a blunt instrument that also bypasses plugin permission checks. The pattern that works is to de-op everybody and grant minecraft.command.<name> nodes instead - minecraft.command.gamemode, minecraft.command.time and so on - which is exactly the granularity operator levels do not give you.

The commands you will actually use#

A few more that are worth knowing exist: spreadplayers scatters a group at random within a radius, forceload add keeps a chunk loaded without a player, datapack list/enable/disable manages datapacks at runtime (the details are in the datapacks guide), and transfer <host> [port] on 1.20.5 and later moves a client to another server without them leaving the game. On 1.20.3 and later, tick freeze, tick step and tick rate <n> control the tick loop itself, which is a debugging tool rather than something to leave on.

Target selectors#

A selector replaces a player name and expands to zero or more targets.

Arguments go in square brackets, comma separated, and they are filters applied in order:

$ kill @e[type=minecraft:zombie,distance=..100]$ gamemode adventure @a[gamemode=survival]$ tp @a[tag=lobby] 0 70 0$ give @a[limit=1,sort=nearest,distance=..20] minecraft:bread 16$ effect give @a[scores={deaths=5..}] minecraft:weakness 60 0

Ranges use .. and are inclusive: 1..5 is one to five, ..64 is up to 64, 10.. is ten and above. A ! negates most arguments, and some arguments can appear more than once for an AND (tag=a,tag=b), while type and gamemode can only be repeated when negated.

Coordinates come in three forms. Absolute (100 64 -200), relative to the execution point (~ ~5 ~, meaning five blocks up), and local to the executor's facing (^ ^ ^5, meaning five blocks forward). Local coordinates need an entity to face something, so they do nothing useful from the console.

execute: the command that runs other commands#

execute changes who runs a command, where it runs, and whether it runs at all. Modern Minecraft administration is mostly this one command, and it chains: each clause modifies the context for the next.

$ execute as @a at @s run playsound minecraft:entity.experience_orb.pickup master @s$ execute in minecraft:the_nether run kill @e[type=item]$ execute as @a[gamemode=survival] at @s if block ~ ~-1 ~ minecraft:magma_block run effect give @s minecraft:fire_resistance 10 0 true$ execute store result score Steve health run data get entity Steve Health

The clauses worth learning:

• as <targets> changes the executor, so @s in the rest of the command means each of them in turn. It does not move the execution point.
• at <targets> moves the execution point to them. as @a at @s is the pair you want almost every time: run this once per player, at that player.
• positioned, rotated, facing, align, anchored fine-tune the point.
• in <dimension> switches to minecraft:overworld, minecraft:the_nether or minecraft:the_end.
• if and unless test a condition and stop the chain if it fails: if block, if blocks, if entity, if score, if data, if predicate, if dimension, if loaded, if biome.
• store result|success writes the command's numeric result into a score, an entity's NBT, a block, a bossbar or data storage.
• run is always last and takes the command to execute.

Because as @a iterates, one execute can be expensive. execute as @a at @s run fill ~-50 ~-50 ~-50 ~50 ~50 ~50 air on a busy server is a good way to freeze it.

Gamerules worth changing#

gamerule with no value prints the current setting. Values are stored in the world, not in server.properties, so they survive a reinstall of the server jar and do not survive a new world.

Newer versions add more, and a few of the entries above arrived in 1.19 or later, so gamerule with tab completion on your own server is the definitive list for your version.

Three of these have a real performance angle. randomTickSpeed multiplies the work done per chunk per tick, and people raise it for faster farms without connecting it to the TPS drop that follows. maxEntityCramming at 0 removes the only thing stopping a mob farm from stacking thousands of entities in one block. And spectatorsGenerateChunks set to false stops a spectator flying out into unexplored terrain and generating chunks the server then has to keep. If you are already chasing lag, why TPS drops and what to do is the wider version of this.

Paper's own commands#

Paper and Spigot add a handful that vanilla does not have, and they are the ones you will reach for when something is wrong.

• tps prints the tick rate over the last one, five and fifteen minutes. Twenty is the maximum; anything below about 19 is noticeable.
• mspt prints how long a tick actually takes, averaged and at the worst case. It is the more honest number, because TPS is capped at 20 no matter how much headroom is left. Under 50 ms means the server has room.
• plugins (or pl) lists plugins, green for enabled. version <plugin> gives the exact build.
• paper entity list counts entities per type per world, and paper mobcaps shows how close each category is to its spawn limit. Both answer "what is on this server that should not be".
• paper heap dumps memory usage per class, and paper dumpplugins writes a JSON description of every loaded plugin.
• spark profiler start and spark profiler stop produce a shareable profile. Timings was removed in Paper 1.21, and spark is the replacement; recent Paper builds include it. Reading the output is its own subject, covered in diagnosing lag with spark.

One Bukkit detail that saves an argument: plugins can register commands with the same name as a vanilla one, and the plugin wins. Prefixing with the namespace forces the original - minecraft:tp is always vanilla teleport, whatever EssentialsX has done to /tp. Aliases live in commands.yml in the server root if you want to change which one wins permanently.

Saving, stopping and backups#

The world is held in memory and written out periodically. Anything that ends the process without a save discards what is in memory, so these four commands matter more than their length suggests.

$ save-off$ save-all flush... copy the world folder ...$ save-on

save-off stops automatic saves and tells the server to hold writes; save-all flush forces everything to disk and waits for it rather than returning immediately; save-on resumes. That sequence gives you a consistent copy. Forgetting save-on is a classic: the server keeps running and never writes again until it restarts, and then it writes a lot at once.

stop is the only clean shutdown. It saves every world, disconnects players with a proper message, and lets plugins write their data - which matters, because an economy plugin that flushes on shutdown loses balances if you kill the process instead.

On RE:NODE the Stop and Restart buttons send that clean stop. The Schedules tab runs ordered tasks with delays on a cron expression, which is enough to build a safe backup window: a console command task running save-off, then save-all flush, a short delay, a backup task, then a console command running save-on. Backup slots are on every plan, backups are stored off the machine they protect, and restoring is a button. The other half of that sentence is the important one - a backup nobody has restored is a hypothesis, which backups that actually restore goes into properly.

One behaviour to know about: if a server reaches its memory limit the container is stopped and restarted clean rather than left to swap. That is a fast recovery, but it is an unclean stop, so it loses whatever was unsaved. On a large world, a shorter autosave interval and a weekly scheduled restart are cheap insurance.

For running commands from outside the panel there is RCON, enabled with enable-rcon=true, rcon.password and rcon.port (default 25575) in server.properties. It is a plaintext protocol with no rate limiting worth the name, so it should never be exposed to the internet - using RCON safely covers what to do instead.

FAQ#

Why does my command work in chat but not in the console?

Usually a selector. @s and @p depend on the executor's position, and the console executes at the overworld spawn with no entity of its own. Rewrite it as execute as @a at @s run ..., or name the player. The other common cause is the leading slash, which the console does not want.

How do I run a command as a player without being that player?

execute as <player> run <command> changes the executor but not the permission level - the command still runs with the console's level 4. That is the point: it is how you teleport someone, or run a plugin command in their context, without opping them.

Where are gamerules stored, and do they survive an update?

In level.dat inside the world folder, so they belong to the world. Updating the server jar keeps them; generating a new world resets every one to its default. If you have a set you always use, keep the gamerule lines in a text file next to your notes.

Can I schedule a command to run every night?

Yes, with the panel's Schedules tab: a cron expression, and a console command task. A daily say Restarting in 60 seconds followed by a delay and a restart action is the common pattern, and it is much better than a silent restart. Inside the game, datapack functions with schedule function can do timed work too.

What is the difference between /kill @e and /kill @e[type=item]?

kill @e kills every entity in loaded chunks, players included, which is almost never what anyone means. Always filter by type. kill @e[type=item] clears dropped items, and kill @e[type=item,nbt={Item:{id:"minecraft:cobblestone"}}] clears one kind, slowly.