Public BlueMap: What to Check Before Sharing Your Map
Before making BlueMap public, decide what a visitor without a login may see and check that view from outside your network. Review terrain, player positions, markers and previously generated data separately. Hiding an area in one screen does not demonstrate that every related piece of information is unavailable.
This procedure is for community owners, build teams and organisers who already have BlueMap installed and need to approve its release. The deliverable is a short publication record with evidence and named owners. It is a proposed review process, not a confidentiality guarantee or an audit we have performed on your server.
Write a policy someone can test
Start with one sentence explaining the map's purpose: “Show the public district and its facilities without revealing the competition area yet.” Avoid an ambiguous requirement such as “make it private”, which different team members may interpret differently.
List the areas and data involved. Include every dimension, rehearsal worlds, unfinished builds, participant locations and markers supplied by integrations. Classify each item as public, restricted or excluded, and name someone who can approve changes.
Consider a hypothetical team that wants to showcase spawn and shops while keeping an arena for a later announcement. Its first release could cover only the public district, with no live player positions and a reviewed marker list. That is a proposed operational choice for this example, not a universal BlueMap configuration.
Agree what happens when the map and the project schedule disagree. If a build is visible before its announcement, who can stop publication? Give that person an actual procedure and access to the relevant system before sharing the link.
Limit the terrain being generated
BlueMap's render-mask can include or exclude areas, with masks processed in order. The documentation says changes update the map and remove tiles outside the defined area. Check your installed version and inspect the result before opening access. See the official mask documentation.
For the example, request publication of only the agreed district. Inspect its limits from above, in perspective and near the boundary. An excluded arena may still be easy to locate if a road, marker name or neighbouring structure points towards it. Review what a visitor can infer as well as the visible geometry.
Use coordinates approved for your world, rather than copying a demonstration. Save a screenshot of the permitted area and identify the configuration that produced it. If excluded blocks remain visible, pause the release and resolve the discrepancy before expanding the map.
Review positions and markers separately
live-player-markers controls position delivery to the web application through the integrated server. Periodic writes of player and marker data to storage are separate options. Check both routes and installed addons; disabling one route does not establish that the others are closed. See the plugin configuration reference.
Use a test account and an observer outside your network. Join, move between the public and reserved areas, change dimension and disconnect. Record what appears during each transition. If the policy forbids public positions, any visible coordinates require a correction in the responsible configuration or integration.
Review marker text too. Team names, links, coordinates and descriptions can reveal planned content without anyone being online. Assign someone to review manually maintained markers and someone to check automatic integrations. If another system recreates a deleted marker, removing it by hand only fixes the immediate symptom.
Include an update cycle in the rehearsal. A clean initial view is insufficient if the next scheduled import brings back the information you meant to exclude. Record which integration produced each problematic item so the responsible developer has a concrete case to investigate.
Check old data and alternative access routes
Removing a map from configuration does not remove all previously rendered data. The configuration guide treats those as separate steps. Before removing stored data, identify the correct map and storage and agree which copy should be retained outside public access.
For a restricted deployment, test the normal address and any direct route to the origin server. The integrated server has a configurable listening interface, documented in the webserver reference. Choose the topology for your deployment: a recipe for a proxy on the same machine cannot simply be transferred to separate machines or containers.
Ask the web operator to check data routes as well as the landing page, together with any cache or public copy used by the project. A fresh browser session helps reproduce the visitor experience. It cannot retract screenshots or files that somebody previously downloaded. If information must remain secret, the strongest approach is to avoid publishing it in the first place.
Approve a repeatable release record
Use a short record another team member can follow:
| Check | Evidence to retain | Release condition |
|---|---|---|
| Terrain and dimensions | Screenshots and identified configuration | Only approved areas appear |
| Players and transitions | Test-account observations | Position policy is respected |
| Markers and integrations | Reviewed list and update test | Excluded information does not return |
| Routes and old data | Project URLs checked and results | Restricted content is unavailable |
| Closing access | Owner and procedure | The team can withdraw publication |
Record the date, BlueMap version, environment, reviewer and exceptions. An unperformed check remains pending; a good-looking map homepage is not evidence for the rest. Repeat affected checks when worlds, masks, addons or web hosting change.
For help coordinating the server and web deployment, outline the environment and responsibilities in a managed infrastructure enquiry. For markers or access workflows connected to your own systems, define the custom integration: which information may leave the game, who approves it and what demonstrates acceptance. Projects are paid and individually scoped; ongoing support is agreed separately.
