Minecraft web maps: Dynmap, BlueMap and squaremap

A web map plugin is a second server running inside your Minecraft server. It reads the world's chunks, renders them into image tiles, writes those tiles to your disk, and serves them over HTTP on a port of its own - 8123 for Dynmap, 8100 for BlueMap, 8080 for squaremap by default. That last part is where most installs stall on hosted servers, because a game plan comes with one port allocation and that one is the game. You need a second one, and the plugin has to be told to use the number the panel gives it rather than its own default. Everything else is a question of how much CPU and disk you are willing to spend on pictures.

What a web map actually is#

There are two distinct jobs behind the single word "map".

The first is rendering. The plugin walks region files or loaded chunks, works out what each column of blocks looks like from above or from an angle, and writes the result as tiles at several zoom levels. This is expensive, it is mostly a one-off, and it is the part that fills a disk.

The second is serving. A small embedded HTTP server hands those tiles to a browser along with a JSON document of player positions, refreshed every second or two. This is cheap. A live map with a dozen viewers costs the server almost nothing once the tiles exist.

After the first full render, the plugin only re-renders tiles whose chunks changed, which on a normal survival server is a handful per minute. So the honest cost model is: one large upfront bill, then close to nothing.

Dynmap, BlueMap and squaremap compared#

Dynmap is the oldest and the most featureful. Its marker API is why almost every plugin that wants to draw something on a map - claims, shops, warps, towns - integrates with Dynmap first. Its isometric "surface" map is also the single most expensive thing in this post.

BlueMap is the one people install because a screenshot of it convinced them. It ships the world to the browser as 3D geometry rather than flat images, so you can fly around it. The trade is a heavier first render and a dependency people do not expect: BlueMap needs the official Minecraft client jar for block textures, and it will not download it until you say so in the config.

squaremap is a fork of Pl3xMap, Paper only, top-down only, and deliberately small. It renders faster than either of the others and produces the smallest tile tree. On a 2 GB or 4 GB plan it is usually the right answer, and the only real argument against it is that flat maps are less impressive.

Confusingly, Dynmap's configuration.txt is YAML despite the extension. Edit it with the same care you would give any YAML file: spaces not tabs, and one bad indent stops the plugin loading.

The extra port, hostnames, and what DNS cannot do#

A Minecraft plan on RE:NODE comes with one allocation, and that is the game port. The map plugin's web server needs its own, which you add on the panel's Network tab. Two things follow from that, and both catch people:

• The panel gives you the number. You do not get to pick 8123 because a plugin's documentation says so. Take whatever the new allocation shows and put that number in the plugin's config.
• An unallocated port is not reachable, even from inside. Leave Dynmap on 8123 and it will start happily, log that its web server is listening, and be invisible from the internet. There is no error to find, because nothing went wrong on the server's side.

So the sequence is: add the allocation, note the port, set the plugin's port to match, set its bind address to 0.0.0.0 rather than 127.0.0.1, restart, then check from your own machine:

$ curl -I http://203.0.113.10:25580/HTTP/1.1 200 OK

Never point the map at the game port. Minecraft's protocol is not HTTP and sharing a port between them is not a thing that can work. Game server ports explained covers why each service needs its own and what a query port is for.

Once it works you will want a nicer address than an IP and a five-digit port. DNS gets you half of it. An A record pointing map.example.com at the server's address means people can type http://map.example.com:25580, which is better. What DNS cannot do is carry the port: an A record maps a name to an address and nothing else. SRV records do carry ports, which is why they work so well for the game itself - see SRV records for Minecraft - but browsers do not look up SRV records for ordinary web requests, so they do not help here.

Losing the port from the URL, and getting HTTPS with it, means something in front terminating TLS and forwarding to the map. That is what a reverse proxy does, and RE:NODE's app and web plans include a proxy slot that issues and renews a certificate automatically once an A record points at it. A game plan's web map is plain HTTP on a port, and for most servers that is fine. Just be aware of what that means:

What a reverse proxy does and subdomains for servers go through the naming side properly.

Installing and configuring Dynmap#

Upload the jar to plugins/, start the server once so it writes its files, stop it, then edit plugins/dynmap/configuration.txt. The settings that matter on a hosted server:

webserver-bindaddress: 0.0.0.0webserver-port: 25580disable-webserver: falsemax-sessions: 30image-format: jpg-q85timesliceinterval: 0.2maxchunkspertick: 120zoomoutperiod: 30tileupdatedelay: 30

Three of those do most of the work.

• timesliceinterval and maxchunkspertick are the throttle. The first inserts a pause between render slices, the second caps how many chunks are processed per tick. Defaults are tuned for a machine with cores to spare; on a plan with 1 to 2 vCPU, 0.2 and 120 keep a full render from taking the tick budget hostage.
• image-format is the biggest single lever on disk use. png is lossless and enormous; jpg-q85 is visually fine for terrain and a fraction of the size.
• zoomoutperiod and tileupdatedelay batch work rather than doing it the instant a block changes.

Per-world map definitions live in worlds.txt, built from the templates in the templates folder. The default set gives each world a flat 2D map, an isometric "surface" map and a cave map. The isometric one is the expensive member of that family in both render time and tiles on disk, so if you only wanted an overview, delete it from the world's definition and keep the flat map. That decision alone can be the difference between a few hundred megabytes and several gigabytes.

Rendering is driven from the console:

$ dynmap fullrender world$ dynmap radiusrender 3000$ dynmap cancelrender world$ dynmap pause all$ dynmap stats

radiusrender renders a circle around your position, which is almost always what you actually want - a full render of an unbounded world will keep going until the disk runs out. pause all stops both full and incremental rendering, which is the emergency brake when a render is hurting a live server.

Dynmap can also store tiles in a database rather than on the filesystem. On a game plan, with one database slot and millions of small tiles, that moves the cost rather than removing it, and it is rarely the right trade. Its web chat component is off by default in most builds and should stay that way unless somebody is moderating it; an unauthenticated chat box on a public URL attracts exactly what you would expect.

Installing and configuring BlueMap#

BlueMap will refuse to do anything on first start, deliberately. It needs the official Minecraft client jar for block textures and will not fetch it without permission:

accept-download: truerender-thread-count: 1metrics: true

Set accept-download to true, restart, and it downloads the resources and begins. render-thread-count decides how many threads do the rendering. It defaults to something sensible for a machine with many cores, and on a container with a hard CPU limit that default is wrong: those threads spend the same share of CPU the game thread needs. On 1 to 2 vCPU, set it to 1 and accept that the first render takes longer.

The web server is separate:

enabled: trueport: 25581webroot: "bluemap/web"

Set the port to your second allocation and the bind address to 0.0.0.0 - the key name for that has changed between major versions, so read the comments in the file rather than copying from a forum post.

Each world gets a file under maps/, and two settings in there save more work than anything else. min-inhabited-time skips chunks nobody has actually spent time in, which on an explored-but-empty world removes most of the render. Restricting the vertical range with the minimum and maximum Y settings stops BlueMap building geometry for bedrock and sky nobody will look at.

Commands are namespaced under /bluemap. Running it on its own prints render progress and the list of subcommands your version supports; reload, freeze (stop updating a map without deleting it) and purge (delete a map's rendered data) are the ones you will use. Because the render runs off the main thread, BlueMap will not usually show up as MSPT, but it will show up as CPU - so if TPS drops during a render, profile with --thread * as described in diagnosing Minecraft lag with spark.

squaremap, the cheap option#

squaremap is Paper only and flat only, and it installs like any other plugin. Its configuration is ordinary YAML:

settings:  internal-webserver:    enabled: true    bind: 0.0.0.0    port: 25582

Per-world options live further down the same file under a default block plus one block per world, so you can render the overworld and skip the end. Commands follow the same pattern as Dynmap:

$ squaremap fullrender world$ squaremap radiusrender 3000$ squaremap cancelrender world$ squaremap resetmap world$ squaremap reload

resetmap deletes a world's tiles and asks for confirmation first, which is the right way to recover from a render you made with the wrong settings. If your plan is a Starter or Standard tier and you mostly want to see where everybody is and how far the base sprawl has spread, this is the plugin to install. It will render the same area in a fraction of the time and leave you disk for the world.

What a render costs in CPU, memory and disk#

Three separate budgets, and people usually only think about one.

CPU. The first render is the expensive part. Dynmap renders on the server's threads with a configurable throttle; BlueMap and squaremap use their own. On a container the distinction matters less than it sounds, because the CPU limit applies to the whole process: whatever the render threads use is taken from the same share the game thread wants. That is not a reason to avoid a web map, it is a reason to render when nobody is playing.

Memory. All three run inside the same Java process as the server, so their working set comes out of the same heap and the same container limit. On a 2 GB plan there is no room for a tile renderer on top of a world and plugins, and the failure mode is not "the map is slow" but "the server hit its memory limit and restarted". Sizing is in how much RAM a Minecraft server needs.

Disk. This is the one that bites. Tile trees scale with the rendered area, not with player count, and a world with no border has no upper bound. A 10,000 by 10,000 block area is 400 region files; the tiles rendered from it can land anywhere between a few hundred megabytes with a flat JPEG map and several gigabytes with 3D maps at PNG quality. That range is genuinely that wide, which is why the right move is to render a small radius first, look at the folder size, and extrapolate.

The order of operations that avoids all of this:

1. Set a world border and pre-generate inside it, so the world itself has a known size. World border and pregeneration has the Chunky commands.
2. Decide which maps you actually need. Flat only, for the overworld only, is a legitimate answer.
3. Run a radiusrender of 1,000 blocks and measure what it produced.
4. Scale up to the border, at a quiet hour, with the throttle on.

Keeping bases and players off the map#

A public live map is a griefing tool on a server without claims. It tells anyone with the URL where every base is and who is currently a long way from theirs. Decide the policy before you render, not after somebody's storage room is empty.

What each plugin gives you:

• Dynmap has /dynmap hide and /dynmap show for individual players, visibility and hidden region limits per world in worlds.txt so you can exclude an area entirely, and an optional web login so the map is not open to everyone.
• squaremap has /squaremap hide and /squaremap show, and per-world settings to control which players appear.
• BlueMap's plugin.conf carries a set of switches for hiding vanished, sneaking, spectating and invisible players, and the live player layer can be turned off completely.

Hiding players is the easy half. Hiding terrain is harder, because the tiles are already rendered and served as static files - a hidden region has to be excluded before the render, or purged after it. If your server needs bases to stay secret, the realistic options are a flat low-zoom map that does not show detail, a map restricted to a spawn region, or no public map at all with a staff-only render you look at locally.

The better answer for most communities is not secrecy but protection. A map plus a claims plugin plus block logging is a healthy combination; a map alone on an unprotected server is a problem waiting for a bad week. Grief protection and anti-cheat covers that side, and the general hygiene of a plugin list is in the Paper optimisation guide.

FAQ#

Which web map should I install?

squaremap if your plan is small or you mainly want an overview. BlueMap if the map is a selling point for your community and you have the CPU and disk for it. Dynmap if you need its marker API because another plugin draws claims, towns or shops on it.

Will a web map lag my server?

The first full render will, unless you throttle it and run it when nobody is on. Incremental updates afterwards are negligible, and serving tiles to viewers costs almost nothing. The lasting cost is disk, not tick time.

Can I run the map on port 80 so the URL has no port in it?

Not on a game plan. You get an allocation from the panel's range and the plugin must use it. Removing the port from the URL needs something in front terminating HTTPS and forwarding to the map, which is what a reverse-proxy slot on an app or web plan is for.

Can I point a subdomain at my map?

Yes, with an A record to the server's address, but the port stays in the URL because DNS does not carry ports. SRV records do, and browsers ignore them.

How much disk will the tiles take?

It depends on the rendered area, the renderer, and whether you kept the 3D maps. Render a 1,000-block radius, measure the folder, and multiply. Setting a world border first is what turns an unanswerable question into an answerable one.

Do web maps work with mods rather than plugins?

Dynmap and BlueMap both publish Fabric, Forge and NeoForge builds. squaremap is a Paper plugin only. On a Paper server all three are plugins and install the same way, through the file manager or SFTP.