Plan your Minecraft server properlyFrom your project to the right plan

Published on October 20, 2026

Decision 1: Java or Bedrock

The first fork determines everything else. Java is the edition with the large plugin and mod ecosystem, Bedrock the one for console, mobile and the Windows edition.

If console players are to join in, that does not necessarily mean Bedrock: a Java server with Geyser lets in Bedrock clients while keeping the variety of plugins. Details in Java vs. Bedrock and Set up crossplay.

Decision 2: the server software

It determines what is possible in the first place - and thus the basic requirement:

Rule of thumb: plugins are cheap, mods are expensive. If you only want administration, ranks and protection features, Paper is much more economical than a modpack.

Decision 3: extensions

The biggest single lever on the requirement. The difference between a Paper server with ten plugins and a modpack with 200 mods is greater than any other factor.

• Plugins run only on the server side; players install nothing.
• Mods change the game and must match on the client too.
• Modpacks usually state their own RAM recommendation - it takes precedence over all rules of thumb.

Installation is described in Install plugins & mods; the guideline values are in How much RAM does a Minecraft server need?.

Decision 4: view distance and play style

The often overlooked point: how you play changes the requirement considerably.

• Everyone builds in one place - cheap, few chunks active at the same time.
• Everyone explores alone - expensive, many world areas loaded in parallel.
• High view-distance - the effort grows quadratically with the value.
• Large farms - cost permanently, even when nobody is standing next to them.

Both distances are set in server.properties. How they affect the tick rate is shown in Lag and TPS.

What you do not need to plan for: the slot count

With many providers, the number of players is the actual price lever: every additional slot costs extra. With us, this calculation does not apply - slots are unlimited; you pay for RAM, storage and performance. So the limit is set not by the plan, but by memory.

For planning, this changes the key question. It is not "how many players is the plan enough for", but "what does this group do with the server". Ten people building together on one base cost less than five who swarm out in all directions and constantly generate new chunks.

You can still set your own limit: max-players in server.properties caps the number of simultaneous players, a whitelist determines who gets in at all. Both are decisions about the character of your server, not technical necessities.

Storage: the second value next to RAM

Memory gets all the attention in planning, while disk space is usually forgotten - yet it grows steadily and for completely different reasons:

• Exploration. Every chunk entered is stored permanently. A world therefore grows with the distances travelled, not with play time.
• Modpacks. They bring a considerable amount of data even before the first world.
• Multiple worlds. Every additional world takes up its own space - see Run multiple worlds.
• Backups. Copies you leave on the server count in full.

Against uncontrolled growth, a world border helps that limits the explorable area from the start - that makes sense even if there is enough space, because smaller worlds load and back up faster. Backups do not belong permanently on the same server anyway: you pull them to your computer via SFTP or the WebFTP file manager; the process is described in Create backups.

Four typical projects

The pragmatic advice: start small rather than big. A server that runs well and grows later is better than one that is paid for oversized from the start - and thanks to prepaid without a contract, switching costs you no commitment. The plans are on the Minecraft product page; with prices and the mapping by project, also in How much does a Minecraft server cost?.

What is easy to change later - and what is not

Not all four decisions carry the same weight. This ranking helps put the care where it pays off:

• The plan is the least critical decision. An upgrade or downgrade is possible at any time; world, plugins and configuration are kept. With a downgrade, however, the requirement must fit the smaller plan - a large modpack does not give its memory back.
• You change the view distance in a minute. It is in server.properties and takes effect after a restart. If it stutters, it is the first lever, not the plan - how it all hangs together is shown in Lag and TPS.
• The server software can be switched, but it takes preparation. From vanilla to Paper, the step is usually uncritical. Switching to Forge or Fabric brings new blocks into the world - and on the way back, exactly these blocks are missing.
• The edition can be switched, but the world cannot come along. You switch between Java and Bedrock in both directions in the game server panel under server type. Because Java worlds cannot simply be opened in Bedrock, and the same goes the other way round, the server is completely reinstalled in the process and all files are deleted. A switch therefore means a fresh start; more on this in Java vs. Bedrock.

In practice, this means: think twice about edition and software, only once about the plan. And if you bring an existing world, plan for it from the start - the move itself is straightforward, see Upload a world, but it largely determines version and software already.

How much memory a project needs in concrete terms and how to recognize during operation that it really is the bottleneck is covered in How much RAM does a Minecraft server need?. This page stays with the planning beforehand.

Frequently asked questions