Bedrock Server Software

The official Bedrock Dedicated Server (BDS), provided by Mojang for Windows and Linux, runs the exact same C++ game engine as the retail Bedrock client, stripped of its rendering and audio subsystems. Because it shares the core engine, BDS offers complete compatibility with standard Bedrock add-ons. Data-driven blocks, entities, items, loot tables, and the `@minecraft/server` Script API behave identically to a local world hosted by a player.

Unlike a client installation where packs are stored in the user's `com.mojang` directory, BDS reads packs directly from its own installation root. During startup, the server scans its `development_behavior_packs`, `behavior_packs`, `development_resource_packs`, and `resource_packs` folders, caching the `manifest.json` UUIDs and versions. However, placing a pack in these folders does not activate it automatically; you must explicitly bind the pack to the active world inside the `worlds/<level-name>/` directory.

In the wider multiplayer ecosystem, you will encounter two distinct categories of third-party software: clean-room rewrites and BDS wrappers. Clean-room implementations—such as PocketMine-MP, Nukkit, and Dragonfly—are written from scratch in languages like PHP, Java, or Go. They speak the Bedrock network protocol (RakNet) to communicate with clients, but they do not contain Mojang's C++ add-on engine. While these servers can send a resource pack to a connecting client so custom textures and geometries render, they generally cannot parse a Behaviour Pack. Custom components like `minecraft:destructible_by_mining`, Molang queries, and JavaScript files relying on `@minecraft/server` will be completely ignored unless you rewrite the logic in the server's native plugin language.

The second category consists of BDS wrappers and hook frameworks, such as LeviLamina or Endstone. These tools run the official `bedrock_server` binary under the hood and inject custom hooks into the C++ memory space. Because the underlying engine is still genuine BDS, these servers support standard Behaviour Packs, Resource Packs, and the official Script API alongside their own native plugin systems. If you are developing a complex add-on, you must target either vanilla BDS, Realms, or a BDS-based wrapper.

Because a dedicated server has no graphical interface to toggle packs on a world, activation is controlled entirely through JSON configuration files inside the world folder. Assuming your `level-name` in `server.properties` is set to `Bedrock level`, you must create or edit `world_behavior_packs.json` and `world_resource_packs.json` inside `worlds/Bedrock level/`.

Each file contains a JSON array of objects. Every object requires the `pack_id` (matching the UUID from the pack's `manifest.json` header) and the `version` array. The server reads this list in order from top to bottom, giving higher priority to packs listed earlier in the array. For resource packs, if you want to ensure players cannot bypass your custom models or UI, you should also set `texturepack-required=true` in the root `server.properties` file. This forces connecting clients to download and apply the server's resource packs before spawning.

[
  {
    "pack_id": "0483942a-6d3b-4f88-918d-6969b2392014",
    "version": [ 1, 0, 0 ]
  }
]

While `@minecraft/server` runs on both client-hosted worlds and dedicated servers, Mojang provides two additional Script API modules exclusively for Bedrock Dedicated Server: `@minecraft/server-net` and `@minecraft/server-admin`. The `@minecraft/server-net` module allows your add-on to make outbound HTTP requests, which is essential for linking game events to external web databases or Discord webhooks. The `@minecraft/server-admin` module provides access to `variables` and `secrets` defined by the server operator.

These modules are entirely absent from retail clients and Realms for security reasons. If you declare them as dependencies in your Behaviour Pack's `manifest.json`, the pack will only load on BDS, and even then, the server administrator must explicitly grant permission for the pack to use them.

{
  "format_version": 2,
  "header": {
    "name": "Dedicated Server Integration Pack",
    "description": "Uses server-admin and server-net modules.",
    "uuid": "0483942a-6d3b-4f88-918d-6969b2392014",
    "version": [ 1, 0, 0 ],
    "min_engine_version": [ 1, 20, 80 ]
  },
  "modules": [
    {
      "type": "script",
      "language": "javascript",
      "uuid": "a19402b1-3892-4029-8f1a-992837461234",
      "entry": "scripts/main.js",
      "version": [ 1, 0, 0 ]
    }
  ],
  "dependencies": [
    {
      "module_name": "@minecraft/server",
      "version": "1.10.0"
    },
    {
      "module_name": "@minecraft/server-admin",
      "version": "1.0.0-beta"
    },
    {
      "module_name": "@minecraft/server-net",
      "version": "1.0.0-beta"
    }
  ]
}

When a pack requests `@minecraft/server-net` or `@minecraft/server-admin`, BDS checks a configuration file located at `config/default/permissions.json` (or inside a specific world configuration folder, depending on your server setup). By default, outbound networking and admin modules are blocked. You must add `

{
  "allowed_modules": [
    "@minecraft/server-gametest",
    "@minecraft/server",
    "@minecraft/server-ui",
    "@minecraft/server-admin",
    "@minecraft/server-net"
  ]
}

Debugging an add-on on a dedicated server requires enabling content logs via `server.properties` rather than the in-game settings menu. By setting `content-log-console-output-enabled=true` and `content-log-level=verbose`, any JSON parsing errors, missing geometry references, or `console.warn()` calls from your scripts will print directly to the server's standard output stream.

For interactive script debugging, BDS supports connecting to Visual Studio Code using the Minecraft Bedrock Edition Debugger extension. To enable this on a server, configure the script debugger properties in `server.properties` (allowing outbound or inbound debug connections on a local port) or enter the `script debugger listen <port>` command directly into the server console. Never leave the script debugger port open to the public internet on a production server, as it allows arbitrary code execution within the script engine.

Applies to Bedrock Dedicated Server 1.19.0 and later. While standard @minecraft/server APIs are stable, the @minecraft/server-net and @minecraft/server-admin modules remain in beta as of 1.21.x and require the Beta APIs experimental toggle to be enabled on the world.

Read out of the game itself, so the ids match the version you are building for.