To enter the Environment details page, go to the Developer Portal, select your licensed app, click Environments, and then click Details on the specific environment.
2 General Tab
The view of the General tab depends on the Mendix Cloud version on which the app is hosted. In this tab, you can find the following information about your environment:
- White – the environment is stopped or was never deployed
- Green – the environment is working correctly
- Orange – the environment has warnings
Red – the environment is not working correctly
Running since date – the date on which the app was started
URL – the URL of the app
Project ID – the unique identifier for your Mendix app
Environment ID – the unique identifier of this environment
Custom domains – the custom domains of the app
Java Version – Oracle version 1.8 or AdoptOpenJDK version 8
Mendix Studios Target – whether this environment is the one where apps will be deployed from Mendix Studio - see Studio Deployment Settings for more information
Plan – (Cloud v4 only) the type of plan covered by this license
Instances – (Cloud v4 only) A summary of the number and memory allocation of instances of this environment: see Scaling… for more information
Database Status – (Cloud v3 only) this is Running by default
Database Version – the PostgreSQL version that is supporting the database
Region - the region where the app is hosted
Mendix Cloud Version – Mendix Cloud v3/Mendix Cloud v4
At the bottom of the page there are three overview sections. These are described below in the Overviews section.
On the right side of the screen, you can find the following action buttons:
- Restart Application – this stops the running application and starts it again — this is necessary to apply new constant values or scheduled events to the environment
- Start/Stop Application
- Clear Environment (only visible if your application is stopped) – this clears, after confirmation, all data from your database and file storage, and removes your app from this environment — you should do this if you want to deploy a different app to this environment, it is not necessary if you are restoring a backup of the same app
- Show Logged in Users
- Change Admin Password – this changes the password for the inbuilt administrator account — the new password is applied immediately, without the need for a restart and will also force the administrator to pick up any new roles assigned in the app deployment package — see the User Role section of Administrator for more information
2.1.1 Logging and Debugging in Mendix Cloud v4
In Mendix Cloud v4 environments, you have two additional action buttons:
- View Live Log
- Show debugger information – shows the settings needed to connect the debugger in Studio Pro to your app — for Mendix Cloud v4, the debugger is always enabled — for more information on debugging in the cloud, see How To Debug Microflows Remotely
2.1.2 Logging and Debugging in Mendix Cloud v3
In Mendix Cloud v3 environments, you have two additional action buttons:
- View Current Log
- Enable/Disable Debugging – enables or disables the debugger option — for more information about enabling the debugger, see How to Debug Microflows Remotely
2.2 Naming of Environments – Flexible Environments in Mendix Cloud v4
If you are the Technical Contact of the app, you can rename the environments as you wish.
Click the Change button next to the name of the environment.
The name must be at least two characters and consist of alphanumeric characters and hyphens (
-) but cannot begin or end with a hyphen.
If you rename an environment, it may take up to 15 minutes before you can access an app via its URL. This is because the URL includes the name of the environment and the old value needs to be removed from the DNS cache. It may take considerably longer for the change to be visible worldwide.
2.3 Scaling – Mendix Cloud v4
If your app is hosted in Mendix Cloud v4, you will see a section named Instances in the General tab. Click the Change scaling button to see the options for changing the scaling.
In Scaling, there are two sliders that you can control:
- Use the Instances slider to increase or decrease the amount from one to four instances by sliding the slider
- The instances are meant for improved resiliency and increased processing power
- The minimum amount of RAM memory per instances is 1GB; you can spread the RAM memory among four instances if you have more than 1GB of RAM memory
- Use the Memory per instance slider to increase or decrease the memory amount per instance by sliding the slider
The Total Allocated Memory is a process circle that shows how much memory is currently used for scaling.
If you have 1GB RAM of the Total Allocated Memory, you have one instance available to store your memory.
To scale your memory over multiple instances, you need more memory.
At the bottom of the page, there are three overview grids with information about the information below.
2.4.1 Deployment Package Details
In this section, you can find information about the deployment package that is currently loaded into the environment:
- Name of the deployment package
- Version of the deployment package
- Runtime version of Mendix used to create the app
- Size (MB) of the deployment package
- Upload date of the deployment package
2.4.2 Plan Details - Mendix Cloud v4
This section shows details of the plan which applies to this environment.
The license overview contains the following information:
- Company owning the license
- Is Production shows if this environment is licensed as a production environment
- Expiration date
- Runtime mode (Production, Acceptance, Test)
- Limitation type (see below for details)
- Amount type
- Number of allowed users
The limitation types are the following:
- Concurrent – the number of named users that are logged in simultaneously
- Concurrent anonymous – the number of anonymous users that are logged in simultaneously
- Named – the number of named users registered in the database that are allowed to use the application
3 Model Options Tab
On this tab, you can edit the model options described below.
3.1 Scheduled Events
In this section, you can view your configured scheduled events.
If you select a scheduled event and click Toggle, you can switch the scheduled event off and on.
You have to restart your application before the changes will be made.
With scheduled events, you can let the Runtime execute a microflow at a specific moment in time. The event can also be repeated with a given interval (for example, every day).
For more information, see Scheduled Events.
In this section, you can view the configured constants. Constants are used to define configuration values that can differ per environment.
To fill in a new value, select the constant and click Edit.
Here you can type a New value.
You can also set Mask to Yes. This replaces the Current value and the New value with asterisks on all screens in the Developer Portal. You will also get asterisks if you export the constants to Excel. This means that you can keep your constants secret from users who do not have edit rights.
You have to restart your application before the changes will be made.
For more information, see Constants.
4 Network Tab
On this tab, you can manage the elements described below.
4.1 Custom Domains
- Domain name
- Expire date
You can perform the following actions:
- Create (in which you have to provide the domainname and select the certificate from a drop-down menu)
4.2 HTTP Headers
HTTP Headers allows you to set the values of selected HTTP response headers. These allow the server to pass additional information with the response which the browser will interpret to control the behavior of your Mendix app.
This replaces the option to prevent embedding your app in an iframe with more flexible options to set HTTP Headers.
For Mendix Cloud v3, only X-Frame-Options is supported. For Mendix Cloud v4 the HTTP headers which are supported in the Developer Portal are:
|Access-Control-Allow-Origin||indicates whether the response can be shared with requesting code from the given origin|
|Content-Security-Policy||allows web site administrators to control resources the user agent is allowed to load for a given page||a string value
for more information see the W3C recommendation Content Security Policy Level 2
|Referrer-Policy||governs which referrer information should be included with requests made|
|X-Content-Type-Options||indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed|
|X-Frame-Options||indicates whether or not a browser should be allowed to render a page in a
||The default is not to allow apps to be rendered inside frames.
This was the value set previously to prevent embedding in an iframe
See Running Your App in an Iframe, below, for information about running your app inside an iframe.
|X-Permitted-Cross-Domain-Policies||specifies whether this page can load resources from a different domain|
|X-XSS-Protection||stops pages from loading when they detect reflected cross-site scripting (XSS) attacks|
There are three types of value for these headers:
Choose a value from a drop-down
Choose a value from a drop-down and specify a URL
Enter the required values as a string
The changes to the headers will be implemented when the app is redeployed.
Additional information can be found in the Mozilla developer guide HTTP headers.
4.2.1 HTTP Response Headers Inserted Automatically
A number of non-configurable response headers are added automatically by Mendix and the deployment environment. These are listed below.
|Response Header||Added in|
|cache-control||the buildpack for index.html and login.html — the Mendix Runtime for other pages|
|strict-transport-security||TLS terminating webservers - this is set to
|x-vcap-request-id||Cloud Foundry to track requests through CF|
4.2.2 Running Your App in an Iframe
Most browsers have additional security to ensure that iframes are only allowed when they are from the same domain as the main page. The defaults for these vary by browser version. This security is controlled through SameSite cookies. You can find a good explanation of SameSite cookies in SameSite cookies explained on the web.dev website.
There can be additional issues when using cookies in iframes for end-users using the Safari browser. Resolving these issues is outside the control of Mendix. See the Full Third-Party Cookie Blocking and More blog post on Webkit.org for more information.
18.104.22.168 Using Custom Domains
To avoid security issues when you want to embed the app in an iframe, we recommend that you use custom domains to ensure that the app you want to embed is part of the same domain. For example, if your page is mainpage.domain.name, then the app embedded in the iframe should be appname.domain.name.
22.214.171.124 Applying a Different SameSite Setting
From Mendix version 8.12, you can control the value of SameSite in your cookies. The default for all cookies is
SameSite=None, which means that they can be used in an iframe. You can change this value in the
com.mendix.core.SameSiteCookies custom runtime setting if you want to add restrictions to apps running outside iframes.
For Mendix versions below 8.12 there was no SameSite value set on cookies and the behavior is dependent on the browser default. To ensure that cookies can be used within iframes, you can set the custom environment variable
true in custom environment variables, which will set
SameSite=None; Secure; for all your cookies.
The SAMESITE_COOKIE_PRE_MX812 setting will only be implemented the next time your app is deployed.
126.96.36.199 Using Custom Sign In Pages
If you use a custom sign in page, your index.html will probably set the
originURI cookie. If your Mendix app runs within an iframe, this cookie needs to be set with the
To do this, find all the places in your theme folder where this cookie is set. It will look like
document.cookie = "originURI=/login.html".
Change this to add the required attributes. For example,
document.cookie = "originURI=/login.html" + (window.location.protocol === "https:" ? ";SameSite=None;Secure" : "").
4.3 Outgoing Connections Whitelisting (Mendix Cloud Dedicated)
If you are deploying your apps to Mendix Cloud Dedicated, all outgoing IP addresses will be allowed by default.
If you uncheck the Allow all outgoing connections option, you can define which IP addresses and ports can be used for outgoing connections in this section.
You can add or edit a number of different IP address and port combinations. Any ranges which have already been set up will be listed here. You can do the following:
- Select Allow all outgoing connections to remove any restrictions, or deselect it to impose restrictions
- Click New to add a new range
- Select an existing range and click Edit to edit an existing range
- Select an existing range and click Delete to delete an existing range (you will be asked to confirm that you want to delete this range)
4.3.1 Managing a Whitelist Range
For each range where you define whitelisted IP addresses and ports, you can enter the following information:
- Name – A name to identify this range
- IP – An inclusive range of whitelisted IP addresses in IPv4 format. All the IP addresses must be in a public range, see Valid IP Ranges, below. All addresses between the Start address and the End address will be whitelisted, including the start and end addresses. If you only want to whitelist a single address, make the start and end addresses the same
- Port – An inclusive range of ports which will be whitelisted for the IP range above. You can use several whitelist entries if you want to whitelist different port ranges for the same IP range
- Protocol – You can specify whether the whitelisting is for TCP, UDP, or ALL traffic
- Description – an optional description of this IP range, for example which API it supports
Click Save to save your range. The new values will be applied within a few minutes without needing an app restart.
4.3.2 Valid IP Ranges
IP Addresses must be within the following ranges:
|IP Start||IP End|
4.4 Path-Based Access Restrictions
You can restrict access to your application by means of Client Certificates or IP ranges.
The top level path (
/) restricts access to the entire application. Settings for specific paths override the implicitly inherited profile for the top level.
Custom access restriction profiles are managed at the application level. They can be reused for all environments (acceptance, production, etc).
The Path based access restrictions overview contains the following information:
- Current Restriction Profile
- New Restriction Profile
You can Delete a path or you can Add and Edit a path with the following restriction types:
- Allow all access
- Deny all access
- Custom Profile for Client Certificates and/or IP ranges
- N/A (inherit)
For more information, see How to Restrict Access for Incoming Requests.
4.5 Outgoing Connections Certificates
Add client certificates (in the PKCS12 format) or certificate authorities (in the PEM format). These will be used when your application initiates SSL/TLS connections.
5 Log Levels Tab
Log levels are used to distinguish the log messages and to highlight the highest priority ones so that they can receive the immediate intervention they require. Note that custom log nodes appear in the list only after a message has been logged to them. See Log Message for more information.
On this tab, you can perform the following actions:
- Change the log level type by clicking the specific level
- Click Set all to INFO to revert all the changes
The log level types are the following:
|Trace||More detailed information. These are only written to logs.|
|Debug||Detailed information, typically of interest only when diagnosing problems.|
|Info||Confirmation that things are working as expected.|
|Warning||Orange||Indicates that something unexpected happened or that there is some problem in the near future (for example, “disk space low”). The application is still working as expected.|
|Error||Red||Due to a more serious problem, the application has not been able to perform some function.|
|Critical||White (text), red (background)||A serious error has occurred, indicating that the application itself may be unable to continue running.|
For more information about log levels, see How to Set Log Levels.
6 Runtime Tab
On this tab, you can add Custom Runtime Settings and Custom Environment Variables
6.1 Custom Runtime Settings
Use the Custom Runtime Settings section to perform the following actions:
- Add a new runtime setting with a new value
- Edit the runtime setting
- Delete the runtime settings
The Mendix Cloud uses runtime settings to configure the included systems for logs, backups, and database. Therefore, the following settings are not configurable by users:
6.2 Custom Environment Variables
Use the Custom Environment Variables to add, Edit, or Delete an environment variable.
Unlike the Custom Runtime Settings, the variables you add have to be chosen from a drop-down list. The variables are:
- DD_API_KEY – the API key used with Datadog
- DD_LOG_LEVEL – the log level of logging sent to Datadog
- DATABASE_CONNECTION_PARAMS – Additional JDBC parameters for PostgreSQL databases, see the Mendix Cloud Foundry Buildpack for more information
- APPMETRICS_TARGET – setting this enables business events to be sent to a different monitoring solution from the technical events
- SAMESITE_COOKIE_PRE_MX812 – set
SameSite=None;Securefor all cookies coming from the Mendix runtime, as described in the Running Your App in an Iframe section
7 Maintenance Tab
There are two types of maintenance:
- Regular weekly maintenance (which does not affect your app), during which you can change the preferred maintenance window
- Planned maintenance (which will affect your app in some ways), about which you will automatically receive an email and you can override the maintenance window if necessary
For more information about maintenance, see Maintenance Windows: Configuration.
7.1 Preferred Maintenance Window
You can view and change the preferred maintenance.
7.2 Planned Maintenance
When a maintenance operation is planned, it will show up under Planned Maintenance. By default, this will be planned in your preferred maintenance window. You can override the maintenance window of a specific maintenance operation by clicking Override.
You will automatically receive email notifications about planned maintenance.
8 Tags Tab
You can set tags on your environment. These are arbitrary strings that are not interpreted by the Developer Portal. Tags serve two purposes:
- Custom tags can be added to metrics for third-party metrics solutions
- Tags can serve as selection criteria for grouping environments into a landscape management dashboard which can be used for third-party logging solutions
For example, you may wish to use tags when logging with Datadog. You can find more information on this at Getting started with tags on the Datadog site.