PicoLimbo: a Minecraft limbo server that speaks nineteen years of protocol versions

What a limbo server is, and why it can be this small

PicoLimbo is described as a lightweight limbo server written in Rust, designed primarily as an AFK or waiting server. There is a linked explainer on the author's site about what Minecraft limbo servers are, and the concept is simple.

A limbo server is where a player sits while they are away from their real server. It holds the connection, keeps the client alive, and offers nothing else. No world, no mobs, no gameplay. The entire job is to be a placeholder that does not time out.

That framing is why the project can be so small, and it is stated in the introduction: its core focus is on efficiency by implementing only essential packets required for client login and maintaining connection, keep-alive, without unnecessary overhead.

So the packet surface is deliberately tiny. A full Minecraft server has to implement the whole gameplay protocol, chunk sending, entity tracking, the inventory system and the rest. A limbo server has to let a client log in, tell it where the world is, and answer the keep-alive ping so the client does not decide the server has hung. Everything else is omitted.

The project is explicit that it is not trying to replicate every server feature. What it does instead is support all Minecraft versions from 1.7.2 through 26.3, excluding snapshots.

The primary language is Rust, the licence is MIT, the default branch is master, and the homepage is picolimbo.quozul.dev. The recent releases are v1.15.0+mc26.3 from 2026-10-10, v1.14.1+mc26.3 from 2026-09-23 and v1.14.0+mc26.3 from 2026-09-18, and the last push was on 2026-10-12 with the project not archived.

The release tags are worth reading, because they encode the version scheme: the library version and the Minecraft version are joined with a plus sign. The project version moves independently of the Minecraft version, which is the right shape for a server that has to speak many protocol versions at once.

Wide version support without a compatibility layer

The first feature is wide version compatibility: supports all Minecraft versions from 1.7.2 to 26.3 natively, with no need for ViaVersion or additional compatibility layers.

ViaVersion is the standard way to let a modern server accept old clients, and it works by translating the protocol on the fly. It is also a large dependency with a large surface, and for a server whose entire purpose is to log a client in and keep it alive, pulling in a protocol translator to do that is a lot of machinery for a small job.

Supporting the old versions directly means the server has to understand each protocol generation itself. That is a different kind of work: instead of translating, you implement the relevant subset of each version. The cost is in the protocol crates, and the benefit is that the whole thing stays in Rust with no Java sidecar.

The screenshots are noted as showing just a few of the supported Minecraft versions, which is the sort of detail that tells you how wide the range really is in practice.

The protocol_version and protocol_version_macro crates in the workspace listing are how that range is expressed in code. A macro crate is the natural way to generate the per-version differences, since the packet sets and the data types change subtly between versions and writing them out by hand for nineteen years of releases would be unmaintainable.

The other thing the range implies is that the packet layer is a first-class concern rather than an afterthought. There is a minecraft_packets crate and a minecraft_protocol crate, split from each other, which suggests the packet definitions and the protocol machinery are separated so the version-specific data can be regenerated rather than hand-maintained.

Proxy support, and what Floodgate adds

The built-in proxy support is the feature that matters most for real deployments, and it lists the major options.

Velocity is supported with Modern Forwarding, and BungeeCord with Legacy Forwarding. BungeeGuard and BungeeGuardPlus authentication is also supported. In both cases the forwarding mode matters, because a proxy that forwards the player's real IP to the backend changes what the backend can log and what it can enforce, and the two systems have different ways of doing it.

Then there is Floodgate, and this is handled in an interesting way. PicoLimbo supports native Floodgate data forwarded by a proxy using Geyser and Floodgate, including Education Edition connections through EduGeyser and EduFloodgate. The key detail is that Floodgate support is handled directly by PicoLimbo, rather than needing a separate plugin.

What Floodgate does is give Bedrock Edition players a Java Edition session, so that a player on Minecraft Bedrock can join a Java server. EduGeyser and EduFloodgate are the Education Edition equivalents. So the combination of Geyser, Floodgate, EduGeyser and EduFloodgate covers both Bedrock and Education Edition players reaching a Java server through a proxy, and the proxy forwards the resulting session data to PicoLimbo, which accepts it directly.

There is a separate Floodgate documentation page for configuration details and proxy setup, which is the right place for it since the setup involves a proxy as well as the server.

BungeeGuard deserves a sentence, because it is not a widely known name. It is a layer that sits in front of a BungeeCord proxy and checks that incoming connections actually came through that proxy, which stops a player from connecting to the backend directly and bypassing the proxy's authentication and rate limiting. If your proxy has that in place, the server behind it needs to believe the forwarded data.

The Skin Support entry is short, and the README's own summary of it is that player skins are supported and what else to say about that. Skins matter for a limbo server because that is the one piece of visible player data a waiting screen still shows, so a player sitting in limbo still sees their own character.

Resource use, configuration, and the experimental world feature

The efficiency claim is specific, and it is the number most people would evaluate this project on. The server uses zero percent CPU while idle and handles hundreds of players under 10 MB of RAM, with a benchmarks page linked.

Zero percent CPU while idle is a consequence of the design rather than a tuning achievement. If the only packets being exchanged are login and keep-alive, then an idle server has nothing to do, and a well-written event loop goes to sleep on the socket. A full server cannot do that because it has to tick the world.

The 10 MB figure is the more interesting one, because a Rust binary with a protocol implementation for nineteen versions of Minecraft would not obviously fit in that. The workspace listing shows the answer, or at least part of it: pico_libraries/ holds pico_identifier, pico_nbt, pico_precomputed_registries and pico_registries, so the NBT parsing and the item and block registries are separate crates, and the registries have a precomputed variant. Precomputed registries mean the data is baked rather than parsed at startup, which is the difference between paying a large cost once and paying none at all.

The configuration is a single TOML file, and the features list names what is in it: welcome message, spawn dimension, server list MOTD, and more. The configuration documentation is on the website.

The experimental feature is the schematic world. You can load a custom world from a schematic file and customise the spawn location, and it is marked experimental and 1.13 and later only. That restriction is a good sign of what the feature does, since the world format changed substantially in 1.13, and 1.13 is the era in which the modern format begins.

The fact that a limbo server loads a world at all is worth noting. The point of a limbo server is that the player is not in the world, but some servers use a lobby as a waiting room with a view. The schematic is a small decorative world rather than a playable one, and the 1.13 floor tells you the implementation targets the modern format only.

How to run it, and the repository structure

There are four routes to a running server, and they cover the different ways people host.

Pterodactyl comes first, and there are official eggs in the pterodactyl/ directory. Pterodactyl is the game server panel, so an egg is a template that tells the panel how to install and launch a particular server. The installation documentation has a section for it.

Docker is the second, and it is a single command:

docker run --rm -p "25565:25565" ghcr.io/quozul/picolimbo:latest

The --rm flag means the container is removed on exit, and the port mapping exposes 25565, the standard Minecraft port, on the host. There is also a docker-compose.yml at the root and a docker/ directory, so a compose-based setup with a volume for configuration is available.

The Java Wrapper is the third route, and it is the one that solves a specific problem. For a user wishing to run PicoLimbo inside a Velocity or BungeeCord proxy, as a plugin or as a standalone jar file, there is a Java Wrapper available from Modrinth. So a Java-only host can still run a Rust server, which matters for panels and networks that assume plugins.

The fourth route is the binary or standalone build, downloaded from GitHub Releases, and the documentation site has the detailed installation and configuration instructions.

The repository layout is where the multi-version design becomes clear. There is pico_limbo/ for the server itself, crates/ for the supporting libraries, pico_libraries/ for the shared data-format crates, and the crates/ directory has eleven members, including blocks_report and blocks_report_data, macros, minecraft_packets, minecraft_protocol, net, pico_binutils, pico_structures, pico_text_component, protocol_version and protocol_version_macro.

The naming tells you the design. The protocol version and its macro are separated so the version range can be generated. minecraft_packets and minecraft_protocol are separate so the packet definitions and the protocol machinery do not change together. pico_structures handles the game data structures, pico_text_component handles the chat component format that replaced raw JSON in chat messages, pico_binutils holds byte-level utilities, and blocks_report with blocks_report_data suggests a generated catalogue of block information.

The release profile is also unusual and deliberate:

[profile.release]
codegen-units = 1
lto = true
strip = "symbols"

codegen-units set to 1 and link-time optimisation enabled both trade build time for runtime performance and a smaller, faster binary, and stripping symbols reduces the size further. For a server whose selling point is a ten megabyte resident footprint, that is a sensible set of choices to make in the build configuration.

There is a rust-toolchain.toml, a flake.nix and flake.lock for Nix, a nix/ directory, and the docs are built with VitePress, which the package.json shows with dev, build and preview scripts and vitepress pinned at 1.6.3.

Editorial conclusion

Adopt PicoLimbo if you run a Minecraft network and need an AFK or waiting server that holds hundreds of players for a few megabytes of RAM, and if you want old clients from 1.7.2 onwards to connect without a ViaVersion layer in the stack. Do not adopt it expecting a playable server, because it implements only login and keep-alive packets by design, and treat the schematic world as decorative rather than a world, since it is marked experimental and restricted to 1.13 and later. Before you commit, check the proxy integration for your setup, particularly the forwarding mode, and note that the release tags couple the project version to the Minecraft version, so plan for the project version and the protocol version to move independently.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. Quozul/PicoLimbo on GitHub
4. README
5. Releases