Environment Details

1 Introduction

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:

• Status
  • 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
• Name – the type of environment (Test, Acceptance, Production or the name of a flexible environment): see Naming of Environments for more information
• 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
• Secondary Backup Location the region where the backup is stored
• 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.

2.1 Actions

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 allows you to empty all the data from your database and, optionally, remove the app and file storage from the environment as well — see Clearing an Environment, below, for more information
• 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 Clearing an Environment

You can use the Clear Environment button to clear your environment so that you can use it for another purpose. This option is only available if the environment is stopped.

When you click Clear Environment you will have two options:

• Only clear the database – this empties all data from your database — after delete confirmation, the application will be stopped, the existing database will be deleted, a new database will be created, and the application will be restarted — ensure you have a backup of any data you want to keep
• Clear the full environment (model and database) (default) – this clears 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

You will need to confirm that you want to clear your environment by typing clear and clicking Clear Environment.

2.1.2 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.3 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.

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.

2.4 Overviews

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.

2.4.3 License

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)
• Limitations
  • 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.

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.

3.2 Constants

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.

For more information, see Constants.

4 Network Tab

On this tab, you can manage the elements described below.

4.1 Custom Domains

• Domain name
• Certificate
• 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)
• Edit
• Delete

For more information, see Certificates and Custom Domains.

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.

For the deprecated Mendix Cloud v3, only X-Frame-Options was supported. For Mendix Cloud v4 the HTTP headers which are supported in the Developer Portal are:

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.

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.

4.2.2.1 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.

4.2.2.2 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 SAMESITE_COOKIE_PRE_MX812 to true in custom environment variables, which will set SameSite=None; Secure; for all your cookies.

4.2.2.3 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 SameSite=None and Secure attributes.

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.2.3 Content Security Policy

A Content Security Policy informs the client (browser) where your page will load resources from. Setting this can make your app more secure by declaring trusted sources for your resources. For more information see the W3C recommendation Content Security Policy Level 2.

Setting a full content security policy is dependent on what your app does. However, a starting point which declares the content security policy which works with a basic Mendix app is given below:

default-src 'self' ; script-src 'self' 'unsafe-inline' 'unsafe-eval' ; connect-src 'self' ; font-src 'self' https://fonts.gstatic.com data: ; img-src 'self' data: ; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com ; base-uri 'self' ; form-action 'self' ; object-src 'none' ; frame-ancestors 'self' ;

If you have issues which appear to be related to a content security policy, you can use the console of your browser to investigate them.

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:

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:

• Path
• 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:

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

For more information about runtime settings, read the Runtime Customization and Advanced Custom Settings in Mendix Runtime documentation.

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:

• com.mendix.core.localfilesystem.cleaning.isEnabled
• com.mendix.core.localfilesystem.cleaning.time
• CACertificates
• ClientCertificatePasswords
• ClientCertificates
• DatabaseHost
• DatabaseJdbcUrl
• DatabaseName
• DatabasePassword
• DatabaseType
• DatabaseUserName
• DatabaseUseSsl
• DTAPMode
• EnableSessionFingerprinting
• JavaKeyStorePassword
• LogFileName
• MaxLogFileCount
• MaxLogFileSize
• MicroflowConstants
• MyScheduledEvents
• OracleServiceName
• ScheduledEventExecution
• TempPath
• WebServiceClientCertificates

6.2 Custom Environment Variables

Use the Custom Environment Variables to add, Edit, or Delete an environment variable.

Unlike the Custom Runtime Settings, most of the variables you add are chosen from a drop-down list.

Select Supported and you can choose from the following variables:

• APPMETRICS_TARGET – setting this enables business events to be sent to a different monitoring solution from the technical events
• DD_API_KEY – the API key used with Datadog
• DD_LOG_LEVEL – the log level of logging sent to Datadog
• DD_SITE – directs metrics to a specific Datadog region
• DATABASE_CONNECTION_PARAMS – Additional JDBC parameters for PostgreSQL databases, see the Mendix Cloud Foundry Buildpack for more information
• METRICS_AGENT_CONFIG – passes a configuration JSON to control the metrics passed to Datadog
• SAMESITE_COOKIE_PRE_MX812 – set SameSite=None;Secure for all cookies coming from the Mendix runtime, as described in the Running Your App in an Iframe section
• USAGE_METRICS_EMAIL_FIELDS – if your app uses specializations of the System.User entity to store users, use this variable to point to the them. This enables us to identify internal and external users of your app. The value of this variable is in the format Module.Entity.Attribute, where Module is the module of your app which contains the Entity that is a specialization of System.User and Attribute is the attribute that contains the email address of the user. If you have multiple specializations of System.User, you can specify the values in comma-separated format. That is Module1.Entity1.Attribute1,Module2.Entity2.Attribute2,…,ModuleN.EntityN.AttributeN. In the following example there are two specializations identified: Administration.Account.Email,MendixSSO.MendixSSOUser.EmailAddress.

In addition, to support features which are in beta, you can add Unsupported environment variables. If you are involved in using a beta feature, you will be told what Name needs to be entered here and what the Value should be.

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.