The problem: a shared world without shared context
A Palworld server is a place a group inhabits together, but most of its useful context is scattered. Players ask who is online, where a teammate went, which base belongs to which guild, or where to find the next resource. The answers often live in chat messages, screenshots, or somebody else's stream.
Putting that context on a map sounds straightforward until the server boundary matters. A useful map needs current information, but a community should not have to publish its Palworld REST port, hand out server credentials, or expose more data than the viewer actually needs.
Pal-Map was built around both sides of that problem: make the world easier to understand while keeping the game server private.
One hosted map for the guild
Pal-Map turns a Palworld server into a stable, hosted map that players can keep on a second screen, check from a phone, or share with the rest of the group. It brings several kinds of live context into one place:
- Online players and their current positions.
- Bases, guilds, and other shared server details.
- World layers for fast travel, resources, dungeons, bosses, merchants, and other places worth finding.
- Region switching for moving between the game's maps.
The administrator controls how the map is shared. A map can be public, unlisted, or password protected, so the same product can support an open community or a private group.
Privacy is part of the product
The collector runs beside the Palworld server and talks to its REST API over the private network. Palworld credentials stay there. The collector sends an allowlisted, versioned snapshot outward over HTTPS, so Pal-Map never requires an inbound public product port.
That snapshot is intentionally smaller than the server response. It does not include the REST password, raw platform identifiers, IP addresses, or server save data. The hosted service keeps the latest map state rather than building a location-history archive.
The hosted service also decides what each viewer is allowed to receive. Access rules are enforced before the map data reaches the browser, rather than depending on the interface to hide sensitive fields after delivery.
From server to map in three steps
- Run one small collector. The administrator follows the Docker Compose setup and gives the collector private access to the Palworld REST API.
- Send only map-ready data. The collector filters the response and submits the privacy-conscious snapshot over outbound HTTPS.
- Share the hosted viewer. Players open one stable link with the access level chosen by the administrator.
The public collector makes this boundary inspectable. Server owners can review the code that handles their local credentials and prepares the outbound snapshot before choosing to run it.
PvP without perfect information
Exact live positions are useful for cooperative play, but they can remove too much uncertainty from PvP. Pal-Map includes six server-controlled activities that turn map information into part of the match: Sector Sweep, Flashpoints, Motion Heat, Signal Storms, King of the Hill, and Champion's Chase.
The first five modes replace exact player plots with broader signals such as occupied sectors, contested areas, or movement clues. Champion's Chase intentionally reveals one selected target while its timer is active. The server remains authoritative about which information the viewer receives.
Where it is today
Pal-Map is live in a private, invite-only preview. Invited administrators can configure servers and share maps now; viewers only need the map link supplied by their administrator. The preview keeps onboarding deliberate while setup and support continue to be refined.