Running as a service

The cleanest way to run a server around the clock - surviving crashes and host reboots - is as a long-lived Docker Compose service. The official endstone/endstone image bundles Bedrock Dedicated Server, Endstone, and an unprivileged service user. Everything the server reads and writes lives under /data, so you mount one folder and the rest is handled for you.

Try it with a one-off run

To kick the tires without writing any config:

docker run --rm -it \
  -p 19132:19132/udp \
  -p 19133:19133/udp \
  -v ./data:/data \
  endstone/endstone

This pulls the image, persists the server folder to ./data on your host, and exposes the game ports. For anything you intend to keep running, use Compose instead.

docker-compose.yml

name: endstone

services:
  endstone:
    image: endstone/endstone:latest
    container_name: endstone
    restart: unless-stopped

    # Keep STDIN open and allocate a TTY so the server console works
    # when you run `docker attach endstone`.
    stdin_open: true
    tty: true

    # Give the server time to save the world before it is killed.
    stop_grace_period: 15s

    ports:
      - "19132:19132/udp"  # IPv4 game port
      - "19133:19133/udp"  # IPv6 game port

    environment:
      PUID: 1000
      PGID: 1000
      TZ: UTC

    volumes:
      - ./data:/data

Start it detached

docker compose up -d

The -d flag runs the container in the background, so it keeps going after you close your terminal.

Stay up across crashes and reboots

The compose file sets:

restart: unless-stopped

With this policy Docker restarts the container automatically if the server crashes, and brings it back when the Docker daemon starts - so as long as Docker itself is enabled to start on boot, your server comes back up after a host reboot. The one exception is when you stop it yourself: a manual docker compose stop stays stopped until you start it again.

Data and persistence

The container runs the server out of /data, so the host folder you mount there is your server folder. Worlds, plugins, packs, and every config file live inside it:

./data/
  worlds/
  plugins/
  server.properties
  endstone.toml
  ...

Back up ./data (or just ./data/worlds) the same way you would a bare-metal install - see Backups.

Environment variables

The entrypoint remaps the service user to PUID/PGID and takes ownership of /data on startup, then drops privileges - so the container never runs the server as root.

Ports

The image exposes UDP 19132 (IPv4) and 19133 (IPv6). Map both. If you change server-port / server-portv6 in server.properties, update the published ports to match.

Use the server console

The compose file keeps stdin_open and tty on, so you can attach to the live console and type server commands (stop, allowlist add, op, ...):

docker attach endstone

To leave the console without stopping the server, detach with the escape sequence Ctrl-P then Ctrl-Q. Pressing Ctrl-C here would signal the server to shut down instead.

Watch the logs

docker compose logs -f

-f follows the log live. Drop it to dump the recent log and exit.

Stop cleanly

docker compose stop

The compose file's stop_grace_period: 15s gives the server time to save the world before the container is killed, so always stop it this way rather than killing the process. Use docker compose down to stop and remove the container (your ./data folder, and therefore your world, stays on disk).

Update the running service

docker compose pull
docker compose up -d

pull fetches the latest image; up -d recreates the container on the new version. On the next launch Endstone installs the matching Bedrock build in place - see Updating your server for what that involves and what it preserves.

macOS and ARM

BDS is x86-64 only. On Apple Silicon or ARM Linux, run the image through emulation by pinning the platform:

docker pull --platform linux/amd64 endstone/endstone

In Compose, add platform: linux/amd64 to the service. Emulation works but is noticeably slower than native amd64 hardware.