Choose Bedrock resources around the world and settings your group will use, then verify that choice during a normal play session. A small player list does not always mean a light server: exploration, active farms, entities, add-ons, and distance settings all change the work a world asks the server to do. There is no reliable RAM-per-player number that guarantees a result for every seed and play style.
Begin with the creator’s recommendation
The current MaximusHost creator recommends 2–6 GB RAM and 1.5–4 vCPU. It currently allows 1–24 GB RAM and 1–8 vCPU. Treat those as a starting range rather than a promise about player capacity or latency. The live creator shows the available choices and current estimate for your account.
For a new, lightly configured world, start near the lower part of the recommendation if that matches your budget and expectations. If players will explore in different directions, use add-ons, or keep several active farms, allow more headroom and monitor the result. Do not pick the maximum “just in case” without a workload reason; that can raise the estimate without fixing a version or settings problem.
Understand what RAM and CPU do
RAM holds the server process and the world data it needs while chunks and entities are active. CPU time handles game ticks, chunk work, entities, and player activity. These resources interact, but they are not interchangeable. If CPU is consistently busy, adding RAM alone may not help. If memory pressure repeats, more CPU does not create extra memory headroom.
Use the manager’s Overview and Resources information while the world is active. Compare usage during ordinary play with the moments when players report trouble. A single spike during startup or when several players join is less useful than a repeated pattern during the same activity.
Settings have resource consequences
Bedrock exposes view distance and tick distance as separate settings. View distance affects how much surrounding terrain is sent to clients; tick distance affects how far gameplay continues simulating. Increasing either can change resource demand, and increasing tick distance can create more work for farms and other active systems.
Before changing either value, write down the current setting and make an owner backup. Change one value by a modest amount, save it, restart if the manager requires it, then repeat the same play test. If the result gets worse, restore the previous value before trying another adjustment. The Bedrock Properties documentation describes the supported controls.
Add-ons and world activity
Behavior packs, resource packs, entities, farms, and player exploration can add work or change how a world behaves. A new add-on can also create a compatibility issue that looks like poor performance. Check its Bedrock version requirements and test it with a backup before changing several packs at once.
Consider where players are going. A group building in one area may load fewer separate regions than the same group splitting up to explore. A farm that continues ticking within the configured simulation area may behave differently from a quiet base. Use your world’s actual pattern rather than assuming that all players contribute an equal fixed amount.
Decide whether to change allocation
Use this sequence when evaluating a resource change:
- Record the server version, resource allocation, and relevant distance or add-on settings.
- Observe RAM and CPU during a representative session and note when the problem occurs.
- Check the console for errors, version mismatch, or pack-loading failures.
- Change one likely cause: an allocation, a setting, or a content version.
- Repeat the same test before deciding whether to keep the change.
Repeated memory pressure can justify more RAM. Repeated CPU pressure may point to CPU demand, distance settings, or active world systems. If resources look comfortable but players cannot join, check client compatibility and server properties before buying more capacity. The Bedrock Overview guide explains where the manager displays live usage.
Reduce an allocation only after representative sessions remain comfortably below it. Leave headroom for exploration and group events; do not judge the whole world from an empty-server snapshot.
Estimate the cost
MaximusHost bills server resources through credits rather than a fixed Bedrock monthly package. The live calculator and creator are the sources for the current estimate; the estimate depends on the resources selected and expected running time. Review Billing & Credits for account and stopped-server details before planning a budget.
When ready, review Minecraft Bedrock hosting and use the creator’s current recommendation as a measured starting point. Revisit the allocation after you have data from your own world.
