I’ve been getting asked to put this together for years including in official GitHub issues. I always knew it would be a great idea but it turned out even better than I expected. This image works great on all platforms including Raspberry Pi!
This is based off my Minecraft Bedrock Linux Dedicated Server scripts for Linux project. I’m going to release a version for the Java Minecraft edition as well so stay tuned for that.
The official GitHub repository is located here.
The official Docker Hub repository is located here.
If you are looking for the Java version of the Docker container it is located here. This is for the Bedrock edition of Minecraft.
You can also run my Geyser + Floodgate Java Minecraft Server container and Bedrock players will be able to connect to it!
It’s now possible to convert your worlds between Bedrock and Java versions. Check out my guide on Chunker here for more information.
Features
- Sets up the official Minecraft Bedrock Server (currently in alpha testing)
- Fully operational Minecraft Bedrock edition server in a couple of minutes
- Adds logging with timestamps to “logs” directory
- Multiarch Support – all Docker platforms supported including Raspberry Pi
- Automatic backups when container/server restarts
- Supports multiple instances — you can run multiple Bedrock servers on the same system
- Updates automatically to the latest or user-defined version when server is started
- Files stored in named Docker volume allowing for extremely easy access/editing and leveraging more advanced Docker features such as automatic volume backups
- *NEW* – Box64 support added for improved speeds on aarch64 (ARM 64 bit)
Usage
First you must create a named Docker volume. This can be done with:
docker volume create yourvolumename
Now you may launch the server and open the ports necessary with one of the following Docker launch commands.
With default ports:
docker run -it -v yourvolumename:/minecraft -p 19132:19132/udp -p 19132:19132 -p 19133:19133/udp -p 19133:19133 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
With custom ports:
docker run -it -v yourvolumename:/minecraft -p 12345:12345/udp -p 12345:12345 -p 12346:12346/udp -p 12346:12346 -e PortIPV4=12345 -e PortIPV6=12346 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
IPV4 only:
docker run -it -v yourvolumename:/minecraft -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
Configuration / Accessing Server Files
The server data is stored where Docker stores your volumes. This is typically a folder on the host OS that is shared and mounted with the container. I’ll give the usual locations here but if you’re having trouble just do some Googling for your exact platform and you should find where Docker is storing the volume files.
You can find your exact path by typing:
docker volume inspect yourvolumename
This will give you the fully qualified path to your volume like this:
{ "CreatedAt": "2022-05-09T21:08:34-06:00", "Driver": "local", "Labels": {}, "Mountpoint": "/var/lib/docker/volumes/yourvolumename/_data", "Name": "yourvolumename", "Options": {}, "Scope": "local" }
On Linux it’s typically available at:
/var/lib/docker/volumes/yourvolumename/_data
On Windows it’s at
C:\ProgramData\DockerDesktop
but may be located at something more like
\wsl$\docker-desktop-data\version-pack-data\community\docker\volumes\
if you are using WSL (Windows Subsystem for Linux).
On Mac it’s typically
~/Library/Containers/com.docker.docker/Data/vms/0/
If you are using Docker Desktop on Mac then you need to access the Docker VM with the following command first:
screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty
You can then normally access the Docker volumes using the path you found in the first step with docker volume inspect
Most people will want to edit server.properties. You can make the changes to the file and then restart the container to make them effective.
Backups are stored in the “backups” folder
Log files with timestamps are stored in the “logs” folder.
Version Override
In some scenarios you may want to run a specific version of the Bedrock server. That is now possible by using the “Version” environment variable:
-e Version=1.18.33.02
For example:
docker run -it -v yourvolumename:/minecraft -e Version=1.18.33.02 -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
This is useful if Microsoft hasn’t released versions of the client and dedicated server at the same time so you can match whichever version your players can connect with.
Clean Environment Variable
If the server is having trouble starting you can clean the downloads folder and force reinstallation of the latest version like this:
docker run -it -v yourvolumename:/minecraft -e Clean=Y -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
This is useful if a download corrupted or something modified your container contents as it will clear everything out and reinstall the latest Bedrock server fresh.
Disable Box64 (aarch64 only):
If you are having trouble running the dedicated server with Box64 support you can tell it to use QEMU instead with:
-e UseQEMU=Y
For example:
docker run -it -v yourvolumename:/minecraft -e UseQEMU=Y -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
TZ (timezone) Environment Variable
You can change the timezone from the default “America/Denver” to own timezone using this environment variable:
docker run -it -v yourvolumename:/minecraft -e TZ="America/Denver" -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
A list of Linux timezones is available here.
NoPermCheck Environment Variable
You can skip the permissions check (can be slow on very large servers) with the NoPermCheck environment variable:
docker run -it -v yourvolumename:/minecraft -e NoPermCheck="Y" -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
Troubleshooting Note – Oracle Virtual Machines
A very common problem people have with the Oracle Virtual Machine tutorials out there that typically show you how to use a free VM is that the VM is much more difficult to configure than just about any other product / offering out there.
It is because there are several steps you need to take to open the ports on the Oracle VM. You need to both:
- Set the ingress ports (TCP/UDP) in the Virtual Cloud Network (VCN) security list
- *and* set the ingress ports in a Network Security Group assigned to your instance
Both of these settings are typically required before you will be able to connect to your VM instance. This is purely configuration related and has nothing to do with the script or the Minecraft server itself.
I do not recommend this platform due to the configuration difficulty but the people who have gone through the pain of configuring an Oracle VM have had good experiences with it after that point. Just keep in mind it’s going to be a rough ride through the configuration for most people.
Troubleshooting Note – Hyper-V
There is a weird bug in Hyper-V that breaks UDP connections on the Minecraft server. The fix for this is that you have to use a Generation 1 VM with the Legacy LAN network driver.
There is a second fix that was shared by bpsimons here. For that fix you need to install ethtool first with sudo apt install ethtool. Next in your /etc/network/interfaces file add “offload-tx off” to the bottom as the issue appears to be with TX offloading.
Here’s an example:
# The primary network interface auto eth0 iface eth0 inet static address 192.168.1.5 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 offload-tx off
This can also be done non-persistently with the following ethtool command:
ethtool -K eth0 tx off
Additional Support
The comments section right here is the best place for support. The second best place is the GitHub issues section.
I will add additional documentation based on what problems people are running into / questions people are asking because right now I’m not really sure what those will be yet. Definitely let me know if you need any of these things!
Hey James,
I had your container running for a while now on my pi 4 and upgraded to a pi 5 now with Pi OS Bookworm. Sadly I get the following error on start:
Starting Minecraft server…
[2023-11-19 21:08:02] Error: PageSize configuration is wrong: configured with 4096, but got 16384
Is it somehow possible to make the container compatible with the new pi? I don’t quite understand what’s this pagesize stuff means.
Thanks for your time and work
Hey Basti,
That’s actually a compatibility issue with Box64. Can you try running it with:
-e UseQEMU=Y
on your startup line? This should make it use QEMU instead of Box64 and then it should load. Hopefully that helps!
Hi James!
Thank for your reply and also for all of this work to begin with. To be clear, that makes my entire line:
sudo docker run -it -e UseQEMU=Y -v minetest1:/minecraft -p 19132:19132/udp -p 19133:19133/udp -p 19133:19133 –restart unless-stopped 05jchambers/legendary-bedrock-container:latest
Correct? My docker volume is minetest1, obviously. Because then I get:
“qemu-x86_64-static: ./include/qemu/rcu.h:101: rcu_read_unlock: Assertion `p_rcu_reader->depth != 0′ failed.”
Maybe it’s better to use a different OS? Tbh I thought Docker was supposed to get around OS limitations but maybe I misunderstand.
Hey James! I just wanted to start by saying thanks for creating this blog/guide/repository or otherwise amazing resource for self-hosting a Minecraft Server!
It won’t come as a shock, but I’m a complete noob when it comes to most things linux, docker, and servers/networking in general. I’ve followed your standalone guide to get a server running on the Raspberry Pi 4, 8GB model and am very happy with the performance, given the system it’s running on.
I was hoping to use this guide, as well as your docker container to run a server on the new Raspberry Pi 5, because the standalone is having some weird issues with qemu (and I read that the containerd version has better performance). I think I’ve gotten the server running, but I can’t seem to figure out how to check on the system itself, and it doesn’t show up under the server section, even when I manually add it in.
Some of the things I’ve tried:
Added a server in the Minecraft Bedrock app, the server doesn’t show online
ran
sudo su
thencd /PiCraft:/var/lib/docker/volumes/PiCraft/_data
but the directory showed empty.I’ve looked around for a moment in the comments to make sure I wasn’t posting a repeat question, though I admittedly didn’t read every comment all the way through.
Thanks again,
Echo
Hey Echo Tree,
Welcome and thanks for the kind words! So can you try it like this:
cd /var/lib/docker/volumes/PiCraft/_data
In the original example it looks like you’re trying to use the same line that it uses to launch the container but the directory should just be /var/lib instead of /Picraft:/var/lib.
In that folder you should see files that look basically exactly the same as the standalone version. If there is nothing in there (definitely take a look at the server launch logs) then the usual reason for that is if it’s unable to connect to the server (usually DNS related issues within Docker on older systems).
Hopefully that helps!
Hey, so first of all, I’m not smart! I realized that I launched a container using your example command, and hadn’t changed the
yourvolumenamehere
argument to match my custom name, so I was looking in the wrong container.After figuring that out, I realized that the Raspberry Pi OS Lite (x64) distro has the same issue as one of the other users with the page size being incorrect, so I reflashed the OS to the Debian server x64 OS and it’s working well. On the Raspberry Pi 5 you see none of the lag the RPi4 shows, even with 5 players (I only have 5 devices to test with atm)
Hi James, Echo Tree,
I’m new to the Raspberry scene (and Linux, tbh), but I have Debian 12 (Bookworm) 64 bit on my shiny new 8GB Pi 5 and also get the page size error. I couldn’t find the other post that was mentioned though. Is this an OS incompatibility? Is there anything else I can do to get past this?
Hey Sander,
It’s an incompatibility with the Box64 version that is precompiled. Can you try:
-e UseQEMU=Y
on your startup line as well!
Sorry I see I replied to the wrong post, I had the same problem as that poster. Anyway, I end up with:
“qemu-x86_64-static: ./include/qemu/rcu.h:101: rcu_read_unlock: Assertion `p_rcu_reader->depth != 0′ failed.”
unfortunately. I may try to get an extra drive to flash a different OS I guess?
Hey Sander,
I would definitely try a different OS. So far it can’t run QEMU or Box64. It looks like the kernel is compiled with a non-default paging size at the very least.
Realistically to get it working on your OS you’d need to compile Box64/QEMU yourself so I would definitely try a different one!
Thanks James,
I went another route and tried the Java/Geyser container instead which started up right away. It seems to work great, except for small glitches where certain types of wood suddenly make the wrong types of planks and the like. And my kid doesn’t seem to mind he’s suddenly playing by Java rules, which I was worried about originally 🙂
Hey Sander,
That’s fantastic, that would have been my #1 recommendation for you as well. We have quite a crew of people who are running their Bedrock servers/environments in Java using Geyser and they’re quite happy with it. If you check out the comments on the posts about those containers you’ll see a lot of activity of people replacing their Bedrock servers with Geyser+Java.
It should be great. Enjoy and take care!
Hey James,
thanks for your great work! Really makes launching your own bedrock server to play on with family and friends a breeze.
Just trying to figure out an issue and wondering if you can help:
I am running your bedrock docker server on the free tier Oracle Cloud ARM64 instance and gave it the full 4 cores and 24 GB of RAM in hopes that it would suffice for a simple vanilla max 4-5 players experience. Monitoring server performance (through oracle metrics as well as htop on the server) seems to indicate that it is more than enough as CPU load peaks with around 30% when 3 or 4 Players are playing and RAM usage around 6 GB tops… Nevertheless we are struggling with frequent connection issues. Sometimes players seem to get (for lack of a better term) “out-of-sync” with the server. This shows some very strange effects on the clients, as they are still able to walk around but interaction with the environement is limited ( e.g. opening chests or picking up items is impossible). Ultimatively they are disconnected from the server (but only after a few minutes) or they may forcibly quit and rejoin to fix the issue. This happens randomly to all sort of clients on the server (tested with PC, PS4 and Switch) and seems to happen more frequent if more players are connected. But the logs show no indication of any issues nor does the server performance peak in those events. I have never experienced any connection issues like those on any minecraft server so I am wondering if it has something to do with the docker networking layer? It’s a wild guess but I am at a loss how to debug this issue as there is no client/server side error shown whatsoever.
Any help would be greatly appreciated and thanks again for all your work on this!
Hey holk,
I have a guess as to what is happening here. The issue is that the Minecraft server is mostly a “single-cored” server. While it does use some threading and offset some things to other threads the fact is that 90-95% of the things happening in the game are still running on a single core. You definitely have plenty of available RAM.
What that means is that for Minecraft servers (both Bedrock and Java) it’s better to have higher power single-core / per-core performance than it is to have multiple cores. I’m guessing that you’re hitting the limitations of the main CPU core that Oracle is using. With 4 cores then having your main game core pegged would show up as 25% in most task/process viewers. It won’t be able to utilize all of the other cores.
The other limitation you are hitting is probably the layer of emulation required for ARM64. The symptoms you’re describing of opening chests and picking up items being slow sounds like the main game thread is not keeping up. Running the server in the native ARM64 / x86_64 format (instead of ARM64) would eliminate this problem as well. I hate to suggest that though as your current setup is free but I wanted to explain that the emulation used for ARM will slow it down and make the CPU bottlenecking worse.
Hopefully that helps!
I recently got the container installed and started it using the ipv4 command. It appears that the server starts up ok, but I cannot connect to it from my local network. Any ideas what might be going on or how to begin troubleshooting? Thanks!
Hey Adam,
Great question! So if you can’t access it from your local network that would suggest a firewall to me. Do you have a distro that has ufw or firewalld installed? If it’s ufw it would be something like:
sudo ufw allow 19132
sudo ufw allow 19133
If you had said from outside your local network I would have immediately pointed to port forwarding but on the local network I’d imagine we have to be dealing with a OS-level firewall installed here. Hopefully that helps!
Thank you for the response! I was very confused as well since it was all on my local network with no Vlans or other complications. But it ended up just being the instance of Minecraft on one iPad. Everything worked great once I tried another iPad. Thanks again!
Hey Adam,
Beautiful, thanks for the update! I’ve actually heard of bugs on both iOS and Android where if it fails to connect to a server a single time it will always fail to connect unless you force close the app and launch it again.
I’m so glad you got yours going, enjoy and take care!
Hello, I am having an issue getting connected. The server seems to be running fine, however I cannot connect via port 25565 (Windows) or 19132 (Switch). I am trying to run this behind traefik so friends can just put in my url instead of my public ip. I am also running this in docker-compose as opposed to regular docker run.
Hey Popebacon,
So port 25565 is only used for the Java version. The ports you want are 19132 (IPV4) and 19133 (IPV6).
I’d imagine that Traefic is probably the issue. Can you connect locally with those ports? If it works locally but not over Traefic then it probably needs some additional network configuration. I’d test locally first though on those ports and make sure it’s working.
Hopefully that helps!
Hi James,
Really looking forward to trying out this docker method. Having a little trouble though.
Firstly, I ran into the connection issue that produces this output:
Checking for the latest version of Minecraft Bedrock server …
Unable to connect to update website (internet connection may be down). Skipping update …
Starting Minecraft server…
/bin/bash: line 1: ./bedrock_server: No such file or directory
I tried setting the DNS servers manually when running the docker container, to no avail. So, I downloaded the bedrock server manually and expanded it to my docker volume. I then run into some sort of system error though, which makes me think maybe it’s a docker issue:
Checking for the latest version of Minecraft Bedrock server …
Unable to connect to update website (internet connection may be down). Skipping update …
Starting Minecraft server…
terminate called after throwing an instance of ‘std::system_error’
what(): Operation not permitted
Any troubleshooting ideas would be most appreciated!
The command I’m using to run is this:
docker run -it -v minecraft_volume:/minecraft -e Clean=Y -p 19132:19132/udp -p 19132:19132 –dns=8.8.4.4 –restart unless-stopped 05jchambers/legendary-bedrock-c
ontainer:latest
Hey TBH,
This is a pretty common Docker DNS issue that comes up from time to time. To see what I mean type:
docker run -it alpine:latest ping google.com
You won’t be able to ping Google either because the DNS is not working inside your Docker. This is usually due to running an older operating system and not the latest release. For example Ubuntu 20.04, Debian 10 (Buster) and a lot of older flavors cause this issue. The fix is to simply install the latest version of the operating system typically.
Hopefully that helps!
Hi! Great docker, me and extended family using it for a while now. I had some issues first (because I’m new to the docker scene mostly), like I wanted the backups to end up at an archive HDD instead of being written to NVMe. Symbolic links apparently doesn’t work(?) with containers, so had to solve it by setting up another volume in docker-compose.yml which pointed where I wanted it – this works fine.
We’ve had some issues with the server crashing lately though, which has revealed a few things I’d like to look into.
First of all, I’d like to disable the backups completely – there’s really not any point of getting 10 backups of the same day just because the server is crashing. I’ll run my own backup once per day instead.
Setting the backup variable to 0 first writes the entire backup, and then deletes it, which feels … not ideal.
I tried to solve this by copying the start.sh script and having my local (very slightly modified) version of start.sh being the entrypoint instead, but couldn’t make it work. Don’t even know if it’s possible. 🙂
Also, are there any logs available? I can set content-log-file-enabled=true, but this supposedly only writes something when a resource/behavior pack is the issue, I’ve never seen any log from this.
I’m guessing it might be possible to write the output from the server into a file or something similar?
Again, thanks for great work! Hope someone might be able to help me.
Hey Sinuouser,
Great questions! So the best way to view the logs is just to use:
docker container ls
docker logs xxxx
The first command will give you the container ID and then you can use docker logs to view all of the output.
For setting the backups to 0 I’m sure I could update it at some point to not take one if it’s set to 0. The scripts are hardcoded in the container so what you’re doing would work if you rebuilt the container afterward.
The symbolic links not working is the first time someone has mentioned this but I’m not too surprised I suppose. The shared mount in Docker is probably trying to do a lower level or more direct usage of the filesystem which probably needs hard links instead of symbolic links. I think your volume solution is pretty smart as the Docker volume drivers are better equipped to deal with this.
I can guarantee that the crashing has nothing to do with the container but I don’t blame you for checking and discovering all of those things during your investigation. Some other tests you could do to confirm this (if you haven’t already) is simply take your server files and try running them with the standalone Minecraft server (Linux or Windows, doesn’t matter). It won’t make any difference unless you are running out of memory on the system or something like that. Another way is to simply start a clean server and test it for a little while (as long as it takes for the original one to crash). This is pretty common unfortunately and usually involves either buggy entities or corruption in the server data files.
Hopefully that helps!
Yeah I didn’t think the crashing was due to the container, as you said, just ran into the other “issues” when trying to figure out what was happening. 🙂
For posterity I found out what was causing the crashing… it was a redstone etho hopper clock crossing a chunk boundary (and maybe also a ticking area boundary) in a way that caused a piston and redstone block to be set in an errenous state. The redstone block could exist in two spots at once. Really weird.
Thanks a ton for the info! And yeah I think it’s not really common to mess around with containers and links – I’m just a control freak with the server and want everything exactly in the “right” place 😀
The next time I’m having an issue with the server now, I’ll know where to look.
Kind Regards
Hey Sinuouser,
Fantastic job tracking it down! It can be pretty hard to find the source of a lot of those problems. It definitely takes some serious investigation usually. That’s awesome that you found it!
Definitely don’t hesitate to stop by, I’m happy to help any time and thanks for sharing the info about how fixing the crash went!