MCM Platform — 3-Tier Deployment Guide

About this architecture

The 3-tier orchestrated deployment is the recommended architecture for production environments. It separates services by role into three distinct tiers to meet strict security compliance standards (such as SOC 2 and HIPAA) and optimize system performance:

• Tier 1: Access Node (VM1): Hosts the gateway interface. This is the only node exposed to public traffic.
• Tier 2: App Node (VM2): Hosts the core backend microservices and the User Interface (UI).
• Tier 3: DB Node (VM3): Hosts the storage layers.

3-Tier Network Architecture

1. Prerequisites & VM Specifications

Ensure that your physical, virtual (on-premises), or cloud virtual machines meet the following minimum configuration requirements:

Network Isolation & Public IP Requirements (Recommended)

To secure the platform from external vectors:

• VM1 (Access Node) - Public IP Required: VM1 must have a public IP address so you can access the ingress gateway and SSH into it from outside the network.
• VM2 & VM3 (App & DB Nodes) - Complete Public Isolation: Both the App Node (VM2) and DB Node (VM3) must be placed in private subnets/VLANs. They do not have public IP addresses (only private IPs) and cannot be reached directly from the internet.
• Outbound Internet Access (VM2): The containers running on the App Node (VM2) require outbound internet access (e.g., via a NAT Gateway or proxy). This is because the MCM microservices must connect to public cloud provider endpoints/APIs (such as AWS, GCP, and Azure APIs) to orchestrate resources, sync inventories, and collect cost/billing metrics.
• Temporary Outbound Access (VM3): The DB Node (VM3) only needs outbound internet access (e.g., via a NAT Gateway or proxy) temporarily during installation/upgrades to fetch packages, after which it can be restricted to internal cluster communications.

2. Network & Connectivity Requirements

To ensure strict network isolation (in accordance with the Network Isolation & Public IP Requirements detailed in Section 1 above), VMs must be placed within a dedicated virtual network utilizing public/private subnet routing.

Configure three distinct subnets in your virtual network (e.g., range 10.0.0.0/16):

• Public Subnet (10.0.1.0/24) — Hosts VM1 (mcm-access).
• Private Subnet 1 (10.0.2.0/24) — Hosts VM2 (mcm-app).
• Private Subnet 2 (10.0.3.0/24) — Hosts VM3 (mcm-db).

On-Premises / Private CloudAWSAzureGCP

Procedure: On-Premises & Private Cloud Setup

1. Configure Network Topology: Configure virtual switches (vSwitches), routing, and firewalls to meet these conditions:
   • Access Node (VM1): Must have a public IP address (or static public NAT mapping) to reach the internet and accept inbound connections on Port 80 (HTTP) and Port 443 (HTTPS). It must also have a private IP that can route traffic to VM2 and VM3.
   • App Node (VM2) & DB Node (VM3): Kept inside a private, isolated network. No direct inbound access from the internet is permitted.
   • Outbound NAT Routing: Configure your virtual firewall/router (e.g., pfSense, Cisco, OPNsense) to perform Source NAT (SNAT) / IP Masquerading so VM2 and VM3 can connect outbound to the internet.
   • SSH Inter-node Reachability: Ensure VM1 can connect directly to VM2 and VM3 on Port 22 (SSH).
2. Automated SSH Key Generation: The installer script install.sh running on VM1 (Access Node) automatically manages key distribution:
   • Key Generation: If no key exists, it will automatically generate a secure 4096-bit RSA keypair at /home/[user]/3-tier.pem on VM1.
   • Public Key Distribution: The script will prompt you for the SSH passwords of VM2 and VM3, using sshpass to transfer the public key.
   • Passwordless Sudo Configuration: It will also configure passwordless sudo privileges for the SSH users on VM2 and VM3.

3-Tier On-Premises Network Topology Diagram

Procedure: AWS VPC & Networking Setup

1. Create the VPC:

   • Navigate to the VPC Dashboard in the AWS Console and select Create VPC.
   • Choose VPC only. Name it mcm-vpc and set the IPv4 CIDR block to 10.0.0.0/16.

2. Create Subnets: Create three subnets inside mcm-vpc. To ensure physical fault tolerance, place them in different Availability Zones (AZs):

   • mcm-public-subnet: CIDR 10.0.1.0/24, Availability Zone us-east-1a (Access Gateway Node).
   • mcm-private-subnet-app: CIDR 10.0.2.0/24, Availability Zone us-east-1b (App Node).
   • mcm-private-subnet-db: CIDR 10.0.3.0/24, Availability Zone us-east-1c (Database Node).

3. Enable Auto-Assign Public IP on Public Subnet:

   • Select mcm-public-subnet from the Subnets list.
   • Click Actions > Edit subnet settings.
   • Under the Auto-assign IP settings, check Enable auto-assign public IPv4 address. Save changes.

4. Create Internet Gateway (IGW):

   • Select Internet Gateways in the left menu, and click Create internet gateway. Name it mcm-igw.
   • Once created, select mcm-igw, click Actions > Attach to VPC, choose mcm-vpc, and attach it.

5. Configure Public Routing:

   • Select Route Tables in the left menu and click Create route table. Name it mcm-public-rt and link it to mcm-vpc.
   • Edit the routes for mcm-public-rt: Add a route with Destination 0.0.0.0/0 and Target Internet Gateway > mcm-igw.
   • Go to Subnet associations > Edit subnet associations and associate it with mcm-public-subnet.

6. Configure NAT Gateway:

   • Select NAT Gateways in the left menu and click Create NAT gateway.
   • Name it mcm-natgw. Select mcm-public-subnet as the subnet.
   • Under Elastic IP allocation ID, click Allocate Elastic IP to assign a static public EIP. Click Create NAT gateway.

7. Configure Private Routing:

   • Create another route table named mcm-private-rt and link it to mcm-vpc.
   • Edit the routes for mcm-private-rt: Add a route with Destination 0.0.0.0/0 and Target NAT Gateway > mcm-natgw.
   • Go to Subnet associations > Edit subnet associations and associate it with mcm-private-subnet-app and mcm-private-subnet-db.

8. Instance Deployment:

   • Launch VM1 (mcm-access) in mcm-public-subnet. Choose a standard Ubuntu Server 22.04 LTS AMI. Verify that a public IPv4 address is auto-assigned, and associate it with the mcm-sg-access Security Group (detailed in Section 3).
   • Launch VM2 (mcm-app) in mcm-private-subnet-app and VM3 (mcm-db) in mcm-private-subnet-db using the same Ubuntu 22.04 AMI. Ensure Auto-assign public IP is set to Disable for both to maintain private network isolation, and associate them with the mcm-sg-app and mcm-sg-db Security Groups respectively (detailed in Section 3).

3-Tier AWS Network Topology Diagram

Procedure: Azure Virtual Network Setup

1. Create the Virtual Network (VNet):

   • Navigate to the Azure Portal and search for Virtual Networks. Click Create.
   • Name the VNet mcm-vnet. Define the primary address space as 10.0.0.0/16.

2. Create Subnets: Add three subnets inside mcm-vnet:

   • mcm-public-subnet: CIDR 10.0.1.0/24 (Access Gateway Node).
   • mcm-private-subnet-app: CIDR 10.0.2.0/24 (App Node).
   • mcm-private-subnet-db: CIDR 10.0.3.0/24 (Database Node).

3. Create Public IP for NAT:

   • Search for Public IP addresses in the portal and click Create.
   • Select Standard SKU, Static allocation, and name it mcm-nat-ip. Choose the same resource group and region as your VNet.

4. Create the NAT Gateway:

   • Search for NAT Gateways in the portal and click Create. Name it mcm-natgw.
   • Under the Outbound IP tab, select the previously created standard public IP resource mcm-nat-ip.

5. Associate Private Subnets with NAT Gateway:

   • On the NAT Gateway configuration page, go to the Subnet tab.
   • Select mcm-vnet and associate the gateway with mcm-private-subnet-app and mcm-private-subnet-db. Click Create.

6. Instance Deployment:

   • Deploy VM1 (mcm-access) in mcm-public-subnet. Associate a Standard Public IP address with its Network Interface (NIC), and link its subnet or NIC with the mcm-nsg-access Network Security Group (NSG) detailed in Section 3. Select Availability Zone 1 for VM placement.
   • Deploy VM2 (mcm-app) in mcm-private-subnet-app (Availability Zone 2, linked with the mcm-nsg-app NSG detailed in Section 3) and VM3 (mcm-db) in mcm-private-subnet-db (Availability Zone 3, linked with the mcm-nsg-db NSG detailed in Section 3). Do not associate public IPs with their NICs (set public IP to None).

3-Tier Azure Network Topology Diagram

Procedure: GCP VPC Setup

1. Create the VPC Network: Create a custom VPC network utilizing custom subnets:

   gcloud compute networks create mcm-vpc --subnet-mode=custom

2. Create Subnets: Create three distinct subnets. Place them in your target region (e.g., asia-south1):

   gcloud compute networks subnets create mcm-public-subnet --network=mcm-vpc --range=10.0.1.0/24 --region=asia-south1
   gcloud compute networks subnets create mcm-private-subnet-app --network=mcm-vpc --range=10.0.2.0/24 --region=asia-south1
   gcloud compute networks subnets create mcm-private-subnet-db --network=mcm-vpc --range=10.0.3.0/24 --region=asia-south1

3. Configure Cloud Router: Create a Cloud Router inside the same region to manage the NAT routing tables:

   gcloud compute routers create mcm-router --network=mcm-vpc --region=asia-south1

4. Configure Cloud NAT Gateway: Create a Cloud NAT gateway to enable private nodes to download dependencies safely:

   gcloud compute routers nats create mcm-natgw \
       --router=mcm-router \
       --region=asia-south1 \
       --auto-allocate-nat-external-ips \
       --nat-custom-subnet-ip-ranges=mcm-private-subnet-app,mcm-private-subnet-db

5. Instance Deployment:

   • Launch VM1 (mcm-access) in mcm-public-subnet (placed in Zone asia-south1-a) and assign an external ephemeral or static public IP. Assign the network tag mcm-access to VM1 to apply the target firewall rules detailed in Section 3.
   • Launch VM2 (mcm-app) in mcm-private-subnet-app (Zone asia-south1-b, tag mcm-app) and VM3 (mcm-db) in mcm-private-subnet-db (Zone asia-south1-c, tag mcm-db). Ensure External IP is set to None for both to apply the target firewall rules detailed in Section 3.

3-Tier GCP Network Topology Diagram

3. Firewall / Security Rules

Security Rule Rationale

1. Port 22 (TCP): Used for administrative SSH access to VM1, and for the deployment script on VM1 to securely tunnel configurations, keys, and certificates to VM2 and VM3.
2. Port 80 (TCP): Used for standard HTTP traffic. Port 80 automatically redirects incoming requests to secure HTTPS (port 443) so users do not experience connection errors if they access the site via http://.
3. Port 443 (TCP): Used for the primary secure application gateway access (routed through VM1).
4. Port 2377 (TCP): Used for cluster management communications. This is only needed between the Manager (VM1) and Workers (VM2, VM3).
5. Port 7946 (TCP & UDP): Used for control-plane "gossip" communication to exchange membership lists and discover services.
6. Port 4789 (UDP): Used for the VXLAN overlay data plane. This encapsulates container-to-container packets securely over a flat virtual network.

# Define node IPs
ACCESS_NODE_IP="[YOUR_ACCESS_NODE_PRIVATE_IP]"
APP_NODE_IP="[YOUR_APP_NODE_PRIVATE_IP]"
DB_NODE_IP="[YOUR_DB_NODE_PRIVATE_IP]"

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 80/tcp comment "HTTP APISIX Redirect"
sudo ufw allow 443/tcp comment "HTTPS APISIX Gateway"
sudo ufw allow from "$ACCESS_NODE_IP" to any port 22 proto tcp comment "Access Node SSH"

# Container Orchestrator & Gossip ports
sudo ufw allow from "$APP_NODE_IP" to any port 2377 proto tcp comment "Orchestrator Manager"
sudo ufw allow from "$APP_NODE_IP" to any port 7946 proto tcp comment "Gossip Control TCP"
sudo ufw allow from "$APP_NODE_IP" to any port 7946 proto udp comment "Gossip Control UDP"
sudo ufw allow from "$APP_NODE_IP" to any port 4789 proto udp comment "VXLAN Orchestrator Overlay"

sudo ufw allow from "$DB_NODE_IP" to any port 2377 proto tcp comment "Orchestrator Manager"
sudo ufw allow from "$DB_NODE_IP" to any port 7946 proto tcp comment "Gossip Control TCP"
sudo ufw allow from "$DB_NODE_IP" to any port 7946 proto udp comment "Gossip Control UDP"
sudo ufw allow from "$DB_NODE_IP" to any port 4789 proto udp comment "VXLAN Orchestrator Overlay"

sudo ufw --force enable

# Define node IPs
ACCESS_NODE_IP="[YOUR_ACCESS_NODE_PRIVATE_IP]"
DB_NODE_IP="[YOUR_DB_NODE_PRIVATE_IP]"

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from "$ACCESS_NODE_IP" to any port 22 proto tcp comment "SSH from VM1"

# Container Orchestrator & Gossip ports
sudo ufw allow from "$ACCESS_NODE_IP" to any port 7946 proto tcp comment "Gossip Control TCP"
sudo ufw allow from "$ACCESS_NODE_IP" to any port 7946 proto udp comment "Gossip Control UDP"
sudo ufw allow from "$ACCESS_NODE_IP" to any port 4789 proto udp comment "VXLAN Orchestrator Overlay"

sudo ufw allow from "$DB_NODE_IP" to any port 7946 proto tcp comment "Gossip Control TCP"
sudo ufw allow from "$DB_NODE_IP" to any port 7946 proto udp comment "Gossip Control UDP"
sudo ufw allow from "$DB_NODE_IP" to any port 4789 proto udp comment "VXLAN Orchestrator Overlay"

sudo ufw --force enable

# Define node IPs
ACCESS_NODE_IP="[YOUR_ACCESS_NODE_PRIVATE_IP]"
APP_NODE_IP="[YOUR_APP_NODE_PRIVATE_IP]"

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from "$ACCESS_NODE_IP" to any port 22 proto tcp comment "SSH from VM1"

# Container Orchestrator & Gossip ports
sudo ufw allow from "$ACCESS_NODE_IP" to any port 7946 proto tcp comment "Gossip Control TCP"
sudo ufw allow from "$ACCESS_NODE_IP" to any port 7946 proto udp comment "Gossip Control UDP"
sudo ufw allow from "$ACCESS_NODE_IP" to any port 4789 proto udp comment "VXLAN Orchestrator Overlay"

sudo ufw allow from "$APP_NODE_IP" to any port 7946 proto tcp comment "Gossip Control TCP"
sudo ufw allow from "$APP_NODE_IP" to any port 7946 proto udp comment "Gossip Control UDP"
sudo ufw allow from "$APP_NODE_IP" to any port 4789 proto udp comment "VXLAN Orchestrator Overlay"

sudo ufw --force enable

Outbound Connectivity & Domains

The MCM platform requires outbound access to the following domains for cloud management operations and optional integrations:

Registry Archive Download Note: The MCM platform deployment archive (mcm_artifacts_1.1.0.tar.gz) contains all core application services and bundled Docker images. Since this archive is only downloaded and extracted directly on the Access Node (VM1), outbound internet connectivity to the registry repository is required only on VM1 during installation. VM2 and VM3 do not require access to the registry repository.

External Connectivity Requirements (Installation Time)

During the initial installation process only, the server requires outbound access to download dependencies:

4. Installation Procedure

Pre-Deployment Checklist

Before you begin:

• Ensure that the SSH user on VM2 and VM3 belongs to the sudo group (the installer will automatically configure this to be passwordless during setup).

• Ensure SSH password authentication is enabled on VM2 and VM3 to allow automatic public key distribution.

  Run the following commands on VM2 and VM3 to temporarily enable it:

  echo "PasswordAuthentication yes" | sudo tee /etc/ssh/sshd_config.d/00-mcm-temp-auth.conf
  sudo systemctl restart ssh

Procedure: Verify Network & Key Settings

1. Network Connectivity: Check that VM1 can connect to VM2 and VM3. Verify the required ports (such as SSH Port 22) are open on your cloud VPC security group or firewall. Also verify that no other service is currently running on the required cluster ports (such as ports 2377, 7946, 4789); if a conflicting service is running on those ports, terminate/kill it before starting the platform.
2. Binary Package Preparation: Make sure that the tar file is downloaded and extracted to run the deployment (follow Step 1 for this).
3. Hardware Requirements Verification: Make sure that before deployment you have a minimum of 10 GB storage and 3 GB RAM available. (On a standard 4 GB VM, approximately ~3.8 GB is typically usable after BIOS/hypervisor reservations; the 3 GB free RAM threshold is designed to account for baseline OS and Docker daemon overhead, so a 4 GB VM is fully sufficient). You can verify these on your host by running the df -h and free -h commands.
4. Automated Connection & Resource Testing: The installer script install.sh automatically performs pre-checks for system hardware (minimum RAM and disk space), OS version verification, and bidirectional network port connectivity. If any misconfiguration is detected (such as blocked ports, insufficient resources, or incorrect IP), the script will report the exact failing check and exit. You must fix the configuration issue and rerun the installer.

Download & Execute the Installer

Before you begin:

• Verify that you have enabled SSH password authentication on VM2 and VM3.
• Ensure all cluster nodes can communicate mutually over the required Container Orchestrator and telemetry ports.
• IP address configuration:
  • If your VMs are on the same network, then enter the private IPs of the VMs when prompted.
  • Else, if your VMs are on different networks, use public IPs of all three VMs (need to give Public IPs to VM2 and VM3), but using public IPs is strongly discouraged due to security risks and high latency. Instead, configure VPC/VNet Peering, Transit Gateways, VPNs, or DirectConnect/ExpressRoute according to your setup so that all three VMs can communicate securely over their internal private IPs, then enter their private IPs when prompted.
• Ensure VM1 has SSH access to both VM2 and VM3 (with SSH password authentication enabled on them) before executing the script.

Procedure

1. SSH into VM1 (Access Node):

   ssh [VM1_USER]@<VM1_PUBLIC_IP>
   # or (using a private key)
   ssh -i /path/to/key.pem [VM1_USER]@<VM1_PUBLIC_IP>

   Custom SSH Port (Optional)

   If your server uses a custom SSH port (e.g., 2222) instead of the default port 22, you can update the SSH configuration and connect as follows:

   1. Update the SSH configuration to listen on your custom port:

      sudo sed -i 's/#Port 22/Port 2222/' /etc/ssh/sshd_config

   2. Restart the SSH service to apply the change:

      sudo systemctl restart ssh

   3. Connect from your local terminal using the custom port:

      ssh -p 2222 [VM1_USER]@<VM1_PUBLIC_IP>

   IMPORTANT: Remember to update your cloud VPC security groups, network firewalls, and host firewalls to keep this custom SSH port open inbound instead of the default port 22.

2. Download the MCM platform deployment archive: (Contact the Revdau team for download credentials at mcm@revdau.ai for access)

   You will receive a deployment credentials email from the Revdau team containing your Registry Credentials (Username and Password/Token):

   

   # Define credentials at the top
   REGISTRY_USER="your_username"
   REGISTRY_PASS="your_password"
   
   # Download the archive from the registry repository
   wget --user="$REGISTRY_USER" --password="$REGISTRY_PASS" -O mcm_artifacts_1.1.0.tar.gz "http://92.204.249.45:8080/repository/mcm-artifacts/1.1.0/mcm_artifacts_1.1.0.tar.gz"

3. Extract the downloaded archive:

   tar -xzvf mcm_artifacts_1.1.0.tar.gz

4. Navigate into the installation directory, and run the installer script:

   cd mcm_artifacts
   sudo chmod +x install.sh
   sudo bash install.sh --three-tier

5. Respond to the interactive prompts to configure network authentication:

   • Enter VM1 IP (Access Node): Type the IP address of VM1.
   • Enter VM2 IP (App Node): Type the IP address of VM2.
   • Enter VM2 SSH Username: Type the SSH username for VM2.
   • Enter VM2 SSH Port: Type the SSH port number for VM2.
   • Enter one-time password for VM2: Type the user password for VM2.

   (Repeat this configuration when prompted for VM3.)

6. Results: The script executes the network prechecks and prints the verification status for each service path:

   ==========================================================
             MCM UNIFIED 3-TIER SWARM DEPLOYMENT
   ==========================================================
   ==========================================================
             VERIFYING CLUSTER VM CONNECTIONS
   ==========================================================
   Enter VM1 IP (Access Node): 10.0.1.2
   VM1 IP: 10.0.1.2
   
   ----------------------------------------------------------
   Configure Authentication & SSH for VM2 (App Node)
   ----------------------------------------------------------
   Enter VM2 IP (App Node): 10.0.2.4
   Enter VM2 SSH Username: ubuntu
   Enter VM2 SSH Port: 22
   Enter one-time password for VM2: [Type VM2 password]
   Copying VM1's public key to VM2 (10.0.2.4)...
   Configuring passwordless sudo on VM2 (10.0.2.4)...
   ✅ SSH Key & Passwordless Sudo successfully configured for VM2!

   (The script will repeat this exact flow for VM3).

   Once connection setup is complete, it will verify network connectivity on all ports:

   Running network path connectivity verification...
   Verifying connection from Access Node to App Node ports:
     - SSH service connection (Port 22/TCP): ✅ OK
     - Gossip synchronization service (Port 7946/TCP): ✅ OK
     - Gossip synchronization service (Port 7946/UDP): ✅ OK
     - Cluster Overlay network (Port 4789/UDP): ✅ OK
   ...
   Network connectivity prechecks successfully passed!

   After verification passes, the installer script will automatically perform the following actions:

   • Initialize Orchestration Engine on VM1 and join VM2/VM3 as workers.
   • Apply node labels (tier=access, tier=app, tier=db).
   • Configure current SSH users on VM1, VM2, and VM3 as members of the docker group so sudo is not required for running container platform commands in future sessions.
   • Sync configurations and certificates over SSH tunnels to VM2 and VM3.
   • Automatically copy and load the bundled container image tarballs onto their respective nodes.
   • Deploy the container orchestrator stack.

Post-Deployment Warm-up: After the installer finishes, please wait at least 5 minutes for the container orchestrator manager to pull metadata, initialize all container volumes, and start the services.

Once the initialization is complete, open the application in your web browser:

Platform Activation & Onboarding

When you access the MCM platform gateway for the first time, you must activate the installation using your subscription details:

1. Retrieve Your Subscription Key

You will receive a deployment resources email from the Revdau team containing your unique Subscription Key:

2. Activate the Subscription

Open the application URL (https://<DOMAIN_OR_IP>) in your web browser. You will be greeted by the Subscription Activation page. Enter your Subscription Key and your registered MSP Email ID, then click Activate:

3. Create the Administrator User

Once the subscription is activated, you will be redirected to the Create User page. Enter the details for the primary platform administrator (First Name, Last Name, Email, MSP Name, and Legal Name) and click Submit:

4. Log In to the Platform

After submitting, you will be redirected to the main login portal.

For a walkthrough of the login process, managing credentials, and exploring user dashboards, please refer to the Getting Started User Guide.

5. Post-Deployment Verification & Operations

You can verify the status and health of all deployed services by executing the healthcheck script (Optional) on VM1 (Access Node):

sudo bash /opt/mcm/scripts/healthcheck.sh

Post-Deployment Security Hardening (Recommended for Production)

Once the installation is successful and passwordless SSH keys have been exchanged, disable SSH password authentication on VM2 (App Node) and VM3 (DB Node) to secure your cluster and meet SOC2/HIPAA compliance standards.

Always toggle via this file — editing sshd_config directly won't work, since cloud-init's drop-in in sshd_config.d/ takes precedence.

Run the following commands on VM2 and VM3 to disable password authentication:

echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/00-mcm-temp-auth.conf
sudo systemctl restart ssh

General Verification and Control

For verification steps, stack teardown commands, and utility control scripts (starting, stopping, restarting, or upgrading the platform components), please refer to the Helper Scripts and Commands Guide.

For custom domain configuration and SSL/TLS certificate management, please refer to the Domain and TLS Certificate Configuration Guide.

For troubleshooting configuration, certificate, or service initialization errors, refer to the Troubleshooting Guide.