On-Premises

Last modified: August 19, 2024

Introduction

When designing your server architecture, there are an infinite number of possibilities for how you can set up your environment. There is no right or wrong configuration, because it all depends on your security, availability, and performance requirements.

The options below are just a few examples of the most commonly used architecture setups. Mendix Cloud uses a (more complex) architecture based on hosting with a separate database server (for details, see Hosting with a Separate Database Server (Option 2)) without a separate file server and with a proxy server to redirect traffic to the correct environment.

This how-to teaches you how to do the following:

Select the best architecture option

Options

Minimal Server Architecture (Option 1)

This is the simplest solution with the fewest configuration and connection problems. This configuration is used in Mendix Cloud as well, except the cloud is Linux-based, with NGINX used instead of IIS and PostgreSQL used as the database server.

Hosting with a Separate Database Server (Option 2)

Separate Database Server and a Separate Web Server (Option 3)

This option is the most difficult to maintain, and every update has to be performed twice (once on your application server as normal, and after as an update in which you have to replicate all the static content to the web server as well). This means that you have to copy the contents of the web folder (including MxClientSystem) to the web server every time you do an update.

You should avoid using this option if possible.

Separate Mendix Web Server in a DMZ (Option 4)

Load Balancing Support and Configuration

The platform can handle a load balancer in front of the platform. When a problem occurs on a single instance, the only thing an active user can lose is the data being working on. Everything that is only available in the memory of the failed instance will be gone, and all of the stored data will still be available for the user.

When updating the application, it is best to stop every instance. If the database structure has changed and a single instance updates the database structure, it can cause some strange behavior on all the running instances, since they are still expecting the old database structure.