Deployment guide

MeshCentral

Overview

MeshCentral is an open-source, self-hosted remote monitoring and management platform. You install a lightweight agent on Windows, Linux and macOS devices, then control desktops, transfer files, open remote terminals, and monitor and patch those devices from a single web console. Everything runs on your own server, with no third-party cloud in the middle.

This SecureAnyCloud image installs Node.js LTS and MeshCentral 1.2.1 natively and runs MeshCentral as a dedicated system service bound to the loopback connector 127.0.0.1:4430. MeshCentral is HTTPS-native, so its console and agent tunnels use secure WebSockets. nginx terminates TLS on port 443 with a per-VM self-signed certificate and reverse proxies to MeshCentral. Port 80 serves an unauthenticated health endpoint and redirects everything else to HTTPS.

What you get:

MeshCentral 1.2.1 installed natively on Node.js 22 LTS and run as the meshcentral system service
The built-in NeDB database, so no external MongoDB is required
nginx terminating TLS on :443 (per-VM self-signed certificate) and reverse proxying to MeshCentral on 127.0.0.1:4430 with the WebSocket upgrade
Port 80 serving an unauthenticated /healthz endpoint and redirecting all other traffic to HTTPS
Self-signup disabled and a unique site admin password generated on the first boot of every VM, recorded in a root-only file (username admin)
A dedicated Azure data disk at /var/lib/meshcentral holding the NeDB database, config.json and TLS certificates
meshcentral.service and nginx.service as enabled, active systemd units
24/7 SecureAnyCloud support

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a reasonable starting point for a small fleet. Choose a larger size for more managed devices and concurrent remote sessions.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network, and 80/tcp and 443/tcp for the console and agent connections. The appliance ships a self-signed certificate. For production, put your own domain and a trusted certificate (for example Let's Encrypt) in front of it, as described under Maintenance.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for MeshCentral by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22), HTTP (80) and HTTPS (443).

Review the dedicated data disk on the Disks tab, then select Review + create and Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:meshcentral-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name meshcentral \
  --image sac1647283583153:meshcentral-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name meshcentral --port 80 --priority 1010
az vm open-port --resource-group <your-rg> --name meshcentral --port 443 --priority 1020

First boot takes a few minutes. In the background, the VM generates its own credentials and starts the services. If you connect as soon as the VM shows as running, wait for that setup to finish before you continue.

Run sudo cloud-init status --wait. It prints status: done when the VM is ready. The credentials and services described below exist only after that.

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

systemctl is-active meshcentral.service nginx.service

Both services report active. MeshCentral runs as a Node.js service bound to the loopback connector 127.0.0.1:4430. nginx fronts it with TLS on port 443, including the WebSocket upgrade the console requires, plus a port 80 health endpoint and HTTPS redirect.

MeshCentral's database and certificates live on the dedicated Azure data disk mounted at /var/lib/meshcentral.

Step 5 - Retrieve your admin password

Your VM generated a unique MeshCentral site admin password on first boot and wrote it to a root-only file. Read it with sudo:

sudo cat /root/meshcentral-credentials.txt

The file contains MESHCENTRAL_USERNAME (always admin), MESHCENTRAL_PASSWORD and the URL to open. Store the password somewhere safe. The file is mode 0600 and owned by root, so only an administrator can read it.

Step 6 - Confirm the health endpoints

Run these commands to check the unauthenticated health endpoint that nginx serves for load balancers and probes:

curl -s http://localhost/healthz
curl -sk https://localhost/healthz

Both return ok. Port 80 returns HTTP 301 and redirects to HTTPS, and the console at https://<vm>/ returns HTTP 200.

The /healthz endpoint never requires authentication, so it is safe for an Azure Load Balancer health probe.

Step 7 - Verify authentication from the command line

MeshCentral's login is a form post over the TLS edge that establishes a session cookie. The check below signs in with the correct per-VM password and reaches the console, while a wrong password stays on the login page.

The command embeds your unique password, so run it interactively rather than from a script. Substitute the value of MESHCENTRAL_PASSWORD from Step 5 for <MESHCENTRAL_PASSWORD>:

login() { j=$(mktemp); bf=$(mktemp); \
  curl -sk -o /dev/null -c "$j" -b "$j" --data-urlencode action=login \
  --data-urlencode username=admin --data-urlencode "password=$1" https://127.0.0.1/; \
  curl -sk -b "$j" -o "$bf" https://127.0.0.1/; \
  grep -qi logout "$bf" && echo "authenticated (reached console)" || echo "rejected"; \
  rm -f "$j" "$bf"; } login '<MESHCENTRAL_PASSWORD>'

The correct per-VM password prints authenticated (reached console). A wrong password prints rejected.

Loopback checks like this are excluded from MeshCentral's brute-force throttle, so your health checks never lock the account. Connections from real client IP addresses keep full brute-force protection.

Set the server name to your public address

On first boot, the VM writes the address Azure reports into MeshCentral's server name (cert in /var/lib/meshcentral/config.json), the TLS certificate and the credentials file. With a Standard SKU public IP (the Azure default, and the --public-ip-sku Standard in Step 2), the current image records the VM's private address (10.0.0.x).

MeshCentral then rejects the console's connections from your browser at the public IP (Invalid origin in HTTP request). Signing in at the public IP fails with Login failed, check username and password., even with the correct password from Step 5. If you see that message, this is the cause. Check the recorded name:

sudo grep '"cert"' /var/lib/meshcentral/config.json

If it shows a 10. address, set the public IP on the VM. Azure's instance metadata service reports the public IP to the VM itself, and nothing leaves the VM:

PUBLIC_IP=$(curl -s -H Metadata:true 'http://169.254.169.254/metadata/loadbalancer?api-version=2020-10-01' | grep -o '"frontendIpAddress":"[^"]*"' | head -1 | cut -d'"' -f4)
PRIV=$(hostname -I | awk '{print $1}'); echo "public $PUBLIC_IP, private $PRIV"
sudo sed -i "s/\"cert\": \"$PRIV\"/\"cert\": \"$PUBLIC_IP\"/" /var/lib/meshcentral/config.json
sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout /etc/nginx/sac-meshcentral/server.key -out /etc/nginx/sac-meshcentral/server.crt \
  -subj "/CN=$PUBLIC_IP" -addext "subjectAltName=IP:$PUBLIC_IP,IP:$PRIV"
sudo chmod 0600 /etc/nginx/sac-meshcentral/server.key
sudo sed -i "s/\b$PRIV\b/$PUBLIC_IP/g" /root/meshcentral-credentials.txt
sudo systemctl restart meshcentral nginx

Give MeshCentral a minute to load before you sign in. Your admin password does not change.

To use a DNS name instead, set PUBLIC_IP to the name and write DNS:$PUBLIC_IP in place of IP:$PUBLIC_IP. Do this before you add devices, because agents are issued the server name.

Step 8 - Sign in to the console

Browse to https://<vm-public-ip>/. The appliance uses a self-signed certificate, so accept the browser warning. For production, put your own domain and certificate in front, as described under Maintenance.

On the MeshCentral sign-in page, enter the username admin and the password from Step 5.

Step 9 - The device console

After you sign in, you land on the My Devices console. Every device you enrol appears here, grouped into device groups.

From this console you can control the desktop, open a remote terminal, transfer files and see live status for each managed machine.

Step 10 - Add a device

Create a device group, then click Add Agent to get the installer for your platform. MeshCentral generates a small agent for Windows, Linux, macOS and more.

Run the agent on a device. The machine appears in the console within seconds, ready for remote control.

Step 11 - Manage your account

Open My Account from the menu to change your password, enable two-factor authentication and manage account settings.

As the site administrator, you can also open My Server to see server status and manage users.

Step 12 - Confirm data lives on the dedicated disk

MeshCentral stores its data under /var/lib/meshcentral on the dedicated Azure data disk. That data covers the NeDB database (users, device groups, enrolled devices, event and stats history), config.json and the generated TLS certificates. Because it is on its own disk, it survives OS changes and can be resized independently. Confirm the mount:

findmnt /var/lib/meshcentral

The mount is backed by a separate Azure data disk captured into the image and re-provisioned on every VM.

Maintenance

Password: the site admin password is set on first boot. To change it, sign in and use My Account, or manage users from the My Server area.
TLS and your own domain: the appliance ships a per-VM self-signed certificate on port 443. For production, point a DNS name at the VM and install a trusted certificate, for example with certbot and Let's Encrypt. Then set that name as the cert value in /var/lib/meshcentral/config.json and restart meshcentral.service so agents are issued the correct server address.
Agents: install the MeshCentral agent on each device you want to manage, using Add Agent in a device group. Agents connect back to the server over port 443.
Upgrades: MeshCentral is installed under /opt/meshcentral. To upgrade, run npm install meshcentral@<version> in that directory and restart meshcentral.service. Your data under /var/lib/meshcentral is preserved.
Storage: all MeshCentral state lives under /var/lib/meshcentral on the data disk. Back up that volume to protect your users, device groups and history.
Self-signup: the image disables new-account self-signup, so only the site admin account exists until you add more users from My Server.
Security patches: unattended-upgrades remains enabled, so the OS continues to receive security updates automatically.

Support

SecureAnyCloud provides 24/7 expert support for this image. Contact sales@secureanycloud.com.

Deploy on Azure

Launch MeshCentral on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

Overview

MeshCentral is a self-hosted remote device management and remote-desktop console. You install a small agent on your Windows, macOS and Linux devices, and they appear in a central web console. From there you can take remote-desktop control, open a terminal, transfer files, view hardware and power state, and run management tasks, all from your own server and over your own network.

MeshCentral is an open-source, self-hosted alternative to hosted remote-support and RMM tools. This SecureAnyCloud image packages it on Ubuntu 24.04 with nginx in front.

What you get:

MeshCentral installed natively with Node.js, running under a dedicated meshcentral service account and listening on port 4430
nginx as the only way in: it terminates HTTPS on port 443 and reverse-proxies to MeshCentral with the WebSocket upgrade that the console control channel and agent tunnels require
Port 80 answering an unauthenticated health endpoint and redirecting everything else to HTTPS
A dedicated EBS data volume mounted at /var/lib/meshcentral, holding the configuration, the embedded database of users, device groups and nodes, and the generated certificates, and resizable independently of the operating system disk
A one-shot first-boot service on every instance that generates a fresh administrator account with a unique password, grants it site-administrator rights, generates fresh server and agent certificates, and records the credentials in /root/meshcentral-credentials.txt with mode 0600
No shared or default credentials and no reused certificates in the image, with open self-signup disabled so only accounts an administrator creates can sign in

Prerequisites

Before you deploy this image, make sure you have:

An Amazon Web Services account where you can launch EC2 instances
IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
An EC2 key pair in the target Region for SSH access to the instance
A VPC and subnet in the target Region, with a security group that allows inbound port 22 from your management network and inbound ports 80 and 443 from the networks your operators and managed devices use to reach MeshCentral
The AWS CLI (version 2) installed locally, if you plan to deploy from the command line

Launch the Instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for MeshCentral. Select the SecureAnyCloud listing, choose Select, then choose Continue on the subscription summary.

Pick an instance type of t3.small or larger. Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet, then create or select a security group. The group must allow inbound port 22 from your management network and inbound ports 80 and 443 from the networks your operators and devices use.

Leave the root volume at the default size or larger. The image adds a separate data volume for the MeshCentral database and certificates automatically.

Select Launch instance. First-boot initialisation generates the certificates and the administrator account. It takes about a minute after the instance state becomes Running and the status checks pass.

Launch the Instance from the AWS CLI

Run the following command to launch an instance from the SecureAnyCloud MeshCentral Marketplace AMI into an existing subnet and security group.

Replace <ami-id> with the AMI ID shown on the Marketplace listing and <key-name> with your EC2 key pair name. Replace <subnet-id> with your subnet ID and <security-group-id> with a security group that opens ports 22, 80 and 443 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type t3.small \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":16,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=meshcentral-01}]'

On success, the command prints a JSON document. Note the instance ID. Once the instance is running, retrieve its public address with aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

Connect and Retrieve the Administrator Credentials

Connect over SSH with the key pair you selected and the public IP address from Step 2. The SSH login user depends on the operating system of the AMI variant you launched:

AMI variant SSH login user

MeshCentral 1.2 on Ubuntu 24.04 ubuntu

The first-boot service runs before the SSH daemon becomes ready, so the credentials file is always in place when you first log in. Read the credentials file with sudo.

ssh <login-user>@<public-ip>
sudo cat /root/meshcentral-credentials.txt

The file is plain text. It contains the MeshCentral URL, the administrator username and the per-instance administrator password:

MESHCENTRAL_URL=https://<public-ip>/ MESHCENTRAL_USERNAME=admin MESHCENTRAL_PASSWORD=<generated-password>

From the same SSH session, confirm that the deployment is healthy. nginx serves an open health endpoint on port 80:

curl -fsS http://127.0.0.1/healthz

ok

An ok response confirms that nginx is fronting the application. A request to the site root over plain HTTP redirects to HTTPS:

curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://127.0.0.1/

301 https://127.0.0.1/

Then confirm that the services that make up the stack are running:

systemctl is-active meshcentral nginx meshcentral-firstboot

active active active

First Sign-in

The image ships with a per-instance self-signed certificate, so the console is encrypted from the first boot. Open a web browser and go to https://<public-ip>/.

Because the certificate is self-signed, your browser shows a certificate warning on the first visit. Accept it to proceed. A plain http://<public-ip>/ request redirects to HTTPS automatically.

The MeshCentral sign-in page is served over HTTPS behind nginx. Sign in as the administrator with the per-instance credentials.

Enter the username admin and the password from /root/meshcentral-credentials.txt, then select Log In. MeshCentral opens on the My Devices console. It is empty until you add a device group and install the agent on your first device.

The left menu offers Devices, Account, Events, Files, Users and Server. Managed devices appear in the console once the agent is installed.

Create a Device Group

MeshCentral organises devices into device groups. On the My Devices console, select click here to create a device group (or the + control).

Give the group a Name and leave the Type as Manage using a software agent. Optionally add a Description, then select OK.

The software-agent type is the right choice for ordinary Windows, macOS and Linux machines. The other type, Intel AMT, is for out-of-band management of hardware that has Intel AMT provisioned.

Install the Agent on a Device

Open the device group you just created. MeshCentral shows an Add Agent panel with a per-group installer for each platform. On the device you want to manage, download and run the installer for its operating system, or copy the one-line install command that MeshCentral provides:

On Windows, download and run the MeshCentral agent executable and approve the installation.
On Linux and macOS, paste the install command from the console. It downloads the agent and installs it as a background service.

The image uses a self-signed certificate by default, so agents must be able to trust the server. For a small trial, run the provided command on a device that can reach the instance. For any real deployment, complete Step 8 first so that the agent trusts a real certificate.

Once the agent is installed and connected, the device appears in the group with its online, connection and power state. You can then take remote-desktop control, open a terminal, browse files and run management tasks from the console.

Server Administration

As a site administrator, you have a My Server view. Open it from the server icon at the bottom of the left menu.

The view shows server statistics such as CPU load and available memory. It also shows live server state, such as the number of user accounts, device groups and agent sessions. Server actions include downloading a server backup, checking the server version and viewing the server configuration.

To add more operators, open My Users and create each account. Grant each account only the rights and device groups it needs. Open self-signup is disabled in this image, so only accounts you create here can sign in.

Use a Real Domain with a Trusted Certificate

The image serves the console over HTTPS with a per-instance self-signed certificate. That is fine for a first look, but it triggers a browser warning and agents do not trust it. For any production deployment, point a DNS name at the instance and install a trusted certificate.

The stack already runs nginx as the HTTPS terminator, so certbot can obtain and install a Let's Encrypt certificate for it. First create an A record for your domain, for example mesh.example.com, pointing at the instance's public IP address. Make sure the security group allows inbound ports 80 and 443 from the public internet, so the certificate can be issued and renewed.

Then run these commands on the instance:

sudo snap install --classic certbot
sudo ln -sf /snap/bin/certbot /usr/bin/certbot
sudo certbot --nginx -d mesh.example.com

certbot edits the nginx site to serve your domain with the trusted certificate and sets up automatic renewal.

After the certificate is installed, tell MeshCentral its public name, so the certificates it hands to agents and the links it generates use your domain. Edit /var/lib/meshcentral/config.json, set the cert value under settings to your domain name, and restart the service:

sudo sed -i 's/"aliasPort": 443,/"aliasPort": 443,\n "cert": "mesh.example.com",/' /var/lib/meshcentral/config.json
sudo systemctl restart meshcentral

Reload the console at https://mesh.example.com/. The browser warning is gone, and agents installed from the console trust the server automatically.

Backups and Maintenance

All MeshCentral state lives under /var/lib/meshcentral on the dedicated data volume. That includes the configuration, the embedded database of users, device groups and nodes, and the generated certificates.

Back it up by taking an EBS snapshot of that volume. Alternatively, use the Download server backup action in the My Server view, which produces a single archive you can store off the instance.

sudo systemctl stop meshcentral
sudo tar czf /var/tmp/meshcentral-backup-$(date +%F).tgz -C /var/lib/meshcentral .
sudo systemctl start meshcentral

Keep the operating system patched with the standard Ubuntu tooling:

sudo apt-get update && sudo apt-get -y upgrade

systemd manages the MeshCentral service and restarts it automatically after a failure or reboot. Check its status and recent logs with:

systemctl status meshcentral --no-pager journalctl -u meshcentral --no-pager | tail -n 50

Scaling and Operations

A single t3.small comfortably manages a small fleet of devices. As the number of connected agents grows, move to a larger instance type for more CPU and memory. Resize the /var/lib/meshcentral data volume as the event history and file storage grow.

Because all state is on the dedicated volume, you can also scale up by stopping the instance, detaching the volume and reattaching it to a larger instance.

For higher availability, run behind an Application Load Balancer with health checks pointed at /healthz. Terminate TLS on the load balancer, or on nginx with your own certificate, and take regular EBS snapshots of the data volume.

MeshCentral also supports an external MongoDB database for larger multi-server deployments. Consult the MeshCentral documentation and SecureAnyCloud support if you need that topology.

Support

SecureAnyCloud maintains this image. For help with deployment, domain and HTTPS configuration, agent rollout, device-group and access-control design, or storage and upgrade planning, contact SecureAnyCloud support by email or chat, available 24/7.

Include the AMI ID, the instance ID and the Region so we can help you quickly.

Deploy on AWS

Launch MeshCentral on AWS with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on AWS