Checkmate

Search the Marketplace for Checkmate on Ubuntu 24.04 and choose your VM size.

Attach a network security group (NSG) that allows TCP 22 (SSH) from your management network and TCP 80 and 443 (the dashboard) from the networks that need it. In production, front port 80 with TLS (see Step 12). Only nginx listens externally. The Node server and MongoDB are bound to loopback.

RG="checkmate-prod"; LOCATION="eastus"; VM_NAME="checkmate-01" IMAGE_URN="sac1647283583153:checkmate-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name checkmate-vnet --address-prefix 10.90.0.0/16 --subnet-name checkmate-subnet --subnet-prefix 10.90.1.0/24 az network nsg create -g "$RG" --name checkmate-nsg az network nsg rule create -g "$RG" --nsg-name checkmate-nsg --name allow-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name checkmate-nsg --name allow-web --priority 110 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 80 443 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:checkmate-ubuntu-24-04:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name checkmate-vnet --subnet checkmate-subnet --nsg checkmate-nsg --public-ip-sku Standard

ssh azureuser@<vm-ip>

MongoDB and the Checkmate Node server listen on loopback. nginx fronts the dashboard on port 80 and proxies the API.

sudo systemctl is-active mongod checkmate nginx
sudo ss -tln | grep -E ':80 |127.0.0.1:52345 |127.0.0.1:27017 ' curl -s -o /dev/null -w 'GET /api/v1/health -> HTTP %{http_code}\n' http://127.0.0.1/api/v1/health

All three services report active. MongoDB is bound to 127.0.0.1:27017, the Node server to 127.0.0.1:52345, and nginx to :80. The health endpoint returns HTTP 200 through nginx.

The image ships with no default credential. On first boot, Checkmate generates a per-VM JWT signing secret and MongoDB password. It also registers a single administrator with a random password stored in a root-only file. Read it over SSH:

sudo grep -E 'bindIp|authorization' /etc/mongod.conf
sudo stat -c '%n perms=%a owner=%U:%G' /root/checkmate-credentials.txt curl -s http://127.0.0.1/api/v1/auth/users/superadmin; echo
sudo cat /root/checkmate-credentials.txt

MongoDB is bound to loopback with authorization enabled, and the credentials file is 600 root:root. Exactly one superadmin exists, so self-registration is closed. The file gives you the URL, admin email and admin password for this VM:

CHECKMATE_URL=http://<vm-ip>/ CHECKMATE_ADMIN_EMAIL=admin@checkmate.local CHECKMATE_ADMIN_PASSWORD=<unique-per-vm-password>

Open http://<vm-ip>/ in your browser. Enter the email and password from /root/checkmate-credentials.txt and click Login.

After signing in you land on the Uptime dashboard. It summarizes how many monitors are up, down, paused or initializing. It also lists each monitor with its live status, response time and uptime percentage.

Click Create. Choose the monitor Type (HTTP(S), Ping, Docker, Port, Game, gRPC, WebSocket or DNS). Enter the URL or address to watch, give it a display name, set the check interval, and save.

Checkmate starts checking immediately. Open a monitor to see how long it has been active, its last check and last response time, and the certificate expiry for HTTPS targets. Charts show uptime and response time over your chosen window.

node -v nginx -v mongod --version | head -1
node -p "require('/opt/checkmate/client/package.json').version"

Node.js 22 runs the server, nginx fronts it, MongoDB 8.0 stores the data, and the pinned Checkmate release is 3.9.2.

All monitoring data lives in the local MongoDB under /var/lib/mongodb, which is captured into the image and carried onto every instance.

sudo du -sh /var/lib/mongodb systemctl is-enabled checkmate-firstboot.service checkmate.service apt-mark showhold

The database directory is present, the services are enabled for the next boot, and there are no held packages. The OS security baseline is intact.

nginx already fronts Checkmate on port 80 and is ready for TLS. Point a DNS record at your VM, then obtain a certificate with certbot:

sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d <your-domain> --agree-tos -m <your-email> --redirect

certbot installs the certificate, rewrites the nginx server block for TLS, and sets up automatic renewal.

If you serve the dashboard on a custom domain, set CLIENT_HOST in /etc/checkmate/checkmate.env to your https:// URL. Then run sudo systemctl restart checkmate so the server accepts requests from that origin.

• Open the product page in the AWS Marketplace and choose Continue to Subscribe, then Continue to Configuration.
• Select the software version and the Region you want to deploy in, then Continue to Launch.
• Choose an instance type. The recommended type is m5.large. You can start smaller to evaluate and scale up as your monitor count grows.
• Select your VPC, subnet and key pair. Attach a security group that allows inbound port 22 from your management network and inbound port 80 (and optionally 443) from your users.
• Launch the instance and wait for its status checks to pass.

You can also launch the AMI directly. Replace the AMI id with the one shown on the Marketplace listing for your Region. Supply your own key pair, subnet and security group ids.

aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --subnet-id subnet-0123456789abcdef0 \
  --security-group-ids sg-0123456789abcdef0 \
  --metadata-options "HttpTokens=required" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=checkmate}]'

The instance uses IMDSv2. The first-boot service reads the instance's public address from instance metadata and configures the dashboard's client host automatically.

Connect over SSH as the default login user for your operating system variant. On the Ubuntu variant that user is ubuntu.

Connecting to your instance

OS variant SSH login user

Ubuntu 24.04 LTS ubuntu

ssh -i my-key-pair.pem ubuntu@<instance-public-ip>

The administrator credentials are generated on first boot and written to a root-only file. Retrieve them with:

sudo cat /root/checkmate-credentials.txt

The file contains the dashboard URL, the administrator email and the per-instance password:

CHECKMATE_URL=http://<instance-public-ip>/ CHECKMATE_ADMIN_EMAIL=admin@checkmate.local CHECKMATE_ADMIN_PASSWORD=<your-per-instance-password>

Browse to http://<instance-public-ip>/ and sign in with the email and password from the credentials file.

The Checkmate sign-in page, served on first boot with a per-instance administrator password and self-registration closed after the first account.

You can confirm the service is healthy from the instance itself. The dashboard is served on port 80, the Node server answers a health endpoint, and requests without a valid token are rejected:

# The React sign-in page is served on port 80 (200)
curl -s -o /dev/null -w 'GET / -> HTTP %{http_code}\n' http://127.0.0.1/
# The Checkmate server health endpoint returns OK (200)
curl -s http://127.0.0.1/api/v1/health
# An unauthenticated write to the API is rejected (401)
curl -s -o /dev/null -w 'POST /api/v1/monitors (no auth) -> HTTP %{http_code}\n' \
  -X POST http://127.0.0.1/api/v1/monitors -H 'Content-Type: application/json' -d '{}'

GET / -> HTTP 200 {"status":"OK"} POST /api/v1/monitors (no auth) -> HTTP 401

From the Uptime dashboard choose Create and select the type of check to perform. Checkmate can monitor HTTP(S) endpoints, ICMP ping, Docker containers, TCP ports, game servers, gRPC services, WebSocket endpoints and DNS.

Adding a new monitor: choose an HTTP, ping, port, Docker, DNS, gRPC or WebSocket check, enter the URL or address to watch and give it a display name.

Enter the URL or IP to monitor, give it a clear display name, set the check interval, and save. Each result is recorded, so you build up an uptime percentage and a response-time history for every target.

The uptime monitors dashboard shows monitored websites and endpoints, each with its status, response-time trend and uptime percentage, plus up, down and paused counts at the top.

Click any monitor to open its detail view. It shows the current status, how long the monitor has been active, and the last check and response time. For HTTPS targets it shows the monitored certificate's expiry.

You also see uptime and downtime counts, an average response-time gauge, a response-time chart, and the log of recent checks with their status codes.

A single monitor's detail view with its status, uptime and downtime history, average response time, response-time chart, certificate expiry and recent check log.

Use Notifications to wire alerts to your channels so you are told the moment a monitor changes state. Use Incidents to review outages, and Status pages to publish a public or internal status page for your services.

Invite additional team members from Settings. Self-registration is closed after the first administrator, so new users join by invitation only.

The appliance runs three systemd services. Inspect and manage them with systemctl:

systemctl status mongod
# MongoDB 8.0, bound to loopback, data on /var/lib/mongodb
systemctl status checkmate
# the Checkmate Node.js server on 127.0.0.1:52345
systemctl status nginx
# serves the React client and reverse-proxies /api on port 80

All three run locally, and only nginx is network-facing:

sudo ss -tlnp | grep -E ':80 |:52345 |:27017 '

LISTEN 127.0.0.1:27017
# MongoDB — loopback only LISTEN 127.0.0.1:52345
# Checkmate Node server — loopback only LISTEN 0.0.0.0:80
# nginx — the only public listener

MongoDB is bound to 127.0.0.1 and is never reachable from outside the instance. The Node server is also loopback-only, reachable only through the nginx reverse proxy.

The image serves the dashboard over HTTP on port 80. Port 443 is available in your security group for you to add TLS.

To terminate HTTPS with your own certificate, place your certificate and key on the instance. Add a listen 443 ssl; server block that references them to the nginx site at /etc/nginx/sites-available/sac-checkmate, keeping the existing /api/ reverse proxy and SPA fallback. Then set CLIENT_HOST in /etc/checkmate/checkmate.env to your https:// address and restart the service:

sudo nano /etc/checkmate/checkmate.env
# set CLIENT_HOST=https://your-domain
sudo nginx -t && sudo systemctl reload nginx
sudo systemctl restart checkmate

For a public domain, a certificate from Let's Encrypt through certbot is the simplest option. Our support team can help you configure TLS termination.

All monitoring data lives in MongoDB under /var/lib/mongodb on a dedicated EBS volume. Snapshot that volume for point-in-time backups, and use mongodump for logical backups:

sudo mongodump --uri "$(sudo awk -F= '/^DB_CONNECTION_STRING=/{sub(/^DB_CONNECTION_STRING=/,"");print}' /etc/checkmate/checkmate.env)" --out /var/backups/checkmate-$(date +%F)

To upgrade the appliance's operating system packages, run sudo apt-get update && sudo apt-get upgrade. For Checkmate application upgrades, contact SecureAnyCloud support.

Start on a small instance type to evaluate, and scale up as your monitor count grows.

Because monitoring data is on its own EBS volume, you can grow storage independently of the operating system disk. You can also snapshot or migrate it without touching the application.