Minecraft Bedrock Dedicated Server: Cross-Play in 14 Steps [2026]

Running your own Minecraft server sounds simple until someone on an Xbox, someone on an iPhone, and someone on a gaming PC all try to join the same world and only the PC player gets in. That gap between Bedrock Edition and Java Edition trips up more self-hosters than port forwarding ever does. This tutorial walks through building a Bedrock Dedicated Server (BDS) that actually accepts every platform Mojang supports, plus the Geyser and Floodgate bridge that lets Java players into the same world if you decide you want that too.

By the end you will have a working server on Windows or Ubuntu Linux, a router configured for the right ports, an allowlist that does not lock out your own friends, and a cross-play bridge tested from at least two platforms. The whole build takes about 90 minutes if your router cooperates, longer if it does not.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

Why Bedrock, Not Java, Is the Cross-Play Answer

Minecraft ships as two codebases that do not speak the same network protocol. Java Edition runs on desktop and historically powered most modded and plugin-driven servers. Bedrock Edition is the version installed on Windows 10/11, Xbox, PlayStation, Nintendo Switch, iOS, Android, and Amazon devices, and it is the only edition that natively supports console and mobile players joining the same world together. If your friend group spans a PlayStation, a Chromebook, and a gaming PC, a Bedrock Dedicated Server is the path of least resistance, because every one of those clients can connect to the same BDS instance without a translation layer.

Java servers can still take Bedrock players, but only through a bridge plugin called Geyser, which we cover later in this guide for readers who already run a Paper or Spigot server and do not want to migrate. For a new build, though, starting with the official BDS binary from Mojang is the simpler route, and it is also free, unlike Realms.

Cross-play also matters more now than it did a few years ago, since the newest consoles and handhelds all ship with Bedrock Edition as the default. A Nintendo Switch 2 player, a Steam Deck player running SteamOS, and a PlayStation 5 player can all land in the same Bedrock world without anyone touching a command line, as long as the server owner got the underlying setup right. That is the entire point of self-hosting a Bedrock Dedicated Server instead of defaulting to a single-platform Java install: one binary, one config file, every platform Mojang ships for. This guide sits alongside tech-insider.org’s broader gaming setup coverage, which includes other self-hosted and cloud server builds for readers who want full control over where their game sessions run.

Realms vs. Self-Hosted BDS vs. Managed Hosting

Before touching a terminal, it is worth being clear-eyed about which of the three common paths actually fits your group, since switching later means migrating a world. Mojang’s own Realms service is the simplest option: it is fully managed, requires no port forwarding, and supports Bedrock cross-play out of the box, but it caps the player count, limits server-side customization, and comes with its own subscription cost on top of whatever you are already paying for Minecraft. Self-hosting a Bedrock Dedicated Server, the focus of this tutorial, gives you full control over server.properties, permissions, and add-ons at no ongoing cost beyond electricity, but it depends on your home internet staying up and a machine staying powered on. Managed third-party hosting splits the difference: you get 24/7 uptime and someone else’s hardware, but you pay a recurring fee and give up some low-level control compared with running the binary yourself.

Option	Uptime	Cost	Control	Best For
Mojang Realms	Managed, always on	Subscription fee	Low (limited settings)	Casual groups wanting zero setup
Self-hosted BDS	Depends on your hardware/internet	Free (electricity only)	Full	Technical users, LAN-style groups, this tutorial
Managed hosting (Apex, PebbleHost, etc.)	Managed, always on	$1-$8+/mo depending on plan	Medium-high	Groups wanting uptime without self-hosting

This tutorial focuses on the self-hosted path because it is the one with the most moving parts and the most places things go wrong, which also makes it the one readers most often get stuck on. If you decide a managed host fits better, most of the configuration file concepts below (server.properties, allowlist.json, permissions.json) still apply; the host’s control panel just handles the port forwarding and uptime for you.

Prerequisites and System Requirements

Mojang’s official download page lists modest minimums for Bedrock Dedicated Server: an Intel Core i3-3210 or AMD A8-7600 APU (or equivalent), 4 GB of RAM, and 180 MB to 1 GB of free disk space. Those numbers get a small server with a handful of players running, but they leave no headroom for world growth, backups, or add-ons. Here is what to actually budget.

Component	Mojang Minimum	Recommended for 5-10 Players	Recommended for 10-20 Players
CPU	Core i3-3210 / A8-7600	4-core modern CPU, 3.0 GHz+	6-core modern CPU, 3.5 GHz+
RAM	4 GB	8 GB	16 GB
Storage	180 MB – 1 GB	20 GB SSD	50 GB SSD
OS	Ubuntu 22.04 LTS+ or Windows 10 build 15063+	Ubuntu 22.04/24.04 LTS	Ubuntu 24.04 LTS
Network	Broadband	Stable upload 10+ Mbps	Stable upload 25+ Mbps

On Linux, Mojang officially supports only Ubuntu 22.04 LTS or later for Bedrock Dedicated Server. Other distributions often work in practice, but if something breaks you are on your own for support. On Windows, you need 64-bit Windows 10 build 15063 or later, or Windows Server 2016 or later. You will also need:

• Administrator or root access to the host machine
• Access to your router’s admin panel for port forwarding, or a cloud VM with a public IP
• A Microsoft/Xbox account for every player you plan to allowlist
• Roughly 90 minutes for the full setup, longer with network troubleshooting

Step 1: Choose Self-Hosting or a Paid Host

Before installing anything, decide whether you are self-hosting on a spare PC or renting from a managed provider. Self-hosting is free beyond electricity and gives full control, but it means your server goes offline when your PC sleeps or your ISP drops. A managed host keeps the server running 24/7 and handles backups, at a monthly cost. Current listed starting prices from several providers, gathered in October 2026, give a sense of the range.

Host	Starting Price	Bedrock Support	Notes
Hostinger	$6.99/mo (24-month term)	Yes, 4-32 GB plans	Price renews higher after promo term
Apex Hosting	$7.99/mo entry tier	Yes	Managed via McMyAdmin panel
PebbleHost	From $1/GB	Yes, one-click Bedrock install	Budget-tier plans available
BisectHosting	From roughly $6/mo (varies by plan)	Yes	Separate Bedrock-optimized plans

Pricing changes often and varies by billing term, RAM tier, and regional data center, so treat this table as a starting point and check each provider’s checkout page before buying. The rest of this tutorial focuses on self-hosting, since that is where most of the setup pitfalls actually live; renting from a managed host skips Steps 2 through 6 entirely. If you are instead building a game rather than hosting one for friends, the backend considerations are different; see our guides on setting up a Nakama game server or Amazon GameLift for developer-facing multiplayer infrastructure.

Step 2: Download the Official Bedrock Dedicated Server

Go to Mojang’s official Bedrock Dedicated Server download page and grab the build for your OS. Always download directly from minecraft.net; third-party mirrors are a common source of tampered server binaries. Stable builds track Mojang’s game releases closely: Minecraft Bedrock Edition 26.40 was published in August 2026, and Bedrock 26.60 is reportedly planned for October 27, 2026, a release tied to the move from RakNet to NetherNet. Check the download page for the current build number before you install. Do not install a preview or release-candidate build, such as Minecraft Preview 26.70.21 from October 20, 2026, unless you specifically want to test upcoming features and can tolerate occasional regressions.

# On Ubuntu, after downloading the zip from minecraft.net
mkdir -p ~/bedrock-server
cd ~/bedrock-server
unzip bedrock-server-*.zip
chmod +x bedrock_server
sudo apt update && sudo apt install -y libcurl4
./bedrock_server

On Windows, extract the downloaded zip to a dedicated folder like C:\BedrockServer, then double-click bedrock_server.exe. The first launch creates a worlds folder, a server.properties file, and a permissions.json file in that same directory. Leave the console window open; closing it stops the server.

Step 3: Configure server.properties

Open server.properties in a text editor while the server is stopped. This file controls nearly everything about how players connect and what they can do once inside. The settings that cause the most confusion are server-port, online-mode, and max-players. The content-log-file-enabled line in the example below is more dependable than it used to be, because Mojang’s 26.40 update fixed a BDS logging bug in August 2026 so that enabled content logs now create files.

server-name=My Cross-Play World
gamemode=survival
difficulty=normal
allow-cheats=false
max-players=10
online-mode=true
server-port=19132
server-portv6=19133
view-distance=32
tick-distance=4
level-name=Bedrock level
default-player-permission-level=member
texturepack-required=false
content-log-file-enabled=false

Keep online-mode set to true. This enables Xbox Live authentication, which is mandatory for every console and mobile player (they cannot connect without it). Setting it to false is sometimes suggested for LAN-only testing, but it will lock out every Xbox, PlayStation, and Switch player on your list, so only disable it for a quick local-network test and switch it back before inviting anyone remotely.

Step 4: Forward the Right Ports on Your Router

Bedrock Dedicated Server listens on UDP port 19132 by default, with 19133 used for IPv6. This is the single most common point of failure in a self-hosted build: forwarding the wrong protocol (TCP instead of UDP), forwarding to the wrong internal IP after a DHCP lease change, or running behind double-NAT/CGNAT from your ISP will all make the server look offline to anyone outside your home network.

• Log into your router’s admin panel (usually 192.168.0.1 or 192.168.1.1)
• Find the Port Forwarding or Virtual Server section
• Create a rule forwarding external UDP 19132 to your server machine’s local IP, port 19132
• Assign your server machine a static local IP or a DHCP reservation so the forwarding rule does not break after a reboot
• On the host machine’s firewall, allow inbound UDP 19132 (and 19133 if using IPv6)

# Ubuntu firewall rule for Bedrock
sudo ufw allow 19132/udp
sudo ufw allow 19133/udp
sudo ufw status

If your ISP uses CGNAT (common on many mobile and some residential connections), port forwarding will not work at all because you do not have a true public IP. A reverse-tunnel service or a small cloud VM acting as a relay is the usual workaround in that case.

Some self-hosters skip router-level port forwarding entirely by putting every player on a private mesh VPN instead, using a tool like Tailscale or a similar WireGuard-based overlay network, the same approach used in self-hosted cloud gaming setups that pair Sunshine and Moonlight with Tailscale. Each player installs the VPN client, joins the same private network, and connects to the server using its mesh IP address rather than a public one. This sidesteps CGNAT and router configuration completely, at the cost of every player needing to install and run the VPN client before launching Minecraft. For a small, trusted friend group this trade-off is often worth it, especially if your ISP does not hand out a usable public IP at all.

Step 5: Set Up the Allowlist Without Locking Out Your Friends

The allowlist (what older guides call a whitelist) restricts who can join by Xbox Live gamertag or Microsoft account identity. Enable it in server.properties, then add entries in allowlist.json. The most common mistake here is a typo in the gamertag or adding a stale identity that no longer matches the player’s current account.

{
 "allowlist": true
}

// allowlist.json
[
 { "name": "YourGamertagHere" },
 { "name": "FriendGamertagHere" }
]

Restart the server after editing allowlist.json; it is not hot-reloaded reliably in every build, and leaving the old server process running is a frequent source of “why can’t my friend join” reports. Separately, adding someone as an operator in permissions.json does not automatically let them past an enabled allowlist – the two systems are independent, and testing with a non-owner account before launch catches this early.

Step 6: Connect From Each Platform

With the server running and ports forwarded, every supported platform connects the same basic way: open Minecraft, go to the Servers tab, choose Add Server, and enter your public IP address and port 19132. Windows, Android, iOS, Xbox, PlayStation, and Switch all use this identical flow since they all run Bedrock Edition under the hood.

Platform	Edition	Connection Method
Windows 10/11	Bedrock	Servers tab, Add Server, IP + port 19132
Xbox Series X/S, One	Bedrock	Servers tab, Add Server, IP + port 19132
PlayStation 4/5	Bedrock	Servers tab, Add Server, IP + port 19132
Nintendo Switch / Switch 2	Bedrock	Servers tab, Add Server, IP + port 19132
iOS / Android	Bedrock	Servers tab, Add Server, IP + port 19132
Windows/Mac/Linux Java	Java	Requires Geyser bridge (Step 8), port 25565

For local network testing before you open ports to the internet, use your server machine’s local IP (something like 192.168.1.50) instead of your public IP. This confirms the server itself works before you start debugging router configuration.

Step 7: Decide Whether You Need Geyser and Floodgate

Everything above gets Bedrock cross-play working between consoles, mobile, and Windows. It does not let Java Edition players join, because Java and Bedrock are separate network protocols. If you already run (or want to run) a Java server with plugins or mods, and still want Bedrock players to join it, that is what GeyserMC solves. Geyser is a translation layer that sits on a Java server (Paper, Spigot, or a proxy like Velocity) and lets Bedrock clients connect to it. As of October 2026, Geyser’s supported-versions page lists compatibility with Bedrock 26.30 through 26.52 and Java 26.2, and that range shifts with every Minecraft protocol update, so check the live compatibility page before building on a specific version.

Floodgate is the companion project that lets Bedrock players join a Geyser-enabled Java server without a full Java Edition account. According to GeyserMC’s Floodgate documentation, it installs as a plugin on Spigot, Paper and forks, BungeeCord, or Velocity, or as a Fabric mod – it is not compatible with a standalone Bedrock Dedicated Server, since BDS does not run plugins at all.

Step 8: Install Geyser and Floodgate on a Java Server

This step is only for readers running a Java Paper or Spigot server who want to add Bedrock players, not for a standalone BDS build. Download the Geyser-Spigot jar and the Floodgate jar from the official GeyserMC download page, which published a fresh build as recently as October 1, 2026.

# On your Paper/Spigot server
cd /path/to/server/plugins
wget https://download.geysermc.org/v2/projects/geyser/versions/latest/builds/latest/downloads/spigot -O Geyser-Spigot.jar
wget https://download.geysermc.org/v2/projects/floodgate/versions/latest/builds/latest/downloads/spigot -O floodgate-spigot.jar
# Restart the server once to generate config files
./start.sh

After the restart, edit plugins/Geyser-Spigot/config.yml to set the Bedrock listening port (commonly 19132, separate from your Java server’s 25565) and confirm the remote address points to localhost if Geyser runs on the same machine as the Java server. Floodgate requires no Microsoft account from Bedrock players, which is convenient for younger players without a full Microsoft account, but it also means those players join under a distinct linked identity rather than their Java username.

Step 9: Import an Existing World or Realm

If you already have a Bedrock world from a Realm subscription or a single-player save, you can move it to your new dedicated server instead of starting fresh. Export the world from the Minecraft client (world settings, then Export), then copy the resulting .mcworld file’s extracted contents into the worlds folder on your BDS install, matching the level-name value in server.properties.

# .mcworld files are just renamed zip archives
mv MyWorld.mcworld MyWorld.zip
unzip MyWorld.zip -d "~/bedrock-server/worlds/Bedrock level"

Back up the original world folder before overwriting anything. A failed import that corrupts the only copy of a world your friends have played on for months is one of the more painful mistakes in self-hosting, and it is entirely avoidable with a single copy command first.

Step 10: Keep the Server Running 24/7

A server that only runs while someone remembers to launch it is not much of a dedicated server. On Linux, wrap bedrock_server in a systemd service so it restarts automatically after a crash or reboot.

# /etc/systemd/system/bedrock.service
[Unit]
Description=Minecraft Bedrock Dedicated Server
After=network.target

[Service]
WorkingDirectory=/home/youruser/bedrock-server
ExecStart=/home/youruser/bedrock-server/bedrock_server
Restart=on-failure
User=youruser
LD_LIBRARY_PATH=.

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable bedrock.service
sudo systemctl start bedrock.service
sudo systemctl status bedrock.service

On Windows, use Task Scheduler to launch bedrock_server.exe at login, or install a lightweight wrapper like NSSM to run it as a proper Windows service. Either way, confirm the server actually survives a full host reboot before relying on it, not just a manual stop and restart.

Step 11: Automate Backups

World corruption, a bad add-on, or a griefing incident are all reasons to keep rolling backups, not just one. A simple cron job that archives the world folder nightly and keeps a week of history covers most home-server scenarios.

# crontab -e, runs nightly at 3am
0 3 * * * tar -czf /home/youruser/backups/world-$(date +\%F).tar.gz -C /home/youruser/bedrock-server/worlds "Bedrock level"
0 4 * * * find /home/youruser/backups -name "world-*.tar.gz" -mtime +7 -delete

Stopping the server briefly before the backup runs avoids copying a world file mid-write, which can produce a corrupted archive. A short save-and-pause window, even a few seconds, is cheap insurance against restoring a broken backup later.

Step 12: Harden Permissions and Operator Access

permissions.json controls who has operator, member, or visitor-level access, separate from the allowlist that controls who can connect at all. Set default-player-permission-level to member in server.properties so new joiners cannot immediately grief the world, and add trusted players individually to permissions.json with operator status only when needed.

[
 {
 "permission": "operator",
 "xuid": "2535XXXXXXXXXXX"
 },
 {
 "permission": "member",
 "xuid": "2535YYYYYYYYYYY"
 }
]

Granting operator access also enables cheats for that player by default in some configurations, which can affect in-game achievement eligibility. Test any permission change with a secondary account before applying it broadly, since the effects are not always obvious until someone actually tries to break a block they should not be able to reach.

Step 13: Install Behavior Packs and Resource Packs

Bedrock Dedicated Server does not support Java-style plugins, but it does support behavior packs and resource packs, which can add custom items, mobs, recipes, and textures without touching the core game. Behavior and resource packs both live in dedicated folders alongside your worlds folder, and the server reads which ones are active from two small JSON manifests.

# Folder layout for add-ons
~/bedrock-server/
├── behavior_packs/
│ └── my-pack/
├── resource_packs/
│ └── my-pack/
├── worlds/
│ └── Bedrock level/
│ ├── world_behavior_packs.json
│ └── world_resource_packs.json

// world_behavior_packs.json
[
 {
 "pack_id": "your-pack-uuid-here",
 "version": [1, 0, 0]
 }
]

Every pack ships with its own manifest.json containing a UUID; copy that UUID into world_behavior_packs.json or world_resource_packs.json exactly, since a mismatched UUID is the single most common reason a pack silently fails to load. Restart the server after adding a pack, and check the server log for a loading error before assuming it worked. Resource-pack-only add-ons (textures, sounds) apply automatically to connecting clients; behavior packs that change gameplay logic require every connecting player to accept the pack download prompt the first time they join.

Securing Your Server Against Griefers and Abuse

A server reachable from the public internet, even a small one for a friend group, is still a server reachable from the public internet. Scanners and bots occasionally probe open Minecraft ports looking for unprotected worlds, and an allowlist alone only stops players from entering, not from trying. A few extra steps keep a home-hosted Bedrock server reasonably safe without needing enterprise security tooling.

• Keep the allowlist enabled permanently on any server exposed to the internet, not just during setup. Disabling it “just for a minute” to let an unlisted friend in is the most common way a server ends up open to strangers.
• Avoid exposing your router’s admin panel to the internet while you have the Minecraft port forwarded; the two are unrelated services, but a compromised router defeats every other precaution.
• Rotate out stale entries in allowlist.json and permissions.json periodically, especially after a falling-out with a former player who still has operator access.
• Keep backups off the same drive as the live world when possible, so a ransomware-style incident or disk failure on the host machine does not also destroy the recovery copy.
• Watch the server log for repeated failed connection attempts from the same IP, which can indicate a bot scanning your port rather than a legitimate player having trouble.

None of this requires a dedicated firewall appliance for a small home server, but it is worth treating the Bedrock port the same way you would treat any other port forwarded out of your home network: minimal exposure, logging, and a habit of checking who actually has access every so often. Readers who already run network-level ad and tracker blocking at home, such as a Pi-hole install, can apply the same “only expose what you have to” mindset to the Minecraft port.

Step 14: Monitor, Update, and Troubleshoot Ongoing Issues

Once the server is live, the remaining work is keeping it updated and watching for the handful of issues that come up repeatedly in self-hosted Bedrock and Geyser setups. Download new BDS builds directly from Mojang’s official page rather than auto-updating scripts from third parties, and back up the world before every version bump. Version bumps can change behavior beyond the version number: Mojang released Bedrock 26.50 on September 15, 2026, and NetherNet became BDS’s default transport with that release, so the network layer you read about in older guides may no longer match what your server runs. If you run Geyser on a Java server, update it whenever Mojang ships a Minecraft version bump, since Geyser’s supported Bedrock-to-Java range shifts with nearly every release.

Version Changes That Affect Existing Add-ons and Worlds

Add-on authors should check their entity files after upgrading, because Mojang’s Bedrock Edition 26.40 notes made schemas for several actor components and goals stricter when parsing, and an entity json that has invalid data will now fail to load in versions 1.26.40 and newer. The same notes changed the actor goal minecraft:behavior.ranged_attack so it takes a float range for attack_interval instead of attack_interval_min and attack_interval_max for versions 1.26.40 and newer. A behavior pack that loaded without complaint on an older build can therefore stop loading, which is why the server log check described in Step 13 matters after every version bump.

Scripting packs are affected as well. The 26.40 notes released @minecraft/server version 2.9.0 and added @minecraft/server version 2.10.0-beta, and they moved Block.getParts and the PlayerStartBreakingBlockAfterEvent class out of beta into scripts version 2.9.0. If a pack depends on a beta module, pin the version in its manifest and test it on a copy of the world first. Worlds can be affected too, since the same notes fixed an issue where a book and quill from pre-26.30 worlds freezes the game (MCPE-239753).

Preview builds deserve a separate rule. Microsoft’s documentation suggests keeping multiple copies of Dedicated Server on one machine for testing purposes, using subdirectories for different versions, and that habit pays off here. Minecraft Preview 26.70.21 is a Bedrock Edition Preview changelog, not confirmation of a released Bedrock Dedicated Server version, so keep the production server on a stable build and try preview features only in a throwaway copy of the world.

Five Common Pitfalls When Self-Hosting a Bedrock Server

• Forwarding TCP instead of UDP. Bedrock uses UDP exclusively on port 19132. A TCP-only forwarding rule looks correct in the router panel but silently fails to pass any Bedrock traffic.
• Setting online-mode to false and leaving it there. This disables Xbox Live authentication entirely, which blocks every console and mobile player, not just the ones you intended to test locally.
• Not reserving a static local IP for the server machine. A router-issued DHCP lease can change after a reboot, silently breaking a previously working port-forward rule days later with no obvious error message.
• Confusing the allowlist with operator permissions. Adding a friend as an operator does nothing if the allowlist is enabled and their gamertag is not also added there, and vice versa.
• Running Geyser on an outdated Minecraft version. Because Geyser’s Bedrock-to-Java compatibility window moves with every Mojang release, an old Geyser build on a freshly updated Java server can silently reject newer Bedrock clients.

Expected Output: What a Working Setup Looks Like

When everything is configured correctly, the server console shows a line confirming the IPv4 and IPv6 listening ports on startup, similar to this:

[INFO] Server started.
[INFO] IPv4 supported, port: 19132
[INFO] IPv6 supported, port: 19133
[INFO] Level Name: Bedrock level
[INFO] Game mode: Survival
[INFO] Difficulty: NORMAL

From a second device on the same network, the Servers tab should show your world with a green signal bar and the correct player count within a few seconds of adding it. From outside the network (a friend’s house, or mobile data), the same server entry should connect using your public IP rather than the local one, confirming the port forward is actually working end to end.

Troubleshooting Guide: Eight Common Problems and Fixes

Problem	Likely Cause	Fix
Server shows offline to outside players	Port forwarded as TCP, or router rule points to stale local IP	Confirm UDP 19132, re-check DHCP reservation
“You do not have permission to join” on console	Allowlist enabled, gamertag missing or mistyped	Add exact gamertag to allowlist.json, restart server
Local LAN players connect, remote players cannot	Port forward missing or CGNAT on ISP side	Verify forwarding rule; consider a relay/tunnel if on CGNAT
Bedrock players cannot join a Java server	Geyser/Floodgate not installed, or ports misconfigured	Install Geyser-Spigot and Floodgate, verify config.yml ports
World fails to load after update	Mismatched level format between old and new BDS build	Restore from backup, update BDS gradually, test on a copy first
Operator commands do nothing for a player	Allowlist and permissions.json are separate systems	Add the player to both, not just one
Server crashes repeatedly under load	Insufficient RAM or too high a view-distance setting	Lower view-distance/tick-distance, add RAM
Backup archive is corrupted	Backup ran while the world was actively being written	Pause saves briefly before archiving, or stop server during backup

Advanced Tips for a More Stable Cross-Play Server

Once the basic server is stable, a few refinements make a meaningful difference for a group that plays regularly. Lowering tick-distance from the default can noticeably reduce CPU load on modest hardware without most players noticing a gameplay difference, since it only affects how far redstone and mob simulation extends beyond the player’s render distance. If your group is large enough to need voice chat alongside text, a dedicated Discord server with a bot that posts join/leave events from the Bedrock server log keeps everyone aware of who is online without needing to tab into the game.

For anyone running the Geyser bridge, pin a specific Geyser build in your server startup script rather than always pulling “latest,” since a same-day update on Mojang’s side can occasionally outpace Geyser’s own compatibility patch by a few hours. Testing the pinned build in a second, disposable server instance before rolling it into production avoids an outage during peak play hours.

Finally, consider separating your allowlist-enabled public-facing server from a private test server running on a different port on the same machine. This lets you validate add-ons, permission changes, or a Geyser update against a throwaway world copy before touching the server your friends are actually building on.

Tuning Performance for Larger Groups

As a server grows past five or six regular players, world simulation becomes the main cost, not network bandwidth. Three settings in server.properties matter most for keeping tick rate stable: view-distance controls how far terrain renders to each player, tick-distance controls how far redstone, crops, and mob AI actually simulate around each player, and max-threads (where supported by your build) controls how many CPU threads the server spreads simulation work across. Lowering tick-distance from a high value to something in the 4-6 range is usually the single biggest performance win available, since most players cannot visually tell the difference between full simulation distance and a slightly reduced one, but the CPU absolutely can. Mojang is also adding tooling for this: optional dedicated-server performance warnings with configurable thresholds and cooldowns arrived in Bedrock Preview on October 13, 2026, which should make it easier to spot an overloaded tick before players notice lag, though preview features are not guaranteed to ship unchanged.

If the server still struggles once those settings are reasonable, the next lever is usually RAM headroom rather than CPU clock speed, since world data, entity tracking, and chunk caching all compete for the same memory pool. Watching free memory during peak play hours with a simple tool like htop on Linux or Task Manager on Windows tells you quickly whether you are CPU-bound or memory-bound, which determines whether upgrading RAM or upgrading the CPU is the better next purchase.

Complete Working Project: A Minimal Cross-Play Server Stack

Putting every step together, here is the full file layout for a self-hosted Ubuntu Bedrock server with systemd auto-restart and nightly backups, ready to copy as a starting template.

/home/youruser/bedrock-server/
├── bedrock_server # official Mojang binary
├── server.properties # core config from Step 3
├── allowlist.json # Step 5
├── permissions.json # Step 12
└── worlds/
 └── Bedrock level/

/etc/systemd/system/bedrock.service # Step 10
/home/youruser/backups/ # Step 11 output

# Crontab entries
0 3 * * * tar -czf /home/youruser/backups/world-$(date +\%F).tar.gz -C /home/youruser/bedrock-server/worlds "Bedrock level"
0 4 * * * find /home/youruser/backups -name "world-*.tar.gz" -mtime +7 -delete

# Router
Port forward: UDP 19132 -> server local IP, port 19132
Static DHCP reservation for server machine's MAC address

# Optional Java cross-play bridge (Step 8)
/path/to/java-server/plugins/
├── Geyser-Spigot.jar
└── floodgate-spigot.jar

This layout is enough to run a small, stable cross-play world for a friend group spanning consoles, mobile, and PC, with automated recovery from both crashes and accidental world corruption.

Frequently Asked Questions

Do I need to buy Minecraft separately for a Bedrock Dedicated Server?

No. The Bedrock Dedicated Server software itself is free to download from Mojang’s official site. Only the players connecting to it need to own Minecraft on their respective platform.

Can Xbox and PlayStation players join the same Bedrock server?

Yes. Xbox, PlayStation, Nintendo Switch, Windows, iOS, and Android are all Bedrock Edition, and all connect to a standalone Bedrock Dedicated Server the same way, through the Servers tab with your server’s IP and port 19132.

Why can’t my Java Edition friend join my Bedrock server directly?

Java and Bedrock use different network protocols and a standalone BDS instance cannot accept Java clients natively. The workaround is running a Java server (not Bedrock) with the Geyser plugin installed, which lets Bedrock players join the Java world instead.

What port does a Bedrock Dedicated Server use by default?

UDP port 19132 for IPv4, and UDP port 19133 for IPv6. Both must be forwarded as UDP, not TCP, for remote players to connect.

How much RAM do I actually need for a small Bedrock server?

Mojang’s official minimum is 4 GB, but that leaves little margin. For a stable server with 5 to 10 regular players, 8 GB is a safer target once you account for world growth and background processes on the host machine.

Does Floodgate let Bedrock players join without a Microsoft account?

Yes, that is Floodgate’s specific purpose on a Geyser-enabled Java server. It lets Bedrock clients join without going through a full Java Edition login, which is useful for younger players who do not have a separate Microsoft account tied to Java Edition.

Can I move my existing Realm world to a self-hosted server?

Yes. Export the world as a .mcworld file from the Minecraft client, then extract its contents (it is a renamed zip archive) into your Bedrock Dedicated Server’s worlds folder, matching the level-name entry in server.properties.

Is a managed hosting plan worth it instead of self-hosting?

It depends on how much uptime and convenience you need. Self-hosting is free aside from electricity but depends on your home internet and a machine staying on. A managed host starting around $6 to $8 a month, depending on the provider and plan, removes the uptime and backup burden but adds a recurring cost.

Why does my server disconnect players after a world update?

This usually happens when the installed Bedrock Dedicated Server build is older or newer than the version a connecting client is running. Mojang periodically bumps the protocol version alongside game updates, and a mismatched client and server version will refuse to connect or will disconnect shortly after joining. Keeping the server binary current with the client version resolves most of these disconnects.

Can I run Bedrock and Java servers on the same machine at the same time?

Yes, as long as they use different ports and the machine has enough RAM and CPU headroom for both. A standalone BDS instance on UDP 19132 and a separate Java server on TCP 25565 do not conflict with each other, though running both at once effectively doubles your resource budget, so check your hardware against the requirements table for each edition before combining them on one box. Many self-hosters who want the best of both worlds end up running the Java server with Geyser and Floodgate instead, since that collapses everything into a single process rather than managing two separate server binaries, two separate worlds, and two separate backup schedules on the same hardware.