Mendix Cloud V4

Last update: Download PDF Edit

1 What Is Mendix Cloud v4?

Mendix Cloud v4 is the latest version of the Mendix Cloud: where licensed Mendix apps are deployed to a scalable, enterprise-grade cloud platform.

V4 was launched in Q1 2017. As in v3, applications are deployed via the Mendix Developer Portal or our APIs. Unlike v3, the applications run on Cloud Foundry clusters that are deployed on highly available Amazon Web Services (AWS) regions. Apps can run in the EU, US, Japan, or the UK.

2 What Is the Status of Mendix Cloud v3?

New apps will be launched on Mendix Cloud v4 by default. Customers that need to stay on v3 because they use a VPN can still get new apps on v3 for the foreseeable future. Mendix Cloud v3 will be supported for several more years; no end-of-support or end-of-life dates have been set yet.

If you want to move your app(s) from v3 to v4, you can find the instructions here: Migrate to Mendix Cloud v4.

3 Can I Upgrade All My Apps?

Your app needs to be on Mendix 6.0 or higher.

We also recommend that your apps are built as 12-factor apps.

The main change will be for apps that use long-running scheduled events. Our recommendation is to split these into smaller chunks and use a queueing system like the Amazon SQS connector to spread the work out over multiple instances.

4 Where Will My Data Be Hosted?

The primary hosting locations are as follows:

  • Mendix Cloud EU: AWS Frankfurt
  • Mendix Cloud US: AWS North Virginia
  • Mendix Cloud Asia Pacific: AWS Tokyo
  • Mendix Cloud UK: AWS London

Backups will always be stored in at least one external data center, separate from the primary hosting location.

Data will always be stored in the same political region for the following regions:

  • Data in the EU, including backups, will stay within the EU
    • Data in the EU is not currently backed up in the UK
    • Data in the UK is backed up elsewhere in the EU
  • Data in the US, including backups, will stay within the US

Data in Japan is currently backed up in Australia.

5 Does Mendix Expose the Underlying Cloud Foundry API?

No, we do not. The Cloud Foundry API does not map one-to-one to our deployment options, our authorization model, or our cloud resource usage. However, deployment to the Mendix Cloud can be automated using the Deploy API.

6 How Do I Access the Underlying AWS Resources, and How Can I Deploy in My AWS account?

Mendix Cloud v4 runs in Mendix’s own AWS account, and you can not interact with the AWS APIs directly via our credentials. We do not offer VPC peering or VPC connections. All access to Mendix-hosted AWS resources (such as EC2, RDS, and S3) is done via our APIs, such as the Database API and FileDocument API in Runtime, and the Deploy API for cloud resources.

You can, however, launch services on your own AWS account in the same region to minimize latency, and you can access those services via connectors in your app. The AWS IoT Connector from the Mendix App Store is a good example.

7 There Is No Deployment in My Desired AWS Region, When Will Mendix Launch There?

We add regions based on customer demand. If you would like a different region, contact your Mendix Customer Success Manager to see what we can offer. Note that we any request will need to take into account the costs of launching a complete Cloud Foundry cluster, with backup services, monitoring, etc.

You can also consider running your Mendix app using your own AWS account in a different AWS region. You can do this using Docker, and there is some information on how to do this here: Docker. If you do this, however, you will not receive all the benefits of running in the Mendix Cloud.

8 What Are the Limitations?

There is no mail server included in Mendix Cloud v4. You can use a third-party email provider instead. For more information, see Sending Email.

A VPN (which is already deprecated in favor of client certificates) will not be possible in Mendix Cloud v4. For alternatives, see Securing Outgoing Connections from Your Application.

9 Differences Between Mendix Cloud Versions

These are the differences between Mendix Cloud v3 and Mendix Cloud v4:

  • In Cloud v4, the debugger is always active, and the button shows the credentials to connect Mendix Studio Pro to it
  • The Java security manager is no longer in place
    • The Java security manager is used in v3 to enforce standardization and to act as an additional security layer
    • In Cloud Foundry, short-lived containers already ensure standardization, and apps are completely isolated from the management network; therefore, the Java security manager will not be enabled on the new environment
  • The number of permitted database connections is no longer static, but tied to the RAM of the database environment. The limit is roughly 100 connections per GB of database RAM. You can use the Mendix Runtime settings ConnectionPoolingMaxActive and ConnectionPoolingMaxIdle to tweak the number of database connections that the Mendix Runtime will set up. The defaults are perfectly fine for most situations. Keep in mind that the setting is applied per runtime instance, so the configured number is multiplied by the number of instances.

10 Missing in Mendix Cloud v4

There are some features missing in v4. Mendix will implement the following features in the future:

  • File storage usage is not visible
  • Application CPU alerts are not sent
  • Archived logs can only be downloaded, not viewed in the browser
  • The database status is not visible on the node details screen

11 Known Issues in Mendix Cloud v4

  • The Amazon RDS maintenance window is not aligned with the CP maintenance window for an application
  • To use the debugger, you need to scale down to one instance
  • Metrics for multi-instance nodes are not reported correctly. The information reported on the app’s Metrics and Alerts pages only represents once instance of a multi-instance node
  • It is not possible to deploy a model (.mda) larger than 4GB when uncompressed or a model that contains approximately 64,000 or more files.
  • In some circumstances your app can run out of file connections. This is indicated by the following entry in the logfile: com.amazonaws.http.AmazonHttpClient executeHelper Unable to execute HTTP request: Timeout waiting for connection from pool. To resolve this:
    • Update all App Store modules to the latest version – older versions may not close file connections correctly
    • If using Mendix 6, upgrade to version 6.10.16 or above; for Mendix 7, upgrade to version 7.16 or above
    • Increase the number of available file connections (default is 50) by adding the setting on the Environments > Runtime > Custom Runtime Settings in the Developer Portal – see Customization – Amazon S3 Storage Service Settings for more information
  • The platform automatically restarts application instances due to routine platform updates, which can be up to several times a week. If you review logs for an app that is functioning normally and you see recent messages about a series of instance restarts for no apparent reason, platform updates are probably the reason. This is normal and ok!

    In the majority of cases, the platform will start a new instance of your application, before gracefully stopping the old one. This ensures that there is no downtime. You can verify this in the logs of your application.

    If you want a second layer of assurance that you will not have downtime in this situation, we advise you to use Mendix 7+ and to scale your application to multiple instances.

12 Read More