Hey, thanks for reaching out. To answer your main question directly: yes, brainCloud's lobby and matchmaking system can trigger an Edgegap server deployment automatically. You do not need to build a custom C++ room server to make this work.

https://github.com/getbraincloud/examples-cpp/tree/develop/relaytestapp

The relaytestapp example on the develop branch of examples-cpp is a working client example that does exactly what you are describing. It uses brainCloud lobbies and matchmaking to find a match, and once the lobby is ready to launch, brainCloud handles spinning up the Edgegap server and passes the connection details back to all players through RTT.
The server configuration you see in the screenshot is what ties everything together on the brainCloud side. That entry defines which Edgegap application to deploy, which regions to consider based on the selected beacons, and the credentials needed to make the deployment call. Once that server is linked to a lobby type, the entire launch sequence is handled for you.
The relaytestapp is a solid starting point to see this end to end.
Screenshot 2026-05-07 at 12.13.17 PM.png

Hi, GetEligiblePromotions is snapshot-driven, not fully real-time. It relies on a cached promotion-eligibility snapshot stored on the UserProfile, which is only refreshed at specific points.

GetEligiblePromotions does not reevaluate Automated Promotion segment conditions (like experienceLevel >= 4) against the latest player state on every call. Instead, it uses the last calculated promotion snapshot that was written to the UserProfile. That snapshot is normally refreshed at login, or when you explicitly call the RefreshPromotions CAPI.

Because of that, the “delay” you are seeing is essentially “until the next snapshot refresh.” In your current flow, that refresh happens on the next login, which is why restarting the app makes the promotion suddenly appear. There is no fixed time-based delay; it is purely tied to when the snapshot is updated.

To make the promotion available immediately mid-session, add an explicit refresh step to your flow. After your CloudCode call to incrementExperiencePoints (once the player has reached level 4), call RefreshPromotions on the client, and then call GetEligiblePromotions. That will force an immediate refresh of the promotion snapshot so the level-4 promotion is returned without requiring a new session.

API details for RefreshPromotions:
https://docs.braincloudservers.com/api/capi/appstore/refreshpromotions.

Q1: The removed player is completely excluded from reward calculation, so if the deletion happens before the job runs, that player is never iterated over and receives no rank or rewards.
Q2: Yes, the modified score will be used. The job always reads live state. Note that whether the score actually gets modified depends on the leaderboard type (e.g., for the LOW_VALUE type, only updates if the new score is less than the existing)
Q3: No backfilling, the next joiner goes to the latest instance, not the freed spot in ^2. No loop over earlier instances (^1, ^2) ever happens. The next joiner goes to ^3 (or ^4 if ^3 is full). The freed spot in ^2 stays empty permanently.

brainCloud developers have just release several playable builds of our famous examples! See our cool features in action. Find them at https://getbraincloud.com/demos for Windows, Mac, online and mobile.