MCM Platform — 3-Tier Deployment GuideCopy Anchor Link

About this architectureCopy Anchor Link

The 3-tier orchestrated deployment is the recommended architecture for production environments. It separates services by role into three distinct tiers to strengthen security isolation and optimize system performance:

• Tier 1: Access Node (VM1): Hosts the API gateway (APISIX) and the mcm management service. This is the only node exposed to public traffic, and the node you run the installer from.
• Tier 2: App Node (VM2): Hosts the core backend microservices, the User Interface (UI) and Kibana.
• Tier 3: DB Node (VM3): Hosts the storage and identity layers — PostgreSQL, Elasticsearch and Keycloak.

An Elastic Agent also runs on each of the three nodes for self-monitoring: it collects host metrics and container logs and sends them only to the platform's own Elasticsearch.

3-Tier Network ArchitectureCopy Anchor Link

1. Prerequisites & VM SpecificationsCopy Anchor Link

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

Baseline Network PrerequisitesCopy Anchor Link

The 3-tier architecture requires the following network conditions:

• VM1 (Access Node): Must be reachable by end users — either via a public IP, VPN, or internal corporate network.
• VM2 (App Node) & VM3 (DB Node): Must have private IP connectivity to VM1 and to each other. These nodes do not need to be reachable from outside your network.
• Outbound Internet Access:
  • All VMs: Require outbound internet access during installation to download system dependencies (Docker, packages, etc.).
  • VM2 (Runtime): Requires persistent outbound internet access because the MCM microservices connect to cloud provider APIs (AWS, Azure) for resource orchestration, inventory sync, and cost metrics.

For detailed port mappings, security groups, and domain firewall rules, see Section 2: Network & Security Requirements.

2. Network & Security RequirementsCopy Anchor Link

All three VMs must be placed within a network where they can route traffic to each other using private IPs. A single subnet (or separate subnets for strict tiering) can be used depending on your network topology.

Example IP layout (using 10.0.0.0/16):

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

On-Premises & Private Cloud SetupCopy Anchor Link

If you are deploying on physical servers or a private virtualized environment:

1. VM Provisioning: Provision 3 virtual machines meeting the CPU, RAM, and Disk specifications listed in Section 1: Prerequisites & VM Specifications.
2. Network Layout & IP Assignment:
   • VM1 (mcm-access): Assign an IP address accessible by your target users (can be a public IP or a private IP if accessed via an internal corporate network, VPN, or local load balancer).
   • VM2 (mcm-app) & VM3 (mcm-db): Assign static private IP addresses. Ensure VM1, VM2, and VM3 have mutual private IP routing to communicate with each other.
3. Firewall & Egress Configuration: Configure your network firewall appliances or host-level firewalls (e.g. UFW) using the Port Requirements and Outbound Connection Requirements tables below.

Port RequirementsCopy Anchor Link

The following ports must be open between the VMs. Configure these in your firewall, security groups, or host-level rules (e.g., UFW) as needed:

Outbound Connection RequirementsCopy Anchor Link

The MCM platform requires outbound HTTPS (port 443) connectivity to the following main domains:

AWS & Azure Infrastructure SetupCopy Anchor Link

If you are provisioning resources on a public cloud, navigate to the dedicated guide for your provider to set up your network, security groups, and VM instances:

• 👉 Go to the AWS Deployment Guide
• 👉 Go to the Azure Deployment Guide

Once your cloud infrastructure and VMs are provisioned, return to Section 3: Installation Procedure of this guide to complete the platform setup.

3. Installation ProcedureCopy Anchor Link

Pre-Deployment ChecklistCopy Anchor Link

Before you begin:

• Ensure that the SSH user on VM2 and VM3 belongs to the sudo group.

• Ensure SSH password authentication is enabled on VM2 and VM3 so the installer can distribute its SSH key (a one-time step; you can turn password authentication off again after installation).

  Run the following commands on VM2 and VM3 to configure a password and temporarily enable authentication:

  Copy Text

  # Set a password for the SSH user (e.g. ubuntu)
  sudo passwd [VM_SSH_USER]
  
  # Enable password authentication drop-in config
  echo "PasswordAuthentication yes" | sudo tee /etc/ssh/sshd_config.d/00-mcm-temp-auth.conf
  sudo systemctl restart ssh

Step 1: Account Registration & Portal AccessCopy Anchor Link

Follow these steps on the MCM Nexus Portal to set up your account:

1. Visit MCM Portal Landing Page: Navigate to https://nexus.mcm.revdau.ai and click the Continue button.

   

2. Complete the Sign-Up Form: Fill in your organizational and contact details in the registration form to create your account.

   

3. Receive Verification & Credentials Email: Check your inbox for the welcome email containing your initial credentials and verification details.

   

4. Sign In to MCM Portal: Go to the login screen and sign in using your registered email and temporary password.

   

5. Set Your Account Password: On your first login, configure a secure password for your account.

   

Step 2: License Request & Approval WorkflowCopy Anchor Link

1. Access Portal Workspace Dashboard: After logging in, access your workspace dashboard.

   

2. Navigate to the Request Tab: Click on the Request tab in the top navigation bar.

   

3. Submit License Request & Wait for Approval: Fill out and submit your license entitlement request.

   
   Administrator Approval

   The MCM Administrator team reviews and approves submitted license requests. Once approved, the software package download and license entitlements become accessible under the License tab.

Step 3: Generate Download Command & Server DeploymentCopy Anchor Link

1. Open Your License: In the MCM Nexus portal, open Licenses and select your license. Under Subscription key, click Create key if you have not already. Copy the key when it is shown — it is displayed only once, and you can Rotate key at any time. You will use it both to download the installer and to activate the platform.

   

2. Select Release Version & Copy Download Command: Under Download installation package, select version 2.0.0 from the Version dropdown and click Copy next to the wget command. If your server reaches the internet through a proxy, enter it in Proxy URL (optional) first and the command is adjusted for you. You can also click Download to save the package through your browser.

   

3. SSH into VM1 (Access Node):

   Copy Text

   ssh [VM1_USER]@<VM1_IP>
   # or using private key
   ssh -i /path/to/key.pem [VM1_USER]@<VM1_IP>

4. Execute the Copied Download Command:

   Copy Text

   wget -c --header="Authorization: ApiKey <YOUR_SUBSCRIPTION_KEY>" \
     "https://nexus.mcm.revdau.ai/api/mcm-app/downloads/package?version=2.0.0" -O mcm-installer.tar.gz

   Replace <YOUR_SUBSCRIPTION_KEY> with your subscription key. The -c flag resumes an interrupted download — re-run the same command to continue.

5. Extract and Launch the Installer:

   Copy Text

   tar -xzf mcm-installer.tar.gz
   cd mcm_artifacts
   sudo ./mcm install --env=main --mode=three-tier

   MCM 2.0 is installed with a single mcm command-line tool (it replaces the install.sh and upgrade.sh scripts used in v1.2). Run it from inside the extracted mcm_artifacts folder on VM1.

6. Provide Node Connection Details: When run in a terminal, the installer prompts for any connection detail you did not pass as a flag:

   • VM1 IP (Access Node): the address this host advertises to the cluster.
   • VM2 IP, SSH user and SSH port (App Node).
   • VM3 IP, SSH user and SSH port (DB Node).

   If VM2 and VM3 do not yet trust VM1's SSH key, the installer asks for each node's SSH password once, creates an SSH key, installs it on the node and configures passwordless sudo. You can also pass everything on the command line:

   Copy Text

   sudo ./mcm install --env=main --mode=three-tier \
     --vm1-ip=<VM1_IP> \
     --vm2-ip=<VM2_IP> --vm2-user=<VM_SSH_USER> --vm2-bootstrap \
     --vm3-ip=<VM3_IP> --vm3-user=<VM_SSH_USER> --vm3-bootstrap

   Omit the --vm2-bootstrap / --vm3-bootstrap flags on later runs, once the nodes already trust VM1's key. The installer then joins VM2 and VM3 to the cluster, labels the nodes by tier and deploys the platform.

   If the servers reach the internet through a corporate proxy, also add --http-proxy=http://<PROXY_HOST>:<PORT> and --https-proxy=http://<PROXY_HOST>:<PORT> (and optionally --no-proxy=<COMMA_SEPARATED_DESTINATIONS>). You can change the proxy later under Settings > Proxy in the MCM console or with sudo mcm proxy configure.

7. Wait for Post-Deployment Warm-up: After completion, wait approximately 5 minutes for all container services to initialize.

Step 4: Platform Activation & Super Admin SetupCopy Anchor Link

Once deployment completes, navigate to https://<VM1_IP_OR_DOMAIN>/subscription in your browser:

1. Activate Subscription: Enter your Subscription Key and click Continue. Review the license details (organization, license name, plan, status, validity and owner), then click Activate.

   

2. Owner Account Created: Activation creates the account for the license owner and emails their login details. When you see Owner account created, click Continue to login.

   

3. Log In to Platform: Log in with the credentials from the email and proceed to the User Guide: first-run activation.

4. Operations & Health VerificationCopy Anchor Link

You can verify the status and health of all deployed services with the mcm tool (optional) on VM1 (Access Node):

mcm status         # platform version, URL and per-service replica status
mcm healthcheck    # point-in-time health snapshot of every service

General Verification and ControlCopy Anchor Link

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.