Yes, it is possible, but not directly inside index.html in the same way as a Mendix constant.
The main limitation is that index.html is a static file. Mendix constants can have different values per environment, and those values are managed in the environment configuration, but a static index.html file does not automatically resolve Mendix constants when the browser loads it.
So the practical pattern is usually this:
You keep the GTM container ID in a place that can vary per environment, such as a Mendix constant or another runtime configuration source. Constants are specifically meant for configuration values that can differ per environment.
Then, instead of hardcoding the final GTM ID directly in the <head>, you load or inject it after the app starts, using JavaScript. In Mendix, that usually means a small JavaScript action, custom widget logic, or another client-side script approach. JavaScript actions are supported for extending client behavior and are called from nanoflows.
A common flow would be:
Your environment stores a different GTM ID for Test and Production. Your app reads that value at runtime. A small JavaScript snippet then creates the GTM script dynamically with the correct container ID.
That way, the value is still environment-specific, but the decision happens at runtime instead of directly in the static index.html. This is usually the cleanest Mendix-friendly approach.
One more thing to keep in mind is Content Security Policy. If you load Google Tag Manager from your app, your CSP must allow those external resources. Mendix documents CSP as the mechanism that controls which resources your app is allowed to load in the browser.
So in short:
No, you normally cannot make index.html itself behave like a Mendix constant file.
Yes, you can still support different GTM IDs per environment by storing the ID in runtime configuration and loading the GTM script dynamically with JavaScript after the app starts.
Hi,
Yes, this is possible, but index.html itself cannot directly read Mendix constants or environment settings, because it is served as a static file before the Mendix runtime initializes. So you cannot dynamically switch values inside <head> using a Mendix constant.
The common and working Mendix approach is to inject the correct value at runtime using the Mendix client configuration object (mx.config) or environment variables.
Below are two approaches that are commonly used.
mx.config.environment in index.html Mendix exposes the environment type in the browser through:
mx.config.environment
Values returned are usually:
Production Acceptance Test Development
So you can load the correct Google Tag Manager container like this inside index.html <head>:
<script>
document.addEventListener("DOMContentLoaded", function () {
var gtmId;
if (mx.config.environment === "Production") {
gtmId = "GTM-PROD123";
} else {
gtmId = "GTM-TEST123";
}
var script = document.createElement("script");
script.innerHTML = "(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':" +
"new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0]," +
"j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=" +
"'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);" +
"})(window,document,'script','dataLayer','" + gtmId + "');";
document.head.appendChild(script);
});
</script>
This will automatically load the correct GTM container depending on the environment.
In Mendix Cloud, you can define environment variables such as:
GTM_CONTAINER_ID
Example values:
Test / Acceptance
GTM-TEST123
Production
GTM-PROD123
Then inject it through JavaScript:
var gtmId = window.mx.config.custom.GTM_CONTAINER_ID;
This requires exposing the variable via a small script or configuration.
You cannot use Mendix constants directly inside index.html, because:
index.html loads before runtime initializationThat is why environment detection via mx.config.environment or environment variables is the correct solution.
Best practical solution:
Use:
mx.config.environment
inside index.html and load the correct Google Tag Manager ID based on environment.
This approach works reliably for:
without needing separate builds of the app.