A live web map is a view of your server's world in a browser, updated as the world changes, so anyone with the link can pan around the map, find spawn, spot bases and see how far the world has been explored without logging in. Players love them, because a map turns a server from a place you visit into a place you can see all at once, and it makes a growing world feel like a shared project. This post covers the two main options, BlueMap and Dynmap, how they differ, what they cost your server, how setup looks at a high level, and when a map is actually worth running.
If you are still assembling your plugin set, a live map sits in the optional-but-popular tier alongside the rest in essential SMP plugins, and it leans directly on the world work in world management and pregen. The wider picture is in running a Minecraft SMP.
The two options and how they differ
Dynmap is the long-standing choice, and it has been the default live map on Minecraft servers for years. It renders the world as flat, top-down 2D tiles, the classic Google-Maps-style view, and it can serve them from its own built-in web server so players just open a link. It is mature, widely documented, and if you have ever seen a server map before, it was probably Dynmap.
BlueMap is the newer option, and it takes a different approach to rendering. It builds a 3D view of the world, so instead of a flat overhead picture you get terrain and structures you can tilt and fly around in the browser. It renders the world to static files, which the browser then displays, and the result is closer to looking at the actual world than at a diagram of it.
The practical difference for you is the rendering model. Dynmap's 2D tiles are the established, lightweight-to-read format that everyone recognises. BlueMap's 3D static files give a richer view that many players prefer, at a different cost profile. Neither is the wrong answer, and the right one depends on what you want players to see and what you are willing to spend on it.
What they cost your server
Both maps have to look at your world and turn it into images, and that rendering is real work. It reads chunks, processes them and writes output, so an initial full render of an existing world is heavy, and keeping the map current as the world changes is a smaller ongoing cost on top. The two projects spend that cost differently, in CPU while rendering and in disk for the output they store. The rough shape is this. BlueMap's initial full render is CPU-heavy, because building a 3D model of the world is more work than drawing flat tiles, but it renders asynchronously and off the server's tick thread, so it does not directly cost you TPS while it runs. Dynmap is lighter on CPU for the same area, but it writes its output as a very large number of small tile images, and on a well-travelled world that tile folder can grow to the same order of magnitude as the world files themselves. So BlueMap tends to spend more on CPU during a render and gives you a richer result, while Dynmap spreads its cost into a lot of small files on disk. The exact numbers depend heavily on world size, detail settings and hardware, so treat both as costs to bound with the settings below rather than fixed figures.
A map's storage grows with the area you render, because every part of the world you map becomes output on disk, and its CPU cost is highest during the initial render of a large or long-established world. Both are manageable with the settings below, and neither is a reason to avoid a map, but both are reasons to configure it deliberately rather than pointing it at an unbounded world at full detail and walking away.
Setup at a high level
The shape is similar for both. You install the plugin, start the server so it generates a config, and then set where and how it renders and how players reach the web view. You point it at the worlds you want mapped, decide the detail and the area, and either use the plugin's own built-in web server or serve the output through a web server you already run. Both ship a built-in web server, so you can be up and running without setting up a separate one. Dynmap's serves on port 8123 by default, and BlueMap's on port 8100. Both are actively maintained and track current server versions, though modded and non-Paper setups are more involved, so check each project's page for the exact version and platform support before you install.
The one decision worth making up front is which worlds to map and how much of each. Mapping the overworld is the obvious case. A resource world that resets on a schedule is often not worth mapping at all, since the map goes stale every reset. Set that intent before the first render, so you are not generating output you will only throw away.
Performance advice
Render on a schedule and off the main thread. A well-behaved map does its rendering as a background job rather than on the tick thread that runs your world, so the map building itself should not directly cost you TPS. Where it can bite is I/O and CPU contention on a busy box, so schedule the heavy full renders for quiet windows and let the lighter live updates run during play. Each exposes controls for this. Dynmap sets the number of concurrent render threads with parallelrendercnt and the pause between tiles with renderinterval in its configuration.txt; keep the thread count below the number of physical cores so rendering never starves the server. BlueMap sets render-thread-count in its core.conf, which caps how many cores it will use, and it too should stay at or below the cores you have available. On both, keep those counts conservative on a shared or busy box, run the heavy full renders in a quiet window, and let the lighter live updates tick along during play.
Bound it with a world border. This is the single most effective control, and it is another reason the world management work pays off twice. A map with no edge tries to render as far as players have ever wandered, which is exactly the unbounded sprawl a border prevents. Render inside the border you already set, and the map's CPU and storage cost becomes a known, fixed quantity instead of something that grows every time someone explores. If you pre-generated to the border, the map has a clean, finite area to work with from the start.
Keep the detail sensible. Both maps let you trade visual quality for render cost and disk, so if the highest detail is not earning its keep, step it down. A map players actually use at a moderate detail beats a beautiful one that bogs the box down on every render.
When a map is worth running
A live map is worth running when players will use it and you have the headroom to serve it. On a social SMP where people share bases, plan builds and enjoy seeing the world fill in, it adds a lot for a cost you can bound with a border and a schedule. On a PvP server it is often deliberately left off or limited, because a public map of everyone's base is a gift to raiders, so think about what the map reveals before you publish it.
If you have the resources spare, it is a genuine crowd-pleaser and a low-risk addition once it is bounded and scheduled. If your box is already tight on the tick, treat it as the optional extra it is, get the core performance right first, and add the map when you have room. Either way, configure it deliberately, keep it inside a border, and it will stay a feature rather than a tax.
If you want the headroom to run a live map without robbing the tick, our Minecraft hosting gives you reserved cores and fast storage, so the render job has somewhere to run that is not the thread keeping your world alive.