Environment Details

Introduction

To open the Environment Details page, go to Apps and click Environments on your licensed app. Then click Details ( ) by the environment you want to view.

The Environment Details page shows information about the selected environment and includes eight tabs: General, Model Options, Network, Log Levels, Runtime, Maintenance, Tags, and Services. You can also use this page to manage and debug several aspects of the environment.

Actions

On the top right side of the screen, there are a number of action buttons and a More Options ( ) menu that you can use to perform various actions. Some action buttons are visible when your app is running, some are visible when your app is stopped, and some are always visible.

Running App Actions

When your app is running, you can perform the following actions:

• Deploy – This deploys an application to the environment.
• Restart App – This stops the running application and starts it again. Restarting your app is required for applying new constant values or scheduled events to the environment.
• Stop App – This stops the application.
• More Options:
  • Show Logged in Users – This shows all users who are logged in to your app.
  • Change Admin Password – This changes the password for the built-in administrator account. The new password is applied immediately, without the need for a restart, and forces the administrator to pick up any new roles assigned in the app deployment package.
  • View Live Logs – This shows a live log of your application and performs the same action as the View Live Log button on the Logs page.
  • Show Debugger Info – This shows the settings needed to connect the debugger in Studio Pro to your app. For more information on debugging in the cloud, see How To Debug Microflows Remotely.
  • Show Running Now – You can use this to monitor all actions that are currently running in your environment. For more information, see Running Now.

Stopped App Actions

When your app is stopped, you can perform these actions:

• Deploy – This deploys an application to the environment.
• Start App – This starts the application.
• More Options:
  • Clear Environment – This allows you to empty all the data from your database and, optionally, remove the app and file storage from the environment. For more information, see Clearing an Environment.
  • View Live Logs – This shows a live log of your application.

Clearing an Environment

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

To clear your environment, follow these steps:

1. Click Clear Environment.

2. Select one of the following options:

   • Only clear the database – This removes all data from your database tables. Ensure you have a backup of any data that you want to keep.

     After you confirm the deletion, the application is stopped, the existing data is removed from the database, and the application is restarted. Note that the database retains some information, such as logs and system data.

   • Clear the full environment (model and database) – This clears all data from your database and file storage. It also removes your app from this environment. Clear the full environment if you want to deploy a different app to the environment.

3. Confirm that you want to clear your environment by typing the indicated text (clear database or clear model and database, depending on which option you selected).

4. Click Clear Environment.

The General Tab

In the General tab, you can find four sections that provide information about the application status, deployment package details, plan details, and license.

Application Status

In the Application Status section of the General tab, you can find the following information about your environment:

• Status
  • – The application in this environment is running
  • – No application has been started yet in this environment, or it has been turned off
  • – The application in this environment is experiencing some difficulties; check the alerts page or logs for more information
  • – The application in this environment is unstable and probably not usable anymore
• Project ID – the unique identifier of the app
• Environment ID – the unique identifier of the environment
• Running Since – the date the app was started, if it is running
• Name – the type of environment (Acceptance, Production, Test, or the name of a flexible environment); for more information, see the Naming of Environments section below
• URL – the URL of the app
• Custom Domains – any custom domains of the app; to add a new domain, click Add Custom Domain
• Studio Pro Target – a Yes or No value indicating whether the environment is the designated deployment target from Studio Pro; for more information, see Studio Pro Deployment Settings
• Java Version – the JDK version selected for the MDA that is deployed to the environment
• Database Version – the PostgreSQL version supporting the database
• Region – the data center region where the app is hosted (for the full list of Mendix Cloud regions, see Outgoing IP)
• Data Backup Secondary Location – the region where the backup is stored (for more information, see Data Location in the Backups documentation)

Naming of Environments – Flexible Environments in Mendix Cloud

If you are the app's Technical Contact, you can rename the environments.

To rename an environment, follow these steps:

1. Click Change next to the name of the environment.
2. Enter the new name, which must meet the following requirements:
   • Consists of at least two characters.
   • Consists of only alphanumeric characters and hyphens (a-z, A-Z, 0-9, and -).
   • Does not begin or end with a hyphen.

Deployment Package Details

In this section, you can find information about the deployment package that is 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

Plan Details

This section shows details of the plan that applies to this environment.
It also includes the option to change your plan. For details, refer to Changing Plan.

• Name – the type of plan associated with your license
• Instances – the number and memory allocation of instances in the environment (for more information, see the Scaling)
• Memory – the total allocated memory of the plan
• Database Plan Cores – the CPU cores allocated to the database
• Database Plan Space – the storage capacity of the database
• Database Plan Memory – the database's RAM size
• File Storage – available size for storing blobs
• Backup Storage – total size available for database backup files
• Multi-AZ Enabled – a Yes or No value indicating whether multiple availability zones are enabled

Scaling

To see the options for changing scaling, click Scale on the Instances row. This will open the Change Scaling dialog box, which includes two sliders that you can control:

• Use the Instances slider to increase or decrease the number of instances
  • The instances are meant for improved resiliency and increased processing power
  • The minimum amount of RAM per instance is 1 GiB; you can spread the RAM among four instances if you have more than 1 GiB of RAM
• Use the Memory per instance slider to increase or decrease the memory amount per instance

The Total Allocated Memory is represented by a progress circle that shows how much memory is currently used for scaling.

If you have 1 GiB RAM of total allocated memory, you have one instance to use your memory. To scale your memory over multiple instances, you need more memory.

For more information, see Scaling Your Environment.

License

The license overview contains the following information:

• Company – who owns the license
• Is Production – indicates if the environment is licensed as a production environment
• Runtime mode – Production, Acceptance, or Test

The Model Options Tab

On this tab, you can edit the model options for constants and scheduled events.

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 to bring up the Edit Constant dialog box.

In the Edit Constant dialog box, you can change the constant value using the New Value field.

You can also set Mask to Yes to change the display settings for Current Value and New Value. When masking is enabled, all screens in the Mendix Portal (and in Excel if you export the constants) conceal their values and display asterisks in their place. This keeps your constants secret from users with no edit rights.

For more information, see Constants.

Comparing Constants

You can export the constant values to an Excel file by clicking Export To Excel, or compare the values across different environments by clicking Compare and Edit.

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 Mendix Runtime run a microflow at a specific moment in time. The event can also be repeated with a given interval; for example, you can set it to repeat every day.

For more information, see Scheduled Events.

The Network Tab

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

Custom Domains

• Domain Name
• Certificate
• Expire date

You can perform the following actions:

• Add – provide the domain name and select the certificate from a drop-down menu
• Edit – update the domain details
• Delete – remove domain

For more information, see Certificates and Custom Domains.

HTTP Headers

The HTTP Headers section lets you set the values of selected HTTP response headers. These headers allow the server to pass additional information with the response, which the browser interprets to control the behavior of your Mendix app.

Mendix Cloud supports the following HTTP headers in the Mendix Portal:

There are three types of values for these headers:

• Choose a value from a drop-down menu:

  

• Choose a value from a drop-down menu and specify a URL:

  

• Enter the required values as a string:

  

The changes to the headers are implemented when the app is redeployed.

For more information about HTTP headers, see MDN's HTTP headers overview.

HTTP Response Headers Inserted Automatically

Mendix and the deployment environment automatically add some non-configurable response headers. These are listed below.

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. For more information, see SameSite Cookies Explained.

Using Custom Domains

To avoid security issues when you want to embed the app in an iframe, use custom domains. This way, you can 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.

Applying a Different SameSite Setting

From Studio Pro 8.12, you can control the value of SameSite in your cookies. The default for all cookies depends on the version of Mendix you are using:

• For Studio Pro 8 (8.12 and above), the default is SameSite=None, which means that they can be used in an iframe
• For Studio Pro 9.0 and above, the default is SameSite=Strict, which means that they cannot be used in an iframe

You can change this value in the com.mendix.core.SameSiteCookies custom runtime setting if you want to change iframe restrictions for your app.

For Mendix 8.11 and below, there was no SameSite value set on cookies, and the behavior depended 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 the Custom Environment Variables section; this sets SameSite=None; Secure; for all your cookies.

Using Custom Sign-In Pages

If you use a custom sign-in page, the originURI cookie is normally set in the index.html file. If your Mendix app runs within an iframe, set this cookie with the SameSite=None and Secure attributes.

To do this, find all the places in your theme folder where this cookie is set. It looks like document.cookie = "originURI=/login.html". Change this to add the required attributes. Here is an example:

document.cookie = "originURI=/login.html" + (window.location.protocol === "https:" ? ";SameSite=None;Secure" : "")

Content Security Policy

A Content Security Policy (CSP) informs the client (browser) where your page loads 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.

The process for setting a full content security policy depends on what your app does. However, a starting point that declares the content security policy that 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 that appear to be related to a content security policy, you can use the console of your browser to investigate them.

Outgoing Connections Safelisting (Mendix Cloud Dedicated)

If you are deploying your apps to Mendix Cloud Dedicated, all outgoing IP addresses are allowed by default.

If you clear the Allow all outgoing connections checkbox, you can define which IP addresses and ports can be used for outgoing connections.

You can add or edit multiple different IP address and port combinations. Any ranges that have already been set up are listed here. You can do the following:

• To remove any restrictions, select Allow all outgoing connections. To impose restrictions, clear Allow all outgoing connections.
• To add a new range, click New.
• To edit a range, select an existing range and click Edit.
• To delete a range, select an existing range, click Delete, and then confirm that you want to delete it.

Managing a Safelist Range

For each range where you define safelisted IP addresses and ports, you can enter the following information:

• Name – Enter a name to identify this range (for example, 192 Group).
• IP – Specify an inclusive range of safelisted IP addresses in IPv4 format (for example, 142.251.39.1 to 142.251.39.255). 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 are safelisted, including the start and end addresses. If you want to safelist a single address, make the start and end addresses the same.
• Port – Specify an inclusive range of ports that are safelisted for the IP range above (for example, 80 to 5000). You can use several safelist entries if you want to safelist different port ranges for the same IP range.
• Protocol – Select whether the safelisting is for TCP, UDP, or ALL traffic.
• Description – Enter an optional description of this IP range (for example, which API it supports).

Click Save to apply your range. The new values take effect within a few minutes without needing an app restart.

Valid IP Ranges

IP addresses must be within the following ranges:

Path-Based Access Restrictions

You can restrict access to your application using Client Certificates or IP ranges.

The root path (/) restricts access to the entire application. If a specific path has it own settings, those will override the profile inherited from other non-root paths.

Custom access restriction profiles are managed at the application level and can be reused across 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.

Outgoing Connections Certificates

Add client certificates (in the PKCS12 format) or certificate authorities (in the PEM format). These are used when your application initiates SSL/TLS connections.

The Log Levels Tab

Log levels are used to distinguish log messages. Log levels highlight the highest-priority log messages so that they can be prioritized accordingly.

Custom log nodes appear in the list only after a message has been logged to them. For more information, see Log Message.

On this tab, you can perform the following actions:

• Change the log level by selecting the new value from a drop-down list.
• Click Set all to INFO to revert all the changes.

When using the Log Levels tab, bear in mind the following considerations:

• If your app is not running, the tab only shows log nodes that are set to a level other than Info. Log nodes that are set to the Info level become visible when your app is restarted.
  • For custom nodes, log nodes become visible when your app is restarted and after messages have been logged to them.
• If you change the log level, this level will continue to be used even if you later restart your app.
• If you change the log level, the startup logs (the logs that are created while starting the runtime, including the logs that the after-startup microflow generates) are not affected. It is not possible to change the log level of the startup logs for apps hosted on Mendix Cloud.
• For an application running a single instance, changes are applied immediately to the application.
• For an application running more than one instance, the changes can only be applied after a restart of the app. This is because it is not possible to instruct the load balancer to set the log level for a specific running instance.
• Log levels may not persist across restarts if you change them outside the Mendix Portal (for example, using an app module).

The log level types are as follows:

For more information about log levels, see How to Set Log Levels.

The Runtime Tab

On the Runtime tab, you can add Custom Runtime Settings and Custom Environment Variables.

Custom Runtime Settings

Use the Custom Runtime Settings section to perform the following actions:

• Add a new runtime setting
• Edit the runtime setting
• Delete the runtime setting

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

Mendix Cloud uses runtime settings to configure the included systems for logs, backups, and database. Therefore, the following settings are not configurable by users:

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

Custom Environment Variables

Use the Custom Environment Variables section to add, edit, or delete an environment variable.

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

Click Add and select Supported to choose from the following variables:

• APPMETRICS_TARGET – This enables sending application runtime and custom business metrics to HTTP endpoints of different monitoring solutions, such as InfluxDB, while ignoring micrometer endpoints.

• DD_API_KEY – This is the API key used with Datadog.

• DD_SITE – This directs metrics to a specific Datadog region.

• DATABASE_CONNECTION_PARAMS – These are additional JDBC parameters for PostgreSQL databases. For more information, see the Mendix Cloud Foundry Buildpack.

• JVM_GARBAGE_COLLECTOR – This overrides the automatic configuration of the Java garbage collector. Accepted values are Serial or G1.

• METRICS_AGENT_CONFIG – This passes a configuration JSON to control the metrics passed to Datadog.

• SAMESITE_COOKIE_PRE_MX812 – This sets 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 (deprecated) – If your app uses specializations of the System.User entity to store users, use this variable to point to them. This enables Mendix 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 that 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.

  To ensure accurate user metering, it is important to distinguish external users from internal users. The recommended approach is to implement logic in your app to classify users (see Populate User Types and the User Classification module). A previous method relied on using email domains via the USAGE_METRICS_EMAIL_FIELDS constant, as described above. However, this method has now been deprecated.

Unsupported environment variables can only be used to control Mendix beta features. To configure an unsupported variable, click Add and select Unsupported. If you are using a beta feature, you will be informed what Name and Value to enter.

The Maintenance Tab

Use the Maintenance tab to view information about planned maintenance and configure your preferred maintenance window.

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 affects your app in some ways), about which you will automatically receive an email

Preferred Maintenance Window

You can view and change the preferred maintenance. For more information about maintenance, see Maintenance Windows: Configuration.

Planned Maintenance

When a maintenance operation is planned, it appears under Planned Maintenance. Each task card will show the purpose of the maintenance, when it is scheduled, and its status.

The status of a maintenance task can be one of:

• Succeeded – the maintenance task was successful
  • No further action is required
• Failed – the maintenance task was unsuccessful
  • The environment requires intervention and our engineering team has been notified, they will recover the environment according to its SLA. If you are still experiencing issues, please create a support ticket with Mendix Support
• Incomplete – the maintenance task was unsuccessful
  • No changes were applied, you can operate the environment as usual
  • Our engineering team has been alerted and will take the appropriate action, which may include rescheduling the task
• Ineligible – the task is not applicable to the environment
  • No changes were applied, you can operate the environment as usual
  • This can happen, for example, if the database of your environment was scheduled to be upgraded but it is already on the target version
• Canceled – the task was canceled
  • No changes were applied, you can operate the environment as usual
  • This can happen if circumstances required us to remove the planned task, a new copy of the task will be scheduled at a later point in time

The Tags Tab

You can set tags on your environment. Tags are arbitrary strings that are not interpreted by the Mendix 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. For more information, see Datadog's Getting Started with Tags.

If you want to add, edit, or delete a tag, make the change on the Tags tab and then restart your environment to update the tags.

The Services Tab

In the Services tab, the Technical Contact decides the custom services for each environment. The Technical Contact must first enable a service for the app, after which you can then activate or deactivate these services for individual environments as needed. For more information, see Services.

Available Services

One custom service is available: Mendix Event Broker. This service is required to use Mendix Business Events on production apps.

Enabling Custom Services

Custom services are only available if the app's Technical Contact has enabled them. The custom services are enabled or disabled separately for each environment of each app. For more information, see Services in the Environments documentation.