A live map renders your world as a browsable page, usually with player positions on it. It is genuinely useful for a community — and it is also the single easiest way to publish everyone's base location to the internet without meaning to.
The two common approaches
| Tile-based | 3D browser-rendered | |
|---|---|---|
| How it renders | The server draws image tiles | The browser draws the world from data |
| Server cost | Higher — rendering is real work | Lower — mostly one-off data export |
| Initial render | Can take hours on a big world | Also slow the first time |
| Looks like | A flat map, like an atlas | A model you can fly around |
What to do
- Install the plugin and give it a port
A web map serves a website, so it needs a port of its own. The Network tab is where your allocations live.
- Let the first render finish before judging performance
The initial pass over an existing world is the heaviest it will ever be. Judging the ongoing cost during it is like judging a car by its first start on a cold morning.
- Restrict the render area
There is no point mapping ten thousand blocks of ocean nobody has visited. Limiting the render radius cuts both the render time and the disk use enormously.
- Decide what is visible before you share the link
Player positions, base locations and hidden builds are all on by default in most configurations.
Live player positions tell anyone watching where people are and, more usefully to a griefer, where they are not. On a survival server with valuables, either hide player markers or accept that you have removed the ability to hide anything. Both are valid; drifting into the second without deciding is not.
Most maps can update on a timer instead of following every block change. Once an hour is plenty for a community map and takes the ongoing cost close to zero.
The map loads in a browser, shows terrain you recognise, and updates after you place a block and wait for the next render.