BlueMap

Last reviewed Sep 13, 2026 · 846 words

The first full render of a modestly explored survival world takes BlueMap a few hours of CPU and leaves behind a web/ directory that is easily larger than the world save itself. That is the whole trade-off in one sentence: BlueMap produces the best-looking map any Minecraft server can have, a real 3D model you orbit and fly through in a browser, and it does so by pre-rendering the world into hundreds of thousands of tile files. Plan the disk, throttle the render, and it is otherwise the easiest thing in the games category to host.

Two ways to run it, and one of them needs no plugin

BlueMap (MIT, Java, 2,801 stars) ships as a plugin for Paper, Spigot, Fabric, Forge and friends, and as a standalone CLI jar. The plugin route is the normal one: drop the jar in plugins/, restart, and it renders while the server runs, updating chunks as players change them and showing live player markers. The CLI route reads a world folder directly, which means you can render a world that is offline, or a backup copy, on a different machine than the one hosting the game. For an already-busy game server on a small VPS, rendering elsewhere is the sane option.

Either way the output is static files plus a built-in web server on port 8100. Because the output is static, you do not need the built-in server at all: point Caddy or nginx at the web/ directory and BlueMap's web server can stay disabled. That is my preferred layout, since it keeps the Java process off the internet entirely.

The one config line everyone hits

BlueMap needs Minecraft's own textures to render blocks, and it will not download the client jar until you tell it that you accept Mojang's terms. On first start it refuses to render and logs the reason. Open plugins/BlueMap/core.conf (or config/core.conf for the CLI) and set:

accept-download: true

Restart, and it fetches the assets and begins. If you use resource packs or mods that add blocks, drop them into the packs folder BlueMap creates next to its config files and it will read the models; unknown blocks otherwise render as missing-texture magenta.

Rendering is the expensive part, serving is free

The renderer is CPU- and memory-bound. Our catalogue's 512 MB floor is realistic for serving and incremental updates; a full initial render on a large world wants 2 to 4 GB of heap and every core you can give it. Two levers matter. render-thread-count in core.conf defaults to something conservative; on a dedicated render box raise it to your core count, on a shared game server lower it to 1 or 2 so tick times survive. And in each map's config (maps/world.conf), min-y, max-y and the render-edge and remove-caves settings decide how much of the underground you model. Skipping caves halves the tile count on most survival worlds.

Disk grows with explored area, not with player count. A world with a 10,000-block explored radius is a multi-gigabyte map; a 30,000-block radius is tens of gigabytes. The "hires" tiles dominate, so if disk is tight, the hires section of the map config can be trimmed. Serving the tiles costs almost nothing since they are plain files, and the browser does all the 3D work with WebGL.

Where it sits next to Dynmap

Dynmap is the older, flatter, more widely deployed choice, with a 2D top-down view and a big plugin ecosystem, and if your players just want "where is spawn" on a phone it remains perfectly good. BlueMap wins on visuals, on standalone rendering, and on a lighter serving footprint. The catalogue's Dynmap alternatives page lays out the field. If you already run a panel such as Crafty Controller or Pterodactyl, BlueMap installs like any other plugin and the panel does not need to know about it; just expose port 8100 or, better, serve the static output separately.

Access control is the one thing BlueMap does not do. The map is public to anyone who can reach the URL, and it reveals base locations and live player positions. For a private server, put it behind Tailscale or basic auth on the reverse proxy.

What I'd do

Install the plugin, set accept-download: true, set the render threads to 2 on the game server, and let the first render complete overnight. Disable the built-in web server, serve web/ from Caddy on a subdomain with TLS, and add basic auth unless the server is public. Watch disk for the first week, then trim caves if the tile directory passes what you are comfortable with. Re-render fully only after a world reset or a major Minecraft version bump. Run this way, it is a 20-minute setup that makes any server look far more polished than its player count deserves.