Introducing PingCore Discovery: A Server List Without Storefront Lock-In
Build a live, searchable server list across storefronts, engines and hosting providers with PingCore Discovery’s simple heartbeat and public API.
Today, we are launching PingCore Discovery: a straightforward way for dedicated game servers to advertise themselves and for game clients to receive a live, searchable server list.
Each server sends a small HTTPS heartbeat containing its address, player count, version and any metadata the game needs. Clients use a public JSON endpoint to search, filter, sort and page through the servers currently available.
Discovery works with Steam, Epic Online Services or neither. It supports any engine that can send HTTPS and read JSON, and servers can run on PingCore, another provider, bare metal or a mixed fleet.
The result is a multiplayer server browser that belongs to the game rather than to one storefront or hosting environment.
Why server discovery still matters
Matchmaking has become the default route into many multiplayer games, but it does not replace every reason players need to see the sessions available to them.
A matchmaker chooses a session according to rules such as skill, party size and region. A server browser gives the player control. It lets communities return to familiar worlds, select a particular map or ruleset, find modded servers and understand where their session will run.
Many games benefit from offering both. Quick play can handle the fastest route into a suitable match, while a browser supports persistent communities, specific modes and player-run spaces.
The problem is that server lists are often attached to a storefront, engine SDK or hosting environment. That may be convenient at launch, but it can become restrictive when a game expands to another store, adds a platform, introduces community hosting or changes infrastructure providers.
PingCore Discovery separates the list from those decisions. Studios can change how the game is distributed or where its servers run without replacing the discovery experience players depend on.
Discovery is one focused infrastructure service
PingCore Discovery maintains an accurate list of game servers that clients can query.
It does not dictate the game engine, account system, storefront, hosting provider or player journey. It can operate alongside a platform-provided server list, replace one or provide discovery where no storefront service is available.
Keeping that boundary narrow makes the service useful during change. A studio can operate servers across several providers, move regions gradually or introduce community hosting while the game client continues to use one consistent API.
From dedicated server to browser in three steps
The integration has one authenticated write path for servers and one public read path for clients.
1. Create a Discovery App
A Discovery App provides a public ID that is safe to include in the game client. Studios can issue separate heartbeat tokens for production, staging, regions or server fleets.
Those boundaries make operations easier. A community-hosting token can be revoked without affecting the official fleet, and a staging environment does not need to share credentials with production.
2. Send a heartbeat
Each dedicated game server sends an HTTPS heartbeat every 30 seconds. It can include the server name, connection port, current and maximum players, exact game version and custom metadata such as map, mode, region, language or mod status.
If the heartbeat stops, the listing expires after three missed intervals. A server does not remain visible simply because a shutdown hook failed, its process crashed or the underlying instance disappeared unexpectedly.
The source address can be inferred from the request or supplied explicitly when the server sits behind NAT or another network layer.
3. Fetch the public list
The game client calls an unauthenticated endpoint using the app’s public ID. It can request only compatible servers—for example, sessions on the correct game version, with open slots, in a particular region or running a selected map.
The public ID can read the list but cannot publish heartbeats or manage the Discovery App.
More useful than a raw fleet dump
A good multiplayer server browser needs more than an array of addresses.
PingCore Discovery applies filtering, sorting and pagination before returning a response. Clients can search by name, require an exact version, show only servers with space, filter against custom metadata and sort by player count or last update.
Server-side querying matters as the fleet grows. A console or game client should not need to download thousands of listings merely to show the first 50 compatible results. Applying the same rules at the API also keeps behaviour consistent across PC, console, web and other supported clients.
Custom metadata leaves the product decisions with the studio. Discovery does not need to understand what “hardcore,” “roleplay,” “tournament” or a particular mod pack means. The server publishes the fields the game needs, and the client queries them through the same interface.
That supports official fleets, community servers, persistent worlds, public co-op sessions, temporary event servers and mixed-provider infrastructure without requiring a different discovery service for each one.
Keep unreachable servers out of the list
A heartbeat proves that a server can make an outbound HTTPS request. It does not prove that players can reach the advertised game port.
Discovery can therefore publish listings with no additional verification, test the endpoint over TCP or use a lightweight UDP echo challenge.
TCP verification opens and closes a connection to the advertised endpoint. UDP verification sends a short challenge that the game server echoes from its receiving socket. Without the expected response, the endpoint remains hidden.
These checks help catch a common class of failures: a process is running and able to report status, but its public port is blocked, misconfigured or routed incorrectly. Keeping that server out of the browser prevents players from selecting a session that could never accept them.
Studios that already guarantee reachability elsewhere can keep the integration simpler and list every valid heartbeat.
Separate server writes from client reads
Server registration and public discovery use different credentials.
Heartbeat tokens belong only on dedicated game servers. The public client ID grants read access to the list without authorising server publication or management operations.
This separation matters because anything shipped in a game client must be treated as public. If the credential required to publish servers were included in the client, it could be extracted and used to create fake listings.
Studios can issue and revoke heartbeat tokens independently for different environments or fleets. A compromised community token does not need to interrupt official servers, and operational credentials can be rotated without changing the public ID already shipped in the game.
Discovery and matchmaking work together
Discovery is not a matchmaker, and a matchmaker is not a server browser.
A browser exposes live sessions so players can choose. A matchmaker forms a group and places it according to the game’s rules. PingCore’s Matchmaking layer uses the same live Discovery state for fleet servers, avoiding separate and potentially conflicting views of availability.
A studio can use Discovery on its own, add PingCore’s ticket-based matchmaking or connect an existing matchmaker to server allocation. The underlying list remains available whichever player journey the game offers.
Adopt it without a migration project
A server-list service should not require the studio to replace the rest of its multiplayer stack.
If the dedicated server can send HTTPS and the client can read JSON, it can use Discovery. There is no required engine plugin, storefront SDK or hosting move.
Studios can begin with one environment, run Discovery beside an existing list and expand after the integration has been proven. Established games can use it as a storefront-independent fallback, unify servers across several providers or make it the common list while infrastructure changes underneath it.
A live server list under your control
Server discovery determines whether players can see the sessions that exist, understand what each one offers and connect to an endpoint that is genuinely available.
PingCore Discovery is available now. Create an app, issue a heartbeat token and connect the first server. Keep the engine, storefront and hosting model that suit the game—and keep control of the server list players rely on.
