Apache and Nginx Multi-Tenancy 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 own bedroom, kitchen, hall, electricity meter, water taps, etc. 

Similarly, customers on the cloud vendors use the same infrastructure and still have their software instance and 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.

The following explores how enterprises can use Apache Multi-Tenant and Nginx Multi-Tenant to support SaaS applications. This article also highlights how Nginx Multi-Tenant and Apache Multi-Tenant 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 review the differences between single-tenant and multi-tenant SaaS architectures to comprehend how each architecture works.

Prerequisite: Set Up 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 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.

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 use 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 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 SaaS companies, applications 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.

Final Conclusion

Nginx Multi-Tenant and Apache Multi-Tenant is a feature that can be used to minimize cost, effort, maintenance, etc. of enterprises. It helps applications work in a shared environment securely. 

This article discussed Nginx Multi-Tenancy and Apache Multi-Tenancy and outlined 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 needed. 

We also explored the required configurations to be done for Nginx Multi-Tenancy and Apache Multi-Tenancy. 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.