Serverless computing has matured into a mainstream deployment model. Many MuleSoft customers are successfully running APIs and microservices in containers while leveraging serverless computing. They utilize Anypoint Flex Gateway to manage and secure these services. Flex Gateway is a high-performance gateway that extends the Anypoint Platform to all APIs and AI services across various environments.
MuleSoft fully supports customers who deploy Flex Gateway in containerized and serverless computing environments. But the success of such deployments is a shared responsibility. MuleSoft is responsible for providing and supporting Flex Gateway and offering an online Docker image registry. Customers are responsible for provisioning and configuring the containerized and serverless computing environment to run Flex Gateway effectively.
Traditionally, customers interested in deploying Flex Gateway in these environments have mainly focused on using Amazon Elastic Container Service (Amazon ECS) with AWS Fargate. However, Azure Container Apps is also gaining popularity in this space.
Before proceeding, it’s essential to understand the following terminology used in the context of this article:
- A Flex Gateway instance is a logical entity that groups one or more Flex Gateway replicas.
- A Flex Gateway replica is a runtime unit or a copy of Flex Gateway running on a supported operating system or infrastructure (e.g. Docker, Azure Container Apps, Kubernetes).
Running Flex Gateway on Azure Container Apps
The foundational Azure resources required to run Flex Gateway on Azure Container Apps are minimal.
Azure Container Apps requires a resource group. The resource group holds all resources related to deploying and running Flex Gateway in Azure. A resource group is tied to a specific Azure region. However, you can add resources from any region to a resource group.
Azure Container Apps also requires a Container Apps environment. A Container Apps environment represents a secure boundary that isolates a container app (e.g. Flex Gateway) and its associated infrastructure. A Container Apps environment is tied to a specific Azure region. Azure automatically creates a virtual network with limited network capabilities when you add a Container Apps environment.
You can enable zone redundancy, i.e. take advantage of availability zones when creating the Container Apps environments. For fine-grained control, you also have the option to specify a virtual network you preconfigured when creating a Container Apps environment to address any security and non-functional requirements you might have.
You can associate multiple Container Apps environments within the same virtual network. However, you can’t change the virtual network and subnet, nor the subnet size associated with a Container Apps environment, once it has been created.
Note: As of version 2.74.0 of the Azure CLI (released May 2025), new Azure Container Apps environments enable workload profiles by default. A workload profiles environment means you can run a mix of serverless (consumption) and dedicated (workload profile) workloads within the same environment.
If you want a fully serverless setup, you can turn this off by setting the `–enable-workload-profiles` parameter to false when creating the Azure Container Apps environment. Previously, the default environment type was consumption-only. Some Azure documentation and examples may not yet reflect this change.
Azure also creates a Log Analytics workspace automatically when you add a Container Apps environment. In the context of Azure Container Apps, a Log Analytics workspace collects all logs from the container apps you run within the associated Container Apps environment. It provides functionality for managing and querying the container apps logs. The Log Analytics workspace is tied to the Azure region where you add the Container Apps environment. You have the option to use a Log Analytics workspace you preconfigured before adding a Container Apps environment.
Azure provides flexibility for provisioning and structuring the foundational Azure resources required to run Flex Gateway on Azure Container Apps. You run a Flex Gateway instance within a Container Apps environment. There’s no definitive rule or recommended practice regarding the number of Flex Gateway instances to run within the same Container Apps environment. You can create as many or as few Container Apps environments as you need to separate Flex Gateway instances logically.
For instance, you could plan a Container Apps environment per software development environment (e.g. development, test, production) or one for non-production environments and one for production. Naturally, the more Container Apps environments you create, the more you must operate, administer, and manage. However, you can create all the required resources and run a Flex Gateway instance on Azure Container Apps with as few as three or four Azure CLI commands – assuming you use a default virtual network and Log Analytics workspace.
A few additional resources and concepts are involved in running Flex Gateway on Azure Container Apps. The following diagram provides a conceptual overview of the components required to run a Flex Gateway instance with ingress enabled, routing incoming requests across Flex Gateway replicas.
After provisioning the foundational Azure resources, you start Flex Gateway replicas by simply creating a container app using the following Azure CLI command:
az containerapp create \
--name sm-flex-aca-demo-dev-01 \
--resource-group ACA-Flex-Resource-Group \
--environment ACA-Flex-Environment \
--image docker.io/mulesoft/flex-gateway:1.9.4 \
--ingress external \
--target-port 8081The command above is an incomplete example provided for illustrative purposes only. Although incomplete, this command still includes implicit and explicit settings and configuration. The command explicitly instructs Azure Container Apps to run the Flex Gateway Docker image (version 1.9.4) published by MuleSoft on Docker Hub, providing additional details on how to run it. It enables ingress and configures it to accept traffic from the internet and the container app’s internal environment, routing incoming requests to Flex Gateway via port 8081.
Default values are used for implicit settings and configuration. For example, Azure Container Apps starts a single Flex Gateway replica with 0.5 CPU, 1 Gi of memory, and 2 Gi of ephemeral storage allocated. As another example, Azure Container Apps could scale out to run ten Flex Gateway replicas concurrently and scale in to run none.
Behind the scenes, Azure Container Apps introduces a few additional moving parts when you create a container app, as implied in the Conceptual Overview diagram above. First, it adds a container app revision to capture the specific settings and configuration you specify when creating the container app. However, revisions are immutable. That is, any update to the container app settings and configuration, even the most minor, is captured in a new container app revision.
You can run a single revision at any point in time or multiple revisions concurrently. When running several revisions concurrently, you can distribute requests across revisions and choose when to terminate older revisions.
The container app revision, among other things, captures scaling rules — e.g. the number of container app replicas to run concurrently, when to scale out, and when to scale in. Based on the scaling rules, Azure Container Apps adds or starts container app replicas, which are essentially Flex Gateway replicas.
Challenges to address before provisioning and configuring Azure resources
Before you start provisioning and configuring Azure resources, it’s essential to be aware of two minor challenges that you must plan to address:
- Making the Flex Gateway registration and configuration files available to the Azure container app
- Azure Container Apps health probes
1. Flex Gateway registration and configuration files
The first challenge is to make the Flex Gateway registration file and any additional configuration files available to the Flex Gateway container app. The recommended configuration file when deploying and running Flex Gateway on Azure Container Apps for the first time sets the Flex Gateway runtime log level to debug for more verbose runtime logs.
Let’s look at the following YAML configuration file:
apiVersion: gateway.mulesoft.com/v1alpha1
kind: Configuration
metadata:
name: logging-config
spec:
logging:
runtimeLogs:
logLevel: debugThe second optional but recommended configuration file exposes the Flex Gateway readiness API, which is one approach for addressing the second challenge, the Azure Container Apps health probes.
Let’s look at the next YAML configuration file:
apiVersion: gateway.mulesoft.com/v1alpha1
kind: Configuration
metadata:
name: probe
spec:
probe:
enabled: true
port: 3000The most straightforward approach to address the first challenge is to use the FLEX_CONFIG environment variable to inject the Flex Gateway registration and the additional configuration files. However, the FLEX_CONFIG environment variable, like any other environment variable, is a name-value pair.
The value of the FLEX_CONFIG environment variable is a string, but Flex Gateway expects the registration and configuration information provided in YAML format. Naturally, you can only specify the FLEX_CONFIG environment variable once. Fortunately, Azure Container Apps fully supports setting runtime environment variables.
To leverage the FLEX_CONFIG environment variable to inject the registration and additional configuration files, you must first merge them into a larger YAML file simply by separating their content with a line with three dashes (i.e. —).
Here is a complete example of a Flex Gateway registration file merged with the debug logs configuration file and the readiness API configuration file.
Next, you need to convert the larger YAML file to a string and escape all the special characters it contains, resulting in a very long string of characters. Here’s an example of a FLEX_CONFIG string value with all special characters escaped.
Be aware that the Azure CLI commands ‘az containerapp create’ and ‘az containerapp up’ accept the optional ‘–env-vars’ parameter for specifying a list of environment variables for the container app. However, it appears that the Azure CLI, as well as the Azure Portal, manipulates or transforms the value of the FLEX_CONFIG environment variable in a way that prevents Flex Gateway from successfully parsing its YAML configuration.
A solution to solve this issue is to leverage the Azure CLI command ‘az containerapp create’ with a YAML file that defines the required configuration to create or run a container app for Flex Gateway.
Here’s an example:
az containerapp create \
--name sm-flex-aca-demo-dev-01 \
--resource-group ACA-Flex-Resource-Group \
--yaml sm-flex-aca-demo-dev-01-create.yamlThe Flex Gateway registration file contains sensitive data, most notably the `agentId`, a certificate, and its private key, which are required to run a Flex Gateway instance. Because of this, some customers choose to store their registration file as a secret in Azure Key Vault and reference it directly in environment variables using managed identity authentication when deploying Flex Gateway to Azure Container Apps.
This approach typically applies only to the registration file and does not automatically handle additional configuration files (e.g. runtime debug logs, readiness probe). You can still use the FLEX_CONFIG environment variable to provide those separately. Alternatively, you can merge additional configuration data into the Flex Gateway registration file and store the resulting larger YAML file as a secret in Azure Key Vault.
Another solution is to extend the base Flex Gateway image to include the Flex Gateway registration and additional configuration files. In other words, you build a custom Docker image per Flex Gateway registration file. Azure offers services to automate the build process, or you could leverage your existing DevOps toolchain and configure CI/CD pipelines. You must also store and maintain custom Docker images in a registry, such as Azure Container Registry or Docker Hub.
Mounting a file share from Azure Files as a volume to the Flex Gateway container app is yet another solution. However, this approach requires provisioning additional Azure resources, which arguably adds complexity and additional moving parts that represent possible points of failure.
All four approaches have benefits and tradeoffs. Regardless, it would be best to plan for your chosen solution before provisioning and configuring Azure resources for deploying and running Flex Gateway on Azure Container Apps.
2. Azure Container Apps health probes
The startup, liveness, and readiness probes required by the ingress in Azure Container Apps introduce the second challenge. There are two approaches to solving this requirement. The first approach consists of exposing and leveraging the Flex Gateway readiness API.
Be aware that the Flex Gateway readiness API requires registering at least one API with Flex Gateway before it returns a readiness state of true. The second approach involves registering an API with Flex Gateway and utilizing it for the ingress startup, liveness, and readiness probes. Ideally, you should leverage an API you will ultimately manage with Flex Gateway.
Both approaches are very similar since the Flex Gateway readiness API requires registering at least one API. Leveraging an API that you already manage with Flex Gateway is straightforward, as in most cases, you should be able to utilize the default configuration for the ingress startup, liveness, and readiness probes. This approach creates a dependency on the actual API, whereas the Flex Gateway readiness API is independent of any APIs managed by Flex Gateway.
Regardless of the approach you select, it almost feels like a chicken and egg situation. To run Flex Gateway successfully, specific infrastructure must be in place. However, you need a running Flex Gateway replica to enable the ingress startup, liveness, and readiness probes.
Here is the recommended approach:
- Run a single Flex Gateway replica without enabling ingress or configuring an Azure Load Balancer
- Register the required API with Flex Gateway
- Enable ingress (or add your Azure Load Balancer)
Plan for your chosen solution before provisioning and configuring Azure resources for deploying and running Flex Gateway on Azure Container Apps.
Baseline architecture
Running Flex Gateway on Azure Container Apps involves provisioning and configuring Azure resources, as well as completing tasks specific to Flex Gateway. The following diagram illustrates a suggested architecture that establishes a baseline or foundation, focusing on a basic deployment with minimal configuration to ensure success.
You don’t have to provision, configure, and secure a virtual network, thereby removing potential areas that might affect the successful startup and operation of Flex Gateway. Similarly, enabling ingress simplifies the overall deployment process, as you no longer need to create an Azure Load Balancer, public IP address, or any other Azure resources to enable incoming HTTP requests or TCP traffic.
The virtual network Azure creates when you add a Container Apps environment offers limited network capabilities. Furthermore, it’s possible to secure and restrict access to the ingress. Arguably, it provides less flexibility to address more stringent non-functional requirements than using an Azure Load Balancer. Consider the baseline architecture as a great foundation from which to learn and build upon to address more complex deployments.
The baseline architecture diagram illustrates running a single Flex Gateway replica with ingress enabled. Naturally, it lacks redundancy to achieve high availability. It doesn’t represent any specific Flex Gateway Deployment Model as you can implement any on Azure Container Apps. It also shows generic APIs owned by any organization and running on any platform. However, you could implement any of the Flex Gateway integration use cases just as quickly.
You can build upon or modify the baseline architecture to meet your specific requirements. You can use multiple availability zones, more than one Flex Gateway replica per availability zone, or both to achieve higher availability. Create a virtual network associated with your Container Apps environment to have fine-grained control and address any security and non-functional requirements you may have. You can’t change the virtual network and subnet associated with a Container Apps environment after it has been created, so plan accordingly.
Next steps and additional resources
If you’re new to Azure Container Apps, complete the tutorial on deploying your first container app from the Azure documentation. If you’ve never installed or worked with Flex Gateway, review the Flex Gateway overview and Flex Gateway reference architecture in the MuleSoft product documentation. Also, review and satisfy the prerequisites before installing Flex Gateway on Azure Container Apps.
Lastly, this GitHub repository suggests an approach to provisioning and configuring Azure resources, as well as completing tasks specific to Flex Gateway, to establish the baseline architecture. The proposed approach leverages the Azure CLI; however, if you have experience provisioning and configuring Azure resources, you can complete all the steps using the Azure Portal or leverage an Infrastructure as Code (IaC) approach, such as Azure Resource Manager, Ansible, or Terraform.
