bareiron

bareiron is a minimalist Minecraft server implementation aimed at memory-restrictive embedded systems. Its stated goal is to make it possible to host Minecraft servers on very weak devices, such as the ESP32. The project explicitly orders its priorities as memory usage first, performance second, and features third, and it notes that compliance with vanilla Minecraft is neither guaranteed nor a goal. Target compatibility is Minecraft version 1.21.8 with protocol version 772. The README warns that only the vanilla client is officially supported, and that issues have been reported when using Fabric or similar clients. Getting started on PC x86_64 platforms is done by downloading the latest build binary and running it. The file is described as a Cosmopolitan polyglot, meaning it can run on Windows, Linux, and possibly Mac despite its file extension. The README notes that the server's default settings cannot be reconfigured without compiling from source. For microcontrollers, compilation is required. Before compiling, registry data must be dumped from a vanilla Minecraft server. On Linux this can be automated with an included extract_registries.sh script; otherwise the process involves placing a Minecraft server JAR in a notchian folder, following the Minecraft Wiki data generator guide to dump all registries, and then running build_registries.js with bun, node, or deno. Compilation instructions cover several environments: Linux with gcc and ./build.sh; Windows via MSYS2 MINGW64 for a native binary, a 32-bit variant compatible with Windows 95/98 via a --9x flag, an MSYS2-linked binary, or WSL for building and running a Linux binary. For ESP variants, the README instructs setting up a PlatformIO project using the ESP-IDF framework (explicitly not Arduino) and cloning the repository on top of it, with suggestions to adjust clock speed and enable compiler optimizations for better performance. Configuration also requires compiling from source. Most user-friendly options live in include/globals.h, including WiFi credentials for embedded setups, while details such as the MOTD or starting time of day are in src/globals.c. The README highlights several options relevant to real microcontroller deployments: movement broadcasting can throttle connections depending on player count, MCU performance, and network bandwidth, and can be adjusted by commenting out BROADCAST_ALL_MOVEMENT and SCALE_MOVEMENT_UPDATES_TO_PLAYER_COUNT, or by lowering TIME_BETWEEN_TICKS at the cost of more compute. Chests and fluid flow can be disabled via ALLOW_CHESTS and DO_FLUID_FLOW if they cause crashes or instability. Increasing VISITED_HISTORY may help with frequent repeated chunk generation, with a stated memory cost of about 240 extra bytes per allocated player when raised to 64. An optional section covers non-volatile storage for ESP targets that want to persist world data after shutdown. On PC platforms this is unnecessary because world and player data is written to world.bin by default. The simplest approach is setting up LittleFS in PlatformIO and commenting out the #ifndef surrounding SYNC_WORLD_TO_DISK in globals.h; since flash writes are typically slow and blocking, uncommenting DISK_SYNC_BLOCKS_ON_INTERVAL is suggested, and MAX_BLOCK_CHANGES may need to be reduced to fit the LittleFS partition. For SD card modules or other virtual file systems, the filesystem setup routine must be implemented by the user, though the built-in serializer should still work because it uses POSIX filesystem calls. As an alternative, world data can be dumped and uploaded over TCP by uncommenting DEV_ENABLE_BEEF_DUMPS, with an explicit note that this system implements no security or authentication and that anyone with server access could upload arbitrary world data. Contribution guidelines ask contributors to create issues and discuss with maintainers before pull requests, even for small changes; to follow the existing code style; to test code before requesting review; and they state that development tooling and compilation improvements are not welcome unless the contributor has worked with the codebase long enough to notice practical shortcomings. The README points to the Minecraft Wiki for protocol information and suggests a search engine for everything else.