Apache and Nginx Multi Tenant to Support SaaS Applications

In Cloud Computing, Multi tenancy, –in this case, Apache Multi Tenant and Nginx Multi Tenant–, is a mode of operation of software where multiple independent instances of one or various applications operate in a shared environment.

The software instances are logically isolated but physically integrated. Even if the software instances use the same underlying resources, cloud customers are unaware of each other, and their data is kept separate and secure. 

Multi tenancy is a vital component of cloud computing. Cloud services would be far less practical without this concept. A multi tenant application can help reduce development and deployment costs to companies that develop applications. This is similar to multiple owners/tenants living in the same building. Even though they live in the same building, they have their bedroom, kitchen, hall, electricity-meter, water taps, etc. 

In this blog you will review everything you need to know about Nginx multi tenant and Apache for you SaaS apps.

Table of contents

• Why use multi tenancy in your Nginx and Apache configuration?
• Prerequisite: Setup your DNS subdomains with a wildcard record and dynamic provision subdomains for multi tenancy
• Alternative 1: Nginx multi tenant configuration – web server
• Alternative 2: Apache multi tenant configuration – Web server
• Subdomains Wildcard SSL Certificate for multi tenancy. “SSL multi tenancy”
• Final Conclusion

Similarly, customers on the cloud vendors use the same infrastructure and still have their software instance, data separate and secure. Adding a new customer can be simplified using a self sign-up process, and a multi tenant application has an automated sign-up process along with the required subdomain.

Before continue with the reading, I would like to make a quick stop right here to recommend you an amazing article about Multi tenant Architecture SaaS Application on AWS where you’ll find valuable information for architect a SaaS multi-tenant application. 

The following explores how enterprises can use “Apache Multi tenant and Nginx Multi tenant to support SaaS applications”. This article also highlights how Nginx Multitenant and Apache Multitenant can be achieved along with their respective DNS wildcard records.

Why use multi tenancy in your Nginx and Apache configuration?

Nginx multi tenant or Apache can respond to wildcard subdomains (via *), which is excellent for multi tenant URL based SaaS applications. A multi tenant application is one that has a single codebase but supports many clients/tenants. To divide up users/clients/tenants with an application is to use subdomains. 

For example, mysaasapplication.com uses subdomains in such a way that each client can have its subdomain where they could log into its application. So customer1 can have something like customer1.mysaasapplication.com and customer2 can have customer2.mysaasapplication.com.

For a better understanding, I suggest you to review the differences between single tenant vs multi tenant SaaS architectures in order to comprehend how each architecture works.

Prerequisite: Setup your DNS subdomains with a wildcard record and dynamically provision subdomains for multi tenancy.

To access the application, you’ll need to tell the browser the address of the application, and this is taken care of by DNS (Domain Name System). The DNS is the phonebook of the Internet. It is a hierarchical and decentralized naming system for services, computers, or other resources connected to the Internet or a private network.

For a subdomain based SaaS application, we would need a DNS wildcard record. A Wildcard DNS is a record that will match requests for all or non-existent subdomains. A wildcard DNS record is specified by using an “*” as the part of a domain name, e.g., *.mysaasapplication.com. Wildcard lets us manage a single set of traffic routing rules, protection settings, and distribution settings.

The following is required to achieve wildcard subdomains.

1. A wildcard record should be in place in your DNS management records.

2. Create an ‘A’ or ‘CNAME’ record pointing to your multi tenant resource (server/load balancer).

3. This wildcard subdomain redirects all routes to your Multi tenant architecture.

While setting up a DNS, be sure to set up your  Time to Live (TTL) records according to your business needs. TTL is the time for which a DNS resolver caches a response. You can keep a long DNS TTL for static sites that don’t often change or if frequent updates or changes are made to your websites, you can reduce it to a lower value.

Alternative 1: Nginx multi tenant configuration – web server

For the Nginx multi tenant the server names are defined using the server_name directive in Nginx. Server Names may be specified using exact names, wildcard names, or regular expressions. We can have an asterisk/wildcard only on the name’s start or end, and only on a dot border. The names “www.*.mysaasapplication.org” and “w*.mysaasapplication.org” are invalid. An asterisk can match several name parts. The name “*.mysaasapplication.org” matches not only www.mysaasapplication.org but www.sub.mysaasapplication.org as well. 

Also, we can grab the subdomain value and set it to a variable using RegEx. Later, we can use the variable in any way we need. We can also set a different webroot per subdomain and change the log file names per subdomain using the variable in which we captured the subdomain. The following three examples show a simple configuration where all three virtual servers listen on port *:80 

If you installed Nginx multi tenant from the Debian or Ubuntu repositories, you could make the following configurations in /etc/nginx/sites-enabled/default file. This file is picked from nginx.conf because of the include /etc/nginx/sites-enabled/*; in nginx.conf. Once the configuration is in place, you can restart the Nginx service using the “sudo systemctl restart nginx” command.

You can also read our blog on Medium

Here are some examples:

Example 1

server {

    listen 80;                                        

    server_name *.mysaasapplication.com;                            

}    

Example 2

This block contains unexpected or invalid content.ResolveConvert to HTML

server {
    listen 80;
    server_name ~^(?.+)\.mysaasapplication\.com$;
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
        fastcgi_param ACCOUNT $my-subdomain; # $_SERVER['ACCOUNT'];
    }
}

Example 3

server {
    listen 80;
    server_name ~^(?<my-subdomain>.+)\.mysaasapplication\.com$;
    root /var/www/$my-subdomain;
    access_log /var/log/nginx/$my-subdomain-access.log;
    error_log  /var/log/nginx/$my-subdomain-error.log;
}

Alternative 2: Apache multi tenant configuration – Web server

In Apache, we can create a virtual host using ServerName and ServerAlias directives. A virtual host can handle a base ServerName and then uses ServerAlias to match a wildcard subdomain. You can make the required configuration in /etc/apache2/sites-available/000-default.conf, which is the default file of Apache2 on Ubuntu Servers. This file, however, does not come with the ServerName directive.

Once the Apache has been configured, you can restart it using the “sudo systemctl restart apache2” command on Ubuntu Servers. Here are some examples of this alternative.

Example 1

<VirtualHost *:80> 
ServerName my-site.mysaasapplication.io
ServerAlias *.mysaasapplication.org
DocumentRoot /var/www/my-saas-application
</VirtualHost>

The above is a virtual host like any other. It handles the base ServerName of my-site.mysaasapplication.org, which is optional to use. This allows the ServerAlias to match the wildcard subdomain that directs to a DocumentRoot.

Example 2

<VirtualHost *:80> 
ServerName my-site.mysaasapplication.io
ServerAlias *.mysaasapplication.or
VirtualDocumentRoot /var/www/mysaasapplication/%-3
</VirtualHost>

In the example above, VirtualDocumentRoot is a directive to the Apache module mod_vhost_alias. It sets the document root to a dynamic path that may contain variables that are evaluated when an actual request is handled. Here %-3 means “get the third dot-separated string of the domain from right to left”.

Subdomains Wildcard SSL Certificate for multi tenancy. “SSL multi tenancy”

For a SaaS company, the application must be performant, highly available, and hardened against attacks. A Wildcard Secure Socket Layer (SSL) Certificate is similar to any other SSL certificate. A Wildcard SSL Certificate is a digital certificate that is applied to a domain and all of its subdomains to secure them. 

An SSL Wildcard Certificate is a single certificate with a wildcard character (*) in the domain name field. This lets the certificate secure multiple subdomain names. When we are looking to secure several subdomains, such as customer1.mysaasapplication.com, customer2.mysaasapplication.com, and so on(*.mysaasapplication.com) with a single certificate, a Wildcard SSL Certificate comes in handy.

A Wildcard SSL Certificate is ideal for securing and protecting the main domain and any number of first-level subdomains. We can set up an unlimited number of subdomains. Once a Wildcard SSL Certificate is installed, and you deploy a new subdomain it will be protected by the certificate from our SaaS application, there will be no need to wait for the issuance of the certificate for the new subdomain.

A Wildcard SSL Certificate is the most suitable option when it comes to securing many subdomains at a low cost. And yes, don’t forget to deal with the certificates under your tenant subdomains. You would need to add them either in the Cloudfront CDN, Load balancer, or your web server.

Which is the perfect SaaS tech stack for your web app?

Final conclusion

Nginx Multi Tenant and Apache Multi Tenancy is a feature that can be used to minimize cost, effort, maintenance, etc. of enterprises and it helps applications work in a shared environment securely. If you need some help while working with your SaaS application, our dedicated DevOps team is always ready to help you with our DevOps outsourcing services!

This article discussed Nginx multi tenancy and Apache multi tenancy and saw the benefits of wildcard SSL certificates for SaaS applications. We saw how Nginx Multi tenant and Apache Multi tenant could help in SaaS applications, and we can have subdomains in real-time as per the need. 

We also explored the required configurations to be done for Nginx Multitenancy and Apache Multitenancy. We tried to understand the benefits of multi tenancy in SaaS Applications. We hope this guide finds you well and helps you understand and implement Nginx Multi tenant and Apache Multi tenant to support your SaaS applications.