Bitnami Node.js for Microsoft Azure Multi-Tier Solutions

What are the differences between a Bitnami Single-Tier Solution and Multi-Tier Solution?

Single-tier architecture implies that all the required components of an application run on a single server. If your environment is growing and becoming more complex, a single layer architecture will not meet your scalability requirements. Single-Tier Solutions are great for departmental applications, smaller production environments, new users, or those applications that don't support multi-tier architectures.

The typical architecture of a Bitnami Single-Tier Solution looks like this:

Single-tier architecture

Multi-tier architecture involves more than one server and infrastructure resource. For example, the Front End-Database topology separates the application server from the database server. This allows you to extend workloads in the cloud and tailor your application to meet specific scalability and reliability goals. Multi-Tier Solutions provide more sophisticated deployment topologies for improved scalability and reliability for larger production or mission critical environments.

TIP: Not sure if you have chosen the right solution? Check out the Bitnami Multi-Tier solutions features and benefits to learn more about the benefits of Multi-Tier.

This Bitnami Multi-Tier Solution provisions multiple nodes as a NodeJS high availability cluster with a pre-configured load balancer, shared file-system and an external database support (MongoDB). This topology is illustrated below:

Multi-Tier architecture

IMPORTANT: By default, the MongoDB database server is not included in the ARM template. We highly encourage you to use the Azure Cosmos DB service, which provides a gobally distributed, low latency database. However, you can always use a custom MongoDB database deployed for your application.


Node.js is a runtime environment built on V8 JavaScript engine. Its event-driven, non-blocking I/O model enables the development of fast, scalable, and data-intensive server applications.

First steps with the Bitnami Node.js Stack

Welcome to your new Bitnami application running on Microsoft Azure! Here are a few questions (and answers!) you might need when first starting with your application.

What credentials do I need?

You need a set of credentials:

  • The server credentials, consisting of an SSH username and key/password. These credentials allow you to log in to your Microsoft Azure Multi-Tier Solutions server using an SSH client and execute commands on the server using the command line.

What SSH username should I use for secure shell access to my application?

SSH username: bitnami

How do I get my SSH key or password?

You would have created and uploaded an SSH key pair at the time of deploying the server(s). Use the same key pair for secure shell access to the server. Click here for more information.

How to start or stop the services?

IMPORTANT: If the case you are deploying your custom application on top of this solution, do not forget to check these requirements and the best practices you should follow when developing the control script for your application.
NOTE: The steps below require you to execute the commands on the remote server. Please check our FAQ for instructions on how to connect to your server through SSH.

Each Bitnami server includes a control script that lets you easily stop, start and restart all the services installed on the current individual server.

Obtain the status of a service with the service bitnami status command:

$ sudo service bitnami status

Use the service bitnami command to start, stop or restart all the services in a similar manner:

  • Start all the services.

    $ sudo service bitnami start
  • Stop all the services.

    $ sudo service bitnami stop
  • Restart all the services.

    $ sudo service bitnami restart
TIP: To start, restart or stop individually each server of the cluster, check the FAQ section about how to start or stop servers in a Multi-Tier Solution.

How to create a Virtual Network peering?

To connect two instances internally you can enable a Virtual Network (VNet) peering from the Azure Portal. Depending if the instances were launched in the same or in different resource groups, there are two methods for performing a internal connection: sharing a virtual network or enabling a virtual network peering.

How to add nodes to the cluster?

IMPORTANT: These steps assume that you have already installed the Microsoft Azure command-line client (Microsoft Azure CLI) on your system and you are signed in to Microsoft Azure through it. If this is not the case, please refer to the FAQ for instructions on how to install and sign in to Microsoft Azure using the Azure CLI.
NOTE: To follow the steps below, you will need the subscription ID, deployment ID and resource group ID for the deployment to which you wish to add nodes. Find out how to obtain the subscription ID and the deployment and resource group IDs.

To add nodes to the cluster, follow these steps:

  • Set the subscription ID for your deployment in the Azure CLI with the command below. Replace the SUBSCRIPTION-ID placeholder with the correct value.

      $ az account set --subscription SUBSCRIPTION-ID
  • Download the deployment template associated with your deployment using the command below. Replace the DEPLOYMENT-ID and RESOURCE-GROUP-ID placeholders with the correct values.

      $ az group deployment export --name DEPLOYMENT-ID --resource-group RESOURCE-GROUP-ID > template.json
  • Download the parameters file associated with your deployment using the command below. Replace the DEPLOYMENT-ID and RESOURCE-GROUP-ID placeholders with the correct values.

      $ az group deployment show --name DEPLOYMENT_ID --resource-group RESOURCE_GROUP_ID --query "properties.parameters" | sed '/"type":/d' > parameters.json
  • Redeploy the solution with the additional node(s) using the command below. Replace the DEPLOYMENT-ID and RESOURCE-GROUP-ID placeholders with the correct values, the ADMIN-PASSWORD and DATABASE-PASSWORD placeholders with the same administration password and external database password used when initially deploying the application, and the NUMBER-OF-NODES placeholder with the final number of nodes you wish to have in the cluster.

      $ az group deployment create --name DEPLOYMENT-ID --resource-group RESOURCE-GROUP-ID --template-file template.json --parameters @parameters.json --parameters adminPassword=ADMIN-PASSWORD databasePassword=DATABASE-PASSWORD '{"nodeCount": {"value": NUMBER-OF-NODES}}'

Verify that the new node(s) have been added successfully by logging in to the Azure portal and selecting the resource group and deployment to check the number of running nodes.

What is the default configuration?

By default the Bitnami Sample Mean application is deployed in the cluster. However, you can use your custom Git repository and deploy your application by setting the URL in the Azure interface at the deploy time. Authentication is also supported if you set the username/password in the URL.

For the Bitnami Sample Mean, this is the default configuration:


The Application Gateway redirects traffic from 80 port to backends in 3000 port.


The directories used to configure the application are (remember that APP_FOLDER and DATA_FOLDER are placeholders, replace them with the directories of your custom application):

  • APP_FOLDER: Contains all the code of the application. Defaults to /app.
  • DATA_FOLDER: Contains all the assets that will be mounted in the file system server. Defaults to /bitnami/app.

Init scripts

The script is intended to be run in every start of the application. You can check the logic of the script here.


As the application is started with pm2, you can retrieve the server logs by running:

    $ sudo PM2_HOME=/etc/.pm2 pm2 logs

For more information related to the application, please, check the official README.

How is the cluster configured?

The Bitnami Multi-Tier Solution for Node.js High-Availability Cluster uses multiple VMs, consisting of:

Node.js nodes

They are configured with the Node.js runtime to serve the application.

Load Balancer

The Azure's Application Gateway is configured to balance the workload between all the nodes.

File system service

The Azure's File Share Service is configured to mount a file system in all the nodes, having a common folder where you can store all the assets of your application.

MongoDB database

By default, there is not configured a MongoDB database for the application. We highly encourage you to use the Azure Cosmos DB service to provide a database for your application, but you can use your custom MongoDB database.P

Public endpoints

By default there are configured two public endpoints:

  • Application Gateway: Load balancer in charge of distributing the HTTP/HTTPS workload across all the Node.js nodes.
  • Node.js node: One of the deployed nodes has a public IP address where users can access by SSH.

How to create an SSL certificate?

NOTE: The steps below assume that you are using a custom domain name and that you have already configured the custom domain name to point to the Application Gateway of the deployment.

This section will guide you through the process to create the SSL certificate and encode it in the correct format to use the Azure's Application Gateway. To do so, follow the instructions below:

  • Generate your private key:

    NOTE: Make sure you keep your private key in a safe place, as it will be used to generate the certificates to provite HTTPS support for your application.
    $ openssl genrsa -out private-key.key 4096
  • Generate the certificate request:

    $ openssl req -new -key private-key.key -out certificate-request.csr

    Once you have executed the command above, you will be prompted to enter some information related to the certificate. Make sure that your custom domain URL is specified in the Common Name step.

    IMPORTANT: This guide shows you the process of self-signing the certificate and uploading it to the Azure's Application Gateway. You can also request a Certification Authority to sign your certificate sending the server.csr file you have just generated.
  • Self-sign the certificate request:

    $ openssl x509 -req -days 365 -in certificate-request.csr -signkey private-key.key -out signed-certificate.crt
  • Encode the certificate in PKCS #12 format:

    The Application Gateway requires a certificate encoded in PKCS #12 format with the pfx extension. To convert your certificate to this format, execute the following:

    $ openssl pkcs12 -export -out certificate.pfx -inkey private-key.key -in signed-certificate.crt
    IMPORTANT: Create a strong password for the exported certificate. You will use it later during the import process in the Azure Portal.

Now, you can use the certificate.pfx file in the Application Gateway to configure HTTPS for your application.

How to enable HTTPS support with an SSL certificate?

NOTE: The steps below assume that you have a signed certificate in the PKCS #12 encoding format with the pfx extension. If not, check how to create an SSL certificate.

By default, the Bitnami Multi-Tier Solution for Node.js High-Availability Cluster comes with the HTTPS support disabled. This section will guide you through the process to upload the generated certificate and enable the HTTPS redirection in the Azure's Application Gateway.

  • Access the Resource Group of your deployment in the Azure Portal and select the Application Gateway:

Azure Resource Group

  • On the resulting screen, select the Listeners option and then, click "Basic" create a basic listener:

Azure Listeners

  • Configure the HTTPS Protocol with your certificate and the same password you have used before to export your certificate:

Azure Listeners configuration

  • Once the listener has been created, navigate to the Rules section and create a basic Rule:

Azure Rules

  • Link the new rule to the listener you just create:

Azure Rules configuration

Now you can use your custom domain with HTTPS support.