How to Install Checkmk on Ubuntu 24.04 — Self-Hosted Infrastructure Monitoring

Modern infrastructure runs on a mesh of Linux servers, containers, databases, network appliances, and cloud APIs. When something goes wrong at 3 a.m., you want a monitoring system that tells you exactly which service on which host crossed which threshold — and ideally did so a few minutes before the outage actually happened. Checkmk is one of the most capable open-source monitoring platforms available, combining classic agent-based host checks with auto-discovery, business intelligence, and a modern web UI. This guide walks you through installing Checkmk Raw Edition on an Ubuntu 24.04 VPS, creating your first site, onboarding Linux agents, tuning thresholds, wiring up notifications, and fronting the whole thing with Nginx + Let's Encrypt TLS.

Prefer a pre-configured setup? Our CloudCore Professional VPS is sized exactly for a production Checkmk deployment (6 vCPU, 12 GB RAM, 100 GB NVMe). Deploy a Professional VPS now and follow this guide end to end.

Table of Contents

What is Checkmk?

Checkmk is an open-source infrastructure, application, and network monitoring platform originally forked from Nagios and now maintained by tribe29 / Checkmk GmbH. It ships in three editions: Raw (fully open source, MIT/GPL), Cloud (paid, adds cloud-native integrations and a distributed setup wizard), and Enterprise/MSP (paid, adds SLA reporting, high availability, and advanced reporting). This guide targets the Raw Edition, which is production-ready for single-site deployments monitoring hundreds to a few thousand hosts.

Checkmk's architecture centers on the Open Monitoring Distribution (OMD) — a self-contained runtime that bundles the monitoring core, a web UI, a data graphing engine, and all dependencies into per-site installations. Each site lives under /omd/sites/<site-name>/ with its own user, configuration, and lifecycle. This means a single Ubuntu host can run multiple independent Checkmk sites (useful for staging/production separation or tenant isolation) and you can start, stop, and upgrade each site independently with the omd command.

The core monitoring model is agent-based: you install a small Checkmk agent (check_mk_agent) on each Linux, Windows, or macOS host. The server polls every agent every 60 seconds by default, parses the output, and stores metrics in an RRD-based time-series store. Checks are grouped into services (CPU, memory, disk, filesystem, running processes, NTP drift, network interfaces, MySQL, Nginx, Docker containers, and several hundred more), and each service has a state: OK, WARN, CRIT, or UNKNOWN.

The killer feature is auto-discovery. When you register a host, Checkmk asks the agent what services are running and proposes the full list for monitoring. Add a new disk, mount a new filesystem, or start a new MySQL instance? A rediscovery picks it up automatically. No manual service definitions, no YAML files to edit — discovery plus rule-based thresholds cover 90% of day-to-day monitoring work.

Why Self-Host vs PRTG, SolarWinds, or Datadog?

Commercial monitoring platforms like PRTG, SolarWinds, and Datadog solve the same problems, and they solve them well — but at a cost that scales uncomfortably with your infrastructure.

• Per-host or per-metric pricing that compounds fast. Datadog's Infrastructure tier starts at ~$15/host/month, and custom metrics, APM, log management, and network performance monitoring are separate SKUs. A modest 20-host deployment with logs and APM routinely lands above $1,200/month. PRTG charges per "sensor" (each CPU core, filesystem, or interface counts), so a handful of busy servers can burn through a 500-sensor license. SolarWinds licenses per node and per module, and the Orion suite plus NPM/SAM add-ons easily exceeds $10,000 for a mid-size environment.
• Data residency and compliance. PRTG ships SaaS-only for its Hosted variant, SolarWinds has had well-publicized supply-chain incidents, and Datadog stores all of your host inventory, process lists, and log contents on US infrastructure. For EU-hosted businesses handling GDPR-regulated data — or any organization with a "no third-party observability" security policy — self-hosting is the path of least friction.
• Vendor lock-in via proprietary agents and data formats. Datadog and SolarWinds agents emit data in closed formats consumable only by their respective backends. Checkmk agents emit plain text over TCP 6556 that you can read with telnet. If you ever decide to migrate off, the data is portable.
• No metric caps or retention cliffs. Free and lower tiers of commercial tools cap metrics at 1-minute resolution for 15 days. Checkmk on your own VPS stores full resolution for as long as your disk holds (RRD rollups keep years of data in gigabytes, not terabytes).
• Unlimited custom checks. Need to monitor a proprietary internal service? Write a shell script, drop it in the agent's local directory, and it's a first-class service with graphs and notifications. No custom metric fees.

Prerequisites

Before starting, confirm you have:

• A VPS running Ubuntu 24.04 LTS with root or sudo access
• At least 4 GB of RAM (8-12 GB recommended for monitoring 50+ hosts)
• At least 40 GB of disk — Checkmk's RRD store grows steadily with the number of monitored services
• SSH access and a public IP
• A domain name pointed at the server (for Nginx + Let's Encrypt in Step 11)

Recommended Plan: CloudCore Professional

For a production Checkmk deployment monitoring up to ~200 hosts with full historical retention, we recommend the CloudCore Professional plan:

- 6 vCPU cores

- 12 GB RAM

- 100 GB NVMe SSD

- Unmetered bandwidth

- EUR 19.99/month

The 100 GB NVMe comfortably holds years of RRD data plus the Checkmk binaries and site files, while 12 GB RAM absorbs peak check execution without swapping.

Connect via SSH to begin:

ssh root@your-server-ip

Step 1: Update System Packages

Always start with a clean, patched system. Checkmk's .deb pulls in roughly 200 dependencies, and stale package indexes are the most common cause of install failures.

sudo apt update && sudo apt upgrade -y

If the kernel was updated, reboot:

sudo reboot

Install a few utilities we'll need along the way:

sudo apt install -y wget curl gnupg ca-certificates lsb-release

Step 2: Download and Install Checkmk Raw Edition

Checkmk distributes Raw Edition as a standalone .deb package from their official download server. Visit download.checkmk.com to confirm the latest version — at time of writing, the stable release is 2.3.0p20. Replace the version string below with whatever is current.

Download the .deb:

cd /tmp
wget https://download.checkmk.com/checkmk/2.3.0p20/check-mk-raw-2.3.0p20_0.noble_amd64.deb

The noble in the filename matches the Ubuntu 24.04 LTS codename. If you see a mismatch, you've grabbed the wrong build — Checkmk ships separate packages for jammy (22.04) and noble (24.04).

Install it with apt (which resolves dependencies automatically, unlike dpkg -i):

sudo apt install -y ./check-mk-raw-2.3.0p20_0.noble_amd64.deb

Expected output (abbreviated):

Selecting previously unselected package check-mk-raw-2.3.0p20.
Preparing to unpack .../check-mk-raw-2.3.0p20_0.noble_amd64.deb ...
Unpacking check-mk-raw-2.3.0p20 ...
Setting up check-mk-raw-2.3.0p20 (2.3.0p20-0.noble) ...
Creating default user of Checkmk-Version 2.3.0p20.cre.
OMD: Initializing default monitoring site...
Trying to setup default apache configuration...

Verify the installation by listing available OMD versions:

omd versions

Expected output:

2.3.0p20.cre (default)

cre means "Checkmk Raw Edition" — exactly what you want.

Step 3: Create Your First Monitoring Site

Checkmk uses the concept of a site — an isolated instance with its own user, data directory, and network ports. Pick a short, memorable site name. We'll use monitoring.

Create the site:

sudo omd create monitoring

Expected output:

Adding /opt/omd/sites/monitoring/tmp to /etc/fstab.
Creating temporary filesystem /omd/sites/monitoring/tmp...OK
Restarting Apache...OK
Created new site monitoring with version 2.3.0p20.cre.
  The site can be started with omd start monitoring.
  The default web UI is available at http://your-server/monitoring/
  The admin user for the web applications is cmkadmin with password: xxxxx-xxxxx-xxxxx
  (It can be changed with 'htpasswd -m ~/etc/htpasswd cmkadmin' as site user.)
  Please do a su - monitoring for administration of this site.

Write down the cmkadmin password. This is the only time it's displayed in plain text. If you miss it, you can always reset it:

sudo su - monitoring -c "cmk-passwd cmkadmin"

Behind the scenes, omd create has:

Step 4: Set the cmkadmin Password and Start the Site

If you want a known password (strongly recommended — store it in your password manager), set it now:

sudo su - monitoring
cmk-passwd cmkadmin

You'll be prompted for a new password twice. Exit back to your regular shell:

exit

Start the site:

sudo omd start monitoring

Expected output:

Starting agent-receiver...OK
Starting mkeventd...OK
Starting rrdcached...OK
Starting cmc...OK (not running — CRE uses nagios core)
Starting nagios...OK
Starting npcd...OK
Starting apache...OK
Starting crontab...OK
Initializing Crontab...OK

Confirm everything is up:

sudo omd status monitoring

You should see every component in the running state.

Step 5: First Login to the Web UI

Open a browser and navigate to:

http://your-server-ip/monitoring/

You'll see the Checkmk login screen. Log in with:

• Username: cmkadmin
• Password: the one you just set

• Monitor — real-time views of hosts and services, dashboards, and event console
• Customize — create your own views, reports, and dashboards
• Setup — all configuration (hosts, rules, users, notifications). Changes here are staged until you click Activate changes in the top right.

Step 6: Install the Linux Agent on Target Hosts

Checkmk can pre-package the agent .deb with your site's exact version so there's no mismatch.

On your Checkmk server, navigate to Setup → Agents → Linux. You'll see a download link for check-mk-agent_2.3.0p20-1_all.deb. Right-click, copy the URL, then on the target host you want to monitor:

wget http://your-checkmk-server/monitoring/check_mk/agents/check-mk-agent_2.3.0p20-1_all.deb
sudo apt install -y ./check-mk-agent_2.3.0p20-1_all.deb

The agent registers two systemd units:

• check-mk-agent.socket — listens on TCP port 6556
• [email protected] — spawned per-connection from the socket

sudo systemctl status check-mk-agent.socket

Test it locally:

sudo telnet localhost 6556

You should see a large plain-text blob starting with <<<check_mk>>> and section markers like <<<cpu>>>, <<<mem>>>, <<<df>>>. That's the raw data format Checkmk parses.

Open port 6556 on the target host's firewall, scoped to the monitoring server's IP:

sudo ufw allow from YOUR_CHECKMK_SERVER_IP to any port 6556 proto tcp

Repeat on every host you want to monitor.

Step 7: Register Hosts and Run Service Discovery

Back on the Checkmk web UI:

Checkmk polls the agent and returns a page of Undecided services — every discovered check on the host. Review the list, click Monitor undecided services, then click Activate changes (top right).

Within 60 seconds your dashboard lights up with CPU, memory, disk, filesystem, process, and network checks for the new host. Go to Monitor → All hosts to see the live state.

Repeat host registration for every server. For fleets of 20+ hosts, look into Setup → Hosts → Dynamic host configuration which auto-creates hosts based on cloud API inventory or DNS.

Step 8: Configure Thresholds with Rules

Checkmk's check thresholds are controlled by rules — a conditional matching system that applies parameters to selected hosts/services.

Example: raise the filesystem warning threshold from the default 80% to 90% on all database hosts.

The rule engine is evaluated top-down — more specific rules win over generic ones. Common rule categories you'll touch in the first week:

• CPU utilization — tune WARN/CRIT percentages
• Memory levels — adjust for hosts that legitimately run hot (caches, JVMs)
• Filesystems — often needs per-mount tuning
• Network interfaces — enable traffic limit warnings
• Process discovery — alert when a named process is missing

Step 9: Set Up Notifications (Email and Slack)

By default, Checkmk silently records events without notifying anyone. Wire up at least one channel before you rely on it in production.

Email notifications

Install a minimal mail transfer agent on the Checkmk server:

sudo apt install -y postfix mailutils

Choose Internet Site during postfix configuration and enter your domain.

In the Checkmk UI:

Trigger a test alert (stop a monitored service on a host, wait ~60 seconds) to confirm mail delivery.

Slack notifications

A test alert should arrive within seconds in the target Slack channel with host, service, state, and a direct link back to the Checkmk UI.

Step 10: Business Intelligence — Group Services into Business Views

Raw health metrics ("CPU on web03 is at 94%") matter less to business stakeholders than service-level availability ("Is the storefront reachable right now?"). Checkmk's Business Intelligence (BI) module lets you aggregate multiple host/service states into a single composite status.

Example: define a BI aggregation called Customer Checkout that is OK only if all of these are OK:

• web01, web02, web03 — HTTP service
• db01 — MySQL service
• redis01 — Redis service
• payments-api.example.com — HTTPS endpoint

To configure:

BI aggregations appear as top-level tiles on the dashboard and make great executive-facing status boards.

Step 11: Secure the Web UI with Nginx and TLS

The default Apache vhost on port 80 is fine for a lab but unacceptable for production. Front Checkmk with Nginx, a real TLS certificate, and optional IP allow-listing.

Install Nginx and Certbot:

sudo apt install -y nginx certbot python3-certbot-nginx

Configure the OMD site to listen on a local-only port so Nginx can proxy to it:

sudo omd config monitoring set APACHE_TCP_ADDR 127.0.0.1
sudo omd config monitoring set APACHE_TCP_PORT 5000
sudo omd restart monitoring

Create an Nginx vhost at /etc/nginx/sites-available/checkmk:

server {
    listen 80;
    server_name monitoring.yourdomain.com;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl http2;
    server_name monitoring.yourdomain.com;
    ssl_certificate     /etc/letsencrypt/live/monitoring.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/monitoring.yourdomain.com/privkey.pem;
    # Modern TLS only
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    # Security headers
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options SAMEORIGIN;
    add_header Strict-Transport-Security "max-age=31536000" always;
    client_max_body_size 32m;
    location / {
        proxy_pass http://127.0.0.1:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 300s;
    }
}

Enable the site and obtain a certificate:

sudo ln -s /etc/nginx/sites-available/checkmk /etc/nginx/sites-enabled/
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d monitoring.yourdomain.com

Certbot autoconfigures renewal via systemd timer. Confirm renewal works:

sudo certbot renew --dry-run

Browse to https://monitoring.yourdomain.com/monitoring/ — you should hit the Checkmk login over TLS with a trusted cert.

For extra safety, restrict access to your office IP only:

sudo ufw allow from 203.0.113.0/24 to any port 443 proto tcp
sudo ufw deny 443

Troubleshooting

sudo su - monitoring
tail -f var/log/web.log var/log/nagios.log

FAQ

Is Checkmk Raw really free for commercial use?

Yes. Checkmk Raw Edition is released under MIT and GPLv2 licenses. You can monitor unlimited hosts and services, use it in commercial environments, and modify the source freely. The paid Cloud and Enterprise editions add features like distributed monitoring wizards, SLA reporting, and commercial support — but Raw is functionally complete for single-site deployments up to several thousand hosts.

How does Checkmk compare to Zabbix and Prometheus?

Checkmk is agent-based with strong auto-discovery and a polished out-of-the-box experience. Install the agent, register the host, accept the discovered services — you're monitoring. Best for teams that want infrastructure visibility fast with minimal config.

Zabbix is also agent-based but more configuration-heavy. It has excellent network device monitoring via SNMP and a highly customizable trigger engine, but the learning curve is steeper.

Prometheus is pull-based, designed for cloud-native environments, and excels at high-cardinality metrics from applications instrumented with the Prometheus client libraries. Pair it with Grafana for dashboards. Best for containerized workloads and service-level metrics.

Many teams run Checkmk for infrastructure and Prometheus + Grafana for application metrics side by side.

Can I monitor Windows servers and network devices with Checkmk?

Yes. Checkmk ships agents for Windows (.msi installer), macOS, Solaris, AIX, and FreeBSD. Network devices (switches, routers, firewalls, UPS, printers) are monitored over SNMP v1/v2c/v3 — no agent required. Setup → Hosts → Add host lets you pick SNMP as the data source.

How many hosts can a single Checkmk site handle?

On the Raw Edition with a 6 vCPU / 12 GB RAM VPS, a single site comfortably monitors 200-300 hosts with ~5,000-10,000 services at 60-second resolution. Beyond that you'll want to scale vertically (more RAM) or move to the Cloud Edition which uses the CMC core (C++ rewrite of Nagios core) and handles 10,000+ hosts per site. For massively distributed estates, run multiple Raw sites and aggregate them with BI.

Where does Checkmk store its data and how do I back it up?

Everything for a site lives under /omd/sites/<sitename>/. Back up with:

sudo omd backup monitoring /backup/monitoring-$(date +%F).tar.gz

This produces a single tarball containing the configuration, user database, RRD metrics, event console state, and notification history. Restore with omd restore. Schedule this nightly via cron and sync the backup to off-site storage.

Should I also run Wazuh alongside Checkmk?

They solve different problems. Checkmk monitors availability and performance — is the service up, is the disk filling, is CPU too high. Wazuh is a security-focused SIEM and host-based intrusion detection system that monitors integrity, logs, and threats — file changes, failed logins, rootkits, CVE-vulnerable packages. A mature production setup typically runs both: Checkmk for ops, Wazuh for security.

Can I write custom checks for my own applications?

Yes, and it's easy. Drop a script into /usr/lib/check_mk_agent/local/ on the target host that prints a status line like:

0 MyAppQueue queue_depth=42 Queue is healthy

The first integer is the state (0=OK, 1=WARN, 2=CRIT, 3=UNKNOWN), then the service name, then performance data, then human text. Checkmk picks it up at the next discovery run. Full plugin docs: docs.checkmk.com/latest/en/localchecks.html.

Next Steps

Checkmk is running and monitoring your first hosts. Recommended follow-ups:

• Enable SNMP monitoring for network gear — add your switches, firewalls, and UPS with community strings or SNMPv3 credentials
• Set up distributed monitoring — if you have hosts in multiple regions, deploy additional Checkmk sites and federate them via the Setup → Distributed monitoring wizard
• Integrate with Grafana — Checkmk ships a Grafana data source so you can build unified dashboards combining Checkmk metrics with Prometheus, Loki, or MySQL data sources
• Pair with Wazuh for security coverage — availability monitoring with Checkmk plus HIDS/SIEM with Wazuh gives full ops + security visibility
• Read the official docs — docs.checkmk.com is thorough and well-maintained, covering advanced topics like LDAP auth, REST API automation, and custom MKP packages

Ready to deploy Checkmk in production?

Our CloudCore Professional plan is sized exactly for this workload — 6 vCPU, 12 GB RAM, 100 GB NVMe, unmetered bandwidth, EUR 19.99/month.

Deploy a Professional VPS now and follow this guide end to end.