Hello @Paul-Winterhalder

I apologize for the repeated questions, but I am following up on this again because our live service experiences a temporary outage every time we attempt to deploy only data to our production environment.

Even when the operation is strictly intended to deploy only customEntities, as shown in the payload below, the temporary "App is disabled" state still occurs:

{
...
"allowLiveUpdate": true,
"components": {
"meta": true,
"scripts": false,
"files": false,
"customEntities": true,
"legacyFiles": false
},
"options": {
"meta": {
"excludes": {
"itemCatalog": true,
"productPricing": false,
"pushCertificates": true,
"integrations": true,
"myServers": true,
"lobbies": true,
"leaderboardsTournaments": true,
"independentLeaderboards": true,
"divisionSetConfigsOverride": true,
"migratableGlobalEntities": true,
"migratableCustomEntities": false,
"selfServiceBranding": true
}
}
}
}

We would like to know the exact scope of deployment conditions where the "App is disabled" state does not occur. While we understand that it might not be possible to prevent the disabled state across all deployment processes, we would like to at least define and narrow down the conditions.

We are hoping there is a way to migrate at least customEntities between environments without triggering the app disabled state. It would be even better if there were a way to specify and migrate each collection individually.

Unfortunately, our notification templating system is very simple and currently only supports simple text notifications. It does not currently push a template id.

We do have plans to revamp the system on our "to-do" list - but it has not been scheduled yet.

We recommend folks use the "raw" template calls - they give devs the most control over what gets sent to the various notification systems.

Paul.

@Paul-Winterhalder
Thank you! Supporting this feature would be a tremendous help in maintaining the stability of our live service.

Could you please leave a comment once a decision is made on how this will be handled?

As soon as the feature is supported, we will make sure to implement it into our live service immediately.

Thanks Paul, that makes sense.

For now, we’ll keep using a dedicated internal/service profile with getSessionForProfile() + callAPIForSession() as a temporary workaround for our monthly transaction reporting job.

Could you please confirm whether this workaround is safe to use temporarily in production, as long as we do not include a profileId in the search criteria and only use the session to authorize the request?

Also, we’d appreciate it if you could let us know once the S2S proxy hookup for SYS_GET_TRANSACTIONS_PAGE has been reviewed or fixed.

Thanks again for checking into this.

hi. @Paul-Winterhalder
yes, permissions to call specific scripts and access control for Services and Operations regarding the generally provided functions are required.
For example, there may be management tools that call specific scripts and use certain functions (CloudData...),
and there may be administrators who only manage items.
If possible, each API Key should be a function with permissions tailored to the situation.

Let me give you an example. A company utilizes a mix of office and remote work. While the internal network can be protected to some extent by IP ranges, it is difficult to identify specific IPs because multiple operators work from home. Therefore, it is currently somewhat difficult to handle this situation using only IPs.

The SDK is just a plain C# source library you can drop into any .NET project (not Unity-only). You can find usage examples and the source in our GitHub repositories at https://github.com/getbraincloud.

@JasonL At the time I reported this, that field was locked too, so it couldn't be edited — but I've now confirmed that it's editable.

Added the additional details to 13660

Case 13633 - [implementing]

@Paul-Winterhalder , could you please respond to @noah 's inquiry?

It's been resolved. Thank you for your response!

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

@Paul-Winterhalder Hello! Here is my app Id "15675

Thanks @Brad-Hester !

We’re planning some major changes to our push notification system, it’s more than just adding a few titles and content fields to the templates. It's not a near-term, stay tuned!

Agreed @armitage - the bulk messaging feature is planned for the use case you describe... (and yup - still coming 🙂 ).