Need way to change environment at run time

[JetForMe]

Need way to change environment at run time

There doesn't seem to be a way to change the environment used at runtime. But debug versions of our app allow the user to select whether or not they're pointing to our staging or production environments. It would be nice to be able to change DataDog's environment as well.

[odaeagle]

need this feature too, we have the exactly situation described above, it's not a deal-breaker (app store user will never be able to switch server) but definitely nice to have

[ncreated]

Hello @JetForMe @odaeagle 👋. We've been discussing this in the team and unfortunately this isn't something we're considering for close future as it seems very specific. Today, env can be only set on SDK initialization. However, please consider requesting this feature through our support channels which will help us triage its popularity and eventually jump on this earlier.

[JetForMe]

Doesn't seem specific at all. I've worked at many companies that had the ability to change the targeted environment at run time. Your SDK can't even be reinitialized.

[johntmcintosh]

We are evaluating integrating DataDog and I was surprised to find that this was not a capability. Every app I've worked on has supported an internal build with an ability to modify the network environment at runtime, so not supporting a way to pass that change into the SDK is limiting for our ability to get reliable data out of the non-production environments.

[MarcelCvent]

I would like to request this as well... not only is it super common for development builds to have many selectable environments - but with regulations like GDPR it is not uncommon to have separate production environments for different regions like the EU.

Datadog themselves have multiple production environments with a separate one for the EU - so don't think that they could legitimately claim that the ability to select between multiple environments is an odd one.

The inability to reinitialize the Datadog SDK, or at least modify the environment, is extremely limiting in putting Datadog in use in many real-world situations.

[backslash-f]

~How is this a thing in 2025? To my surprise, I'm unable to reinitialize the Datadog SDK when my app testers change the environment. I have to force kill it, which pollutes our analytics. It's 2025, people!~

See @ncreated message below. That does it. Thanks for sharing! 👍🏻

[shagedorn]

We also miss this ability – not just for the environment. Some way to re-initialize/re-configure the SDK without forcing an app relaunch would be appreciated.

[ncreated]

Hello everyone 👋. In version 2.7.0, we introduced the stopInstance() method, which can be leveraged to restart the SDK with a new configuration. This can be particularly useful in internal testing, QA, or debugging scenarios where you might need to switch environments (or other configurations) at runtime.

An example of switching env at runtime:

func startDatadog(with environment: String) {
    Datadog.initialize(
        with: .init(
            clientToken: "client-token",
            env: environment
        ),
        trackingConsent: .granted
    )
    RUM.enable(with: .init(applicationID: "app-id"))
}

func stopDatadog() {
    Datadog.stopInstance()
}

Key Points:

• The stopInstance() method tears down the entire SDK, including all enabled features (e.g., RUM, Logs, etc.).
• After calling stopInstance(), you can reinitialize the SDK with a new configuration (for example, a different env or site).
• Since stopInstance() tears down all features, you don't need to disable them individually. However, when restarting the SDK, you'll need to re-enable each feature you require.

We hope this approach addresses all the concerns raised in the previous discussions. Let us know if this works for you 🙏.

[shagedorn]

Seems like we completely missed this/assumed it wasn't there. That behaviour sounds exactly like what we want. Thanks for pointing it out and providing extra context 🙏🏻

[ncreated]

🚀 @shagedorn We're happy to hear that this approach works for your use case! For that reason, I'll go ahead and close this issue (feel free to still add comments tho).

Apologies for not updating this thread sooner after the 2.7.0 release — it just went off our radar. We understand this isn't as simple as a dedicated "change env" API, but due to the implicit complications (especially around managing pending RUM sessions that must be, by design, limited to a single env), we believe that using stopInstance() provides a good compromise between the feature and the complexity.

[diegodorado]

Maybe related to this: if the app is initialized from the js side, and then the js side only gets restarted ( as a codepush restart), is the native side skipping the re-initialization caled from the js side again? I could open a new issue if this is confusing the thread, but I am seeing error logs that belongs to an OTA update with the version suffix of the previous one so I am suspecting there is a silent skip of a re-initialization