Support Policy for Mendix on Azure

Last modified: February 25, 2025

Introduction

This document describes the technical support policies and limitations for Mendix on Azure, based on the shared responsibility model underlying the offering.

Shared Responsibility Model

Under the shared responsibility model for Mendix on Azure deployments, Mendix, Microsoft, and customer organizations all have their own responsibilities in the deployment process and business-as-usual operations. Familiarize yourself with the responsibilities listed below:

Microsoft Responsibilities

Microsoft is responsible for operating and securing the Azure services underlying the Mendix on Azure service. This includes the following services:

  • Compute
    • Azure Kubernetes service
  • Storage
    • Azure Blob Storage
    • Azure Container Registry
  • Database
    • PostgreSQL Flexible Server
  • Networking
    • Virtual networks
    • Load balancer
    • Private endpoints
  • Monitoring
    • Managed Grafana and Prometheus

Mendix Responsibilities

Mendix is responsible for orchestrating, operating, maintaining, securing, and supporting the Mendix on Azure service. This includes the following tasks:

  • Orchestrating - Ensure that the underlying Azure services function together as one cohesive offering.
  • Operating - Resolve regressions in how the underlying Azure services come together as one service.
  • Maintaining - Ensure that the service absorbs changes in the underlying Azure services without impact on customers.
  • Securing - Ensure that the service remains compliant with relevant security best practices and frameworks.
  • Supporting - Reactively address customer issues with using the service.

Customer Responsibilities

Customers are responsible for developing, deploying, operating, integrating, and securing apps on top of the Mendix on Azure service. This includes the following tasks:

  • Developing - Create apps that deliver business outcomes.
  • Deploying - Deploy apps.
  • Operating - Monitor app behavior and address deviations.
  • Integrating - Securely integrate apps with backend services and IAM.
  • Securing - Comply with Mendix best practices for secure apps.

Available Customizations

When a Mendix on Azure cluster is initialized, all components that are required to host Mendix apps are automatically deployed inside an Azure Resource group of your choosing. Mendix and Microsoft regularly push all required updates to your cluster to ensure that it remains compliant and secure.

Because the updates are automated for all Mendix on Azure customers, you cannot modify any of these components directly in Azure. You also cannot influence the upgrade process. Because of that, you can only implement customizations that are offered in the Mendix on Azure and Private Cloud portals. Currently this includes the following customizations:

  • Adding custom tags to Azure resources
  • Changing the Azure Kubernetes Service tier
  • Changing the Azure Kubernetes agent node VM type
  • Overriding the maximum AKS agent node pool (upper autoscaling limit)
  • Changing the Azure for PostgreSQL Flexible server computing SKU and storage performance tier
  • Switching to internal load balancer exposure to enable apps that can only be reached privately
  • Changing IP address prefix of the subnet hosting AKS nodes (only at initial deployment)

Any customization beyond what is offered as self-service through the Mendix on Azure and Mendix Private Cloud portal is not possible.

Raising Support Tickets

Since your Mendix on Azure resources contain private and sensitive data, Mendix Support cannot access your resources. To be able to troubleshoot incidents on your behalf, the Mendix on Azure portal allows you to raise a support ticket that includes recent logs for your environment, as well as provide consent to Mendix personnel for accessing your resources temporarily while processing your support ticket.

Service Updates and Releases

All components in Mendix on Azure are managed and are upgraded to newly available versions on a quarterly basis by Mendix and Microsoft. Mendix conducts pro-active regression testing to ensure the updated set of components keep working well together.

All node-level OS components in Mendix on Azure receive weekly security patches (as per Microsoft’s NodeImage auto-upgrade Node OS upgrade channel). In case critical security patches are found in the Mendix components running in your cluster (i.e. Operator and Agent) these will be patched as soon as possible (but at the end of the quarter latest).

These quarterly and weekly upgrade cadences are fully automatic and cannot be influenced by the customer.

Mendix Support Coverage

Mendix provides technical support for the following example scenarios:

  • Cluster initialization fails despite passing pre-flight validation checks.
  • The customer is impacted by issues with service availability and is unable to recover the situation using the self-service recovery option.

Mendix does not provide technical support in the following example scenarios:

  • Requests about how to integrate with other Azure Services that are beyond the scope of the product. Such requests can be supported by Mendix Expert Services or Mendix (infra) partners as part of (paid) consultancy engagements.
  • Requests to make configuration changes to underlying Azure services beyond what is offered as self-service in the Mendix on Azure and Mendix Private Cloud Portal. Since such changes are not possible with this service, customer may consider to adopt Mendix for Private Cloud instead.
  • Requests for any other type of customization on the resources deployed in customer’s Azure subscription. Since such customization is not possible with this service, customer may consider to adopt Mendix for Private Cloud instead.
  • Requests to fix security vulnerabilities in one of the managed components beyond what is automatically pushed during the weekly and quarterly update cycles.

Customer Responsibilities for Mendix on Azure Resources

The customer is responsible for optionally integrating the solution with the rest of their internal network (for example, to access backend services) by correctly configuring VNet Peerings, routing tables and DNS name resolution as per documentation.

The customer is responsible for reporting service availability issues to Mendix in the case these cannot be resolved using self-service options.

If the customer chooses to deploy the solution into a network that limits egress, it is the customer’s responsibility that appropriate egress exceptions are made for the underlying Azure services (particularly AKS).

Issues and Bugs in Underlying Azure Services

Because Mendix on Azure relies on several rapidly evolving underlying Azure services (especially AKS), bugs and issues may arise in those services. Some of these limitations and bugs cannot be worked around within Mendix on Azure itself, but must be fixed in the underlying Azure services.

Mendix strives to minimize the impact of such bugs and issues for our customers in the following ways:

  • By conducting quarterly testing to detect regressions early and work around them to the degree that we can.
  • By working with Microsoft Support and engineering teams in case a bug or issue needs to be resolved upstream.
  • By communicating to our customers why an upstream bug or issue affects their Mendix on Azure cluster, and providing workarounds where possible.

Compliance Frameworks

The solution is being benchmarked against SOC2 Azure Policy Compliance controls.

Known Limitations

  • Mendix on Azure only supports hosting apps on Mendix versions 10.10 or later. Any app on an earlier version will fail to deploy successfully.
  • Due to the managed nature of this product, not all Private Cloud APIs are available to the customer. Refer to the Build and Deploy API documentation to find out which API calls are out of scope for Mendix on Azure.