Checkmk Cloud vs self-hosted Checkmk

Checkmk Cloud removes server operations but caps monitoring at 50,000 services. Self-hosted editions keep data and control in your infrastructure and add the work of running the monitoring server.

On this page

When Checkmk Cloud or self-hosted Checkmk fits your team

Choose Checkmk Cloud when you want the vendor to operate the monitoring server and your estate stays under the edition's cap of 50,000 services. Choose a self-hosted edition when data location rules, growth beyond that cap, or the need for Ultimate features means your team must run the server. The Checkmk editions page lists the Cloud edition at 240 euros per month billed yearly. The self-hosted options are Community, Pro and Ultimate, and the decision rests on who operates the server and where monitoring data sits, not on the monthly fee alone. Start with a service count, not a host count. The cap applies to services, and a single host can carry many. Pull the number of services from your current monitoring or from a trial installation, then add expected growth over the contract period. Next, ask the vendor in writing where Cloud monitoring data is stored and processed, which regions are available, and how the data processing terms apply to your sector. If your regulator, customer contracts or internal policy require data to stay in your own facilities or a named jurisdiction, treat that as a hard gate before you compare prices. Confirm these answers with Checkmk directly, because your compliance obligations are yours to verify.

The self-hosted path makes sense for teams that already run Linux servers and can own patching, backups and upgrades. Community is free and open source, but the editions page describes it as suited to small infrastructures, scalable to about 100 hosts. Pro is listed at 190 euros per month and Ultimate at 275 euros per month, both billed annually, and those fees come with the licence rather than the staff time. Installation is available as Linux packages for Red Hat-based systems, SUSE Linux Enterprise Server, Debian and Ubuntu, or as Docker container images. Push-mode agents and automatic host registration are Ultimate features, so confirm whether the Cloud edition offers them before you assume parity. Your own staff, or a partner you pay under a written scope, will carry the installation, the site upgrades and the restore tests.

Checkmk Cloud vs self-hosted Checkmk: features, limits and prices side by side

This table sets Checkmk's SaaS Cloud edition against self-hosted Community, Pro and Ultimate on price, billing, limits, core, installation and support. Read each row against your host count, service count and data residency rules, and treat cells marked for confirmation as questions to put to Checkmk before you decide.

FactorCheckmk CloudSelf-hosted CommunitySelf-hosted Pro and Ultimate
Published price240 euros per month, billed yearlyFree and open sourcePro from 190 euros per month; Ultimate from 275 euros per month, both billed annually
Billing termYearly billing at the published monthly rateNo license fee; your own staff and infrastructure carry the costAnnual billing at the published monthly rate
Service or host limitCapped at 50,000 servicesEasily scalable up to about 100 hosts, per the editions pageNo service cap stated in the supplied facts; confirm sizing limits with Checkmk
Editions and add-onsCloud edition only; confirm which Pro and Ultimate features are includedCommunity features onlyPro adds analytics, automation, distributed monitoring and 8x5 support; Ultimate adds multi-tenancy, push agents and mass rollouts
Synthetic Monitoring add-onConfirm availability with CheckmkNot availableAvailable only with Pro and Ultimate
CoreConfirm which core Checkmk runs for Cloud sitesNagios coreCheckmk Micro Core by default; Nagios core kept only as an optional migration core
Installation optionsHosted by Checkmk; you do not install or patch the serverLinux packages for Red Hat-based systems, SUSE, Debian, Ubuntu, or Docker imagesLinux packages or Docker images; virtual and physical appliances for commercial editions
Support level and hoursConfirm support hours and response terms with CheckmkCommunity support, no vendor support tier in the supplied factsPro includes 8x5 support; confirm Ultimate support terms with Checkmk
Data locationConfirm hosting region and data residency with CheckmkStays wherever you host the serverStays wherever you host the server

Who controls the data and the access in each model

Checkmk Cloud and self-hosted Checkmk differ most in who holds the monitoring server, the credentials and the logs. The cards below cover what you control in each model and what you must obtain from Checkmk before you accept the Cloud edition.

Where the monitoring data lives

In the self-hosted editions, you decide the location: your own cloud account, data center or network, and the backups that follow it. With Checkmk Cloud, the vendor operates the service, so you must ask in which region the monitoring data is stored, whether backups leave that region, and which sub-processors touch it. Get those answers in writing before you send host names, IP ranges or service output to a hosted service.

Administrative access to the server

A self-hosted site gives your own administrators root and site access, and you decide who holds those credentials and how they are rotated. In the Cloud edition, the vendor's staff operate the platform, so ask which vendor roles can reach customer sites, how that access is approved, and whether you can review it. Write down who on your side can open a support session.

Network path and agent connections

Self-hosted monitoring keeps the collection path inside your network, with firewall rules you write and inspect. A Cloud deployment requires agents or relays to reach an external endpoint, which changes your egress rules and may need proxies in restricted zones. Map every port and direction with your network team before deciding, and confirm which traffic is encrypted end to end.

Monitoring data exposure

Service output, process names, configuration and alert text can reveal internal architecture even when no credentials are stored. Self-hosting lets you limit what leaves your perimeter and who can view dashboards. For the Cloud edition, ask what metadata the vendor collects, how long it is kept and whether it is used for product analytics or support, and confirm this against the contract.

Compliance documents to request

Checkmk does not hold a certification that this comparison relies on. Ask Checkmk for its current security documentation, data processing terms, sub-processor list and any third-party audit reports it is willing to share under NDA. An attestation, if one exists, is issued by an independent auditor, and you should read its scope and period before counting it toward your own controls.

Audit trail you must keep

Whichever model you pick, your team must hold evidence of who changed rules, accessed hosts and altered notification settings. Self-hosted, you export and retain the site's logs and configuration history in your own systems. In the Cloud edition, confirm how long the vendor retains audit logs, whether you can export them on request, and how quickly they are produced during an incident or assessment.

What the published prices cover and what they leave out

The published prices are subscription fees, and they are the only line in this comparison that Checkmk bills directly. The Checkmk editions page lists Pro at 190 euros per month and Ultimate at 275 euros per month, both billed annually, and the Cloud edition at 240 euros per month billed yearly, capped at 50,000 services. Community is free to use and carries no subscription fee. Each subscription recurs for as long as you keep it, so the figure to budget is the annual commitment multiplied across the term you choose. Confirm with Checkmk whether the listed prices include VAT, currency conversion, or any minimum term, because the page does not settle those questions for you.

Self-hosting moves costs that the subscription does not show. With Pro, Ultimate or Community, you pay for the server or cloud compute that runs the monitoring site, the storage that holds its history, and the staff time to install, patch and upgrade it. You also own backups and restore tests, and you must monitor the monitoring server itself, since a silent failure of the collector hides every other outage. These costs are largely one-time for setup and recurring for operations, and they are usually paid from an existing infrastructure or staff budget, so they rarely appear on the same invoice as the license. With the Cloud edition, Checkmk operates the platform, which shifts the hosting and upkeep cost into the subscription, but it does not remove the work of defining hosts, rules and alerting on your side.

Several drivers raise total cost in either model. Host and service growth increases both the subscription tier you need and the size of the server you run, and the Cloud cap of 50,000 services is a hard ceiling to plan against. Distributed sites add servers, network paths and synchronization work. The number of administrators affects both license scope and the training and review effort per person. Before signing, ask for a written quote that states the edition, the service count, the billing term, the support level, and each add-on, including Synthetic Monitoring, which the editions page limits to Pro and Ultimate. Ask Checkmk to confirm whether that quote covers future service growth or requires a tier change first.

How the work splits across Community, commercial self-hosted and Cloud

With Community, your team owns the full monitoring server. You install Checkmk from a Linux package for a Red Hat-based system, SUSE Linux Enterprise Server, Debian or Ubuntu, or run it from a Docker container image, following the setup guide. The edition is free and open source, so the cost is the staff time and infrastructure you put into it, not a subscription.

  • Server install and patching: Your team installs, patches and hardens the host or container platform and applies Checkmk updates.
  • Sites and agents: You create sites, deploy agents and register hosts yourself, because push-mode agents and automatic host registration are Ultimate features.
  • Backups and capacity: You set the backup schedule, test restores and size the server. Community is aimed at small infrastructures, scaling to about 100 hosts.
  • Upgrades: You plan, test and perform every upgrade, including any move from the Nagios core to the Checkmk Micro Core.
  • Appliances: Virtual and physical appliances are not offered for Community, so the operating system layer is always yours.

Confirm in writing with Checkmk what vendor support, if any, is available for Community before you rely on it for production monitoring.

What your team runs in each hosting model

This table lists the operating tasks that sit with your team in self-hosted Checkmk and the points to confirm for Checkmk Cloud. Read it as a checklist for your staffing plan: each self-hosted row is work you own, and each Cloud cell marks what you must confirm in writing with Checkmk before you rely on it.

Operating taskSelf-hosted CheckmkCheckmk Cloud
Server installationYour team installs Checkmk from Linux packages or Docker images, and virtual or physical appliances are available only for commercial editions.Checkmk operates the monitoring server. Confirm with Checkmk what installation or site setup, if any, falls to your team.
Operating system and patchingYour team patches the host OS and the Checkmk site, and chooses the package or image version.Confirm with Checkmk who patches the underlying platform and how maintenance windows are scheduled.
Backups and restoreYour team designs, runs and tests backups of the site configuration and monitoring data.Confirm with Checkmk what is backed up, how often, retention periods and how your team requests a restore.
Capacity planning for services and checksYour team sizes the server. Community is positioned for small infrastructures, up to about 100 hosts, while the Cloud edition is capped at 50,000 services.Your team tracks service count against the 50,000 service cap. Confirm with Checkmk how the cap is metered and what happens when it is exceeded.
Agent rolloutYour team deploys agents and, for push-mode agents and automatic host registration, uses Ultimate.Confirm with Checkmk which agent and registration methods are supported from the Cloud site and how agents reach it.
Distributed sitesYour team builds and runs remote sites, which is a Pro and Ultimate capability.Confirm with Checkmk whether distributed monitoring is available in the Cloud edition and how remote networks connect.
Upgrades between patch and minor releasesYour team plans each upgrade, for example moving between patch releases such as 2.5.0 and 2.5.0p15, and tests it before rollout.Confirm with Checkmk how and when platform updates are applied and whether you can defer them.
Incident response on the monitoring serverYour team responds to outages of the monitoring server itself, including access to logs and the monitoring host.Confirm with Checkmk its support hours, escalation path and the response it commits to for platform incidents.
Access reviewsYour team manages user accounts, roles and reviews of who can change monitoring rules.Confirm with Checkmk which user and role controls you can administer yourself and what audit logs you receive.

Which features and add-ons change the decision

Feature availability is the first thing to pin down, because several capabilities that matter for a monitoring rollout sit behind specific self-hosted editions. Synthetic Monitoring is an add-on available only with Checkmk Pro and Ultimate, according to the Checkmk editions page, so a team that expects to run external checks should confirm whether the Cloud edition includes that add-on or sells it separately before comparing invoices. Push-mode agents and automatic host registration are Ultimate features per the Checkmk setup guide, and the editions page places multi-tenancy and full-stack observability in Ultimate as well. If your model depends on several business units sharing one monitoring server with separate views, or on agents that push data outward from hosts you cannot reach inbound, those items decide the edition, not the hosting model.

The Checkmk Micro Core (CMC) is context for scale, not a feature you choose separately. The Checkmk docs say the commercial editions create new sites with the CMC by default, while Community runs on the Nagios core. In the vendor's benchmarks, the CMC executed more than 600,000 checks per minute on a desktop Core i7 and loaded a configuration of 20,000 hosts and 600,000 services in about half a second. Benchmarks are not your workload. Ask the vendor for the test conditions and then size against your own check intervals, check types and distributed site layout, and ask which core the Cloud service runs on so you can compare its behavior with a self-hosted site.

Before purchase, confirm the Cloud feature set capability by capability instead of assuming parity with Pro or Ultimate. Make a list of the features your team relies on, including Synthetic Monitoring, push agents, automatic registration, multi-tenancy, distributed monitoring, reporting and support hours, and ask the vendor in writing which of them the 240 euros per month Cloud edition includes, which are add-ons and which are unavailable. Note that the 50,000-service cap applies to the Cloud edition only. If a required capability is missing from the Cloud tier, that gap changes the decision toward self-hosting regardless of price.

How to move between Checkmk Cloud and a self-hosted server

This sequence moves monitoring from one Checkmk environment to the other without losing coverage, so that each host and service is verified in the new site before the old one stops sending notifications. The output is a documented cutover with a retirement record for the Cloud or self-hosted environment you leave.

  1. Inventory hosts and services against the cap

    The monitoring lead exports the current host list and service count from the existing site and compares the total with the 50,000-service cap that applies to the Cloud edition. Record hosts, services, custom checks, notification rules and any dependencies on API calls or scripts. Ask Checkmk in writing how configuration and historical data can be exported or moved, and what the Cloud exit terms are. This step is done when you hold a signed-off inventory that shows whether the target fits within the cap or needs a different edition.

  2. Confirm target edition and install method

    The platform owner decides between self-hosted Community, Pro or Ultimate and checks the published editions page for the features each one needs, such as distributed monitoring, push-mode agents or multi-tenancy. Push-mode agents and automatic host registration are Ultimate features, so confirm these before assuming they carry over. Choose an install path from the supported options: Linux packages for Red Hat-based systems, SUSE Linux Enterprise Server, Debian or Ubuntu, or Docker images for Community and commercial editions. This step is done when the edition and install method are written into the change record.

  3. Build the target site and roll out agents

    Your infrastructure team installs the new site on infrastructure you control, then recreates the host groups, rules and checks from the inventory. Commercial editions create new sites with the Checkmk Micro Core by default, so confirm whether any legacy Nagios core behavior needs to be carried over. Agents are deployed to a small pilot group first, and each agent is confirmed reporting in the new site. This step is done when the pilot hosts show current data and the rollout plan covers the remaining hosts.

  4. Run both systems in parallel

    The monitoring team keeps the Cloud environment and the new self-hosted site active at the same time and compares check results, state changes and alert timing for the same hosts. Differences in thresholds, check parameters or notification timing are documented and fixed in the new site. Notifications stay routed through the old environment during this window so that no alert is lost. This step is done when the team signs off that results match for the agreed set of critical hosts and services.

  5. Cut over host registration and notifications

    The operations lead moves agent registration and notification routing to the new site, one host group at a time, and confirms that test alerts reach the on-call channels. Old agents are pointed to the new site or removed from the old one, depending on the agreed order. Each cutover batch is logged with the time, the owner and the rollback step. This step is done when all in-scope hosts report to the new site and a test alert from each group has been received and acknowledged.

  6. Retire the old environment after retention

    Once the cutover is stable, the compliance lead confirms which monitoring data, alert history and configuration must be retained and for how long under your own policies and any applicable regulations. The data is exported in the form Checkmk confirms it can provide, and the Cloud subscription is ended under the exit terms you obtained in writing. Access for former users is removed and the retirement is recorded. This step is done when the retention checklist is complete, the export is verified, and the old environment is formally closed.

Questions buyers ask before choosing Checkmk Cloud or self-hosting

What does the total cost difference between Checkmk Cloud and self-hosting depend on?

The total cost depends on how many hosts and services you monitor, which edition you need, and what your own staff spend on running the server. The Checkmk editions page lists the Cloud edition at 240 euros per month billed yearly, capped at 50,000 services, while Pro is 190 euros and the higher-priced edition is 275 euros per month, both billed annually. Community is free software. Self-hosting adds recurring costs you carry yourself: virtual machine or hardware, operating system support, backups, patching, upgrades and the staff hours they consume. Ask any quote to separate one-time setup from recurring subscription and labor, and to state which features and support hours each price includes. Confirm that the Cloud price covers every feature you need before comparing.

Can a small team run a self-hosted Checkmk server on its own?

A small team with Linux administration skills can usually run a Community server, but the work is ongoing rather than a one-time install. Checkmk installs from Linux packages for Red Hat-based systems, SUSE Linux Enterprise Server, Debian and Ubuntu, or as Docker container images for Community and commercial editions, according to the Checkmk setup guide. Virtual and physical appliances are available only for commercial editions. Your team would own the operating system, storage, backups, monitoring of the monitoring server, certificate management and version upgrades. If nobody has time for that on-call work, the Cloud edition moves the server burden to Checkmk GmbH. Decide based on who will answer a failed upgrade at 2 a.m.

How long does a migration from Checkmk Cloud to self-hosting take?

The sources supplied for this page do not give a migration duration, so treat any number you hear as unverified until it is written into a scope. The time depends on the number of hosts and services, how many custom rules, dashboards, notification paths and integrations must be rebuilt, how agents are redeployed, and how many teams need access during cutover. Ask for a written plan that lists each workstream, the acceptance tests for alerts and reports, the rollback steps and the data you will keep. Ask Checkmk GmbH and any implementation partner to state their assumptions about host count and agent rollout, so you can compare plans on the same basis.

What skills does a team need to install and upgrade self-hosted Checkmk?

Your team needs Linux administration, package management, and enough monitoring knowledge to verify that checks, notifications and sites behave after each change. Upgrades matter because Checkmk ships patch releases on a steady cadence: version 2.5.0 was tagged on April 24, 2026, and patch release 2.5.0p15 was tagged on September 30, 2026, according to the Checkmk GitHub tags. Know which core your site runs. The commercial editions create new sites with the Checkmk Micro Core by default, while Community uses the Nagios core, which commercial editions keep only as an optional migration core. Plan a test environment and a documented rollback before each upgrade.

Can a team move from Checkmk Cloud to self-hosted Checkmk later?

Yes, a move in either direction is possible in principle, but the supplied sources do not describe the export or migration tooling, so confirm the exact path with Checkmk before you commit. Plan for the parts that are hard to reverse: agent configuration on every monitored host, notification endpoints, access accounts, historical data retention and any integrations that point at a specific server address. Ask whether historical metrics can move with the configuration and whether your current edition can run the same rules on your own server. Write a cutover checklist, and test it on a subset of hosts before moving the full estate.

Is Checkmk Community enough for about 100 hosts?

Community can cover about 100 hosts, because the editions page describes it as free and open source monitoring for small infrastructures, easily scalable up to about 100 hosts. Beyond that size, or if you need distributed monitoring, you should price Pro, which the editions page lists at 190 euros per month billed annually and which adds advanced analytics and reporting, automation, distributed monitoring and 8x5 support. Community is built on the Nagios core, so check whether the features you rely on, such as reporting or automation, are available there before you deploy. Confirm the support options for Community in writing, since the supplied facts do not describe them.

When is an outside consultant or implementation partner worth the cost?

A consultant is worth paying for when your team lacks the capacity or skills to build, harden and run the server while keeping normal operations going. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen also prepares evidence for compliance assessments but does not issue audit reports or certifications. Confirm in writing whether any proposed scope covers Checkmk specifically before assuming it does.

How DeployOpen scopes and runs a self-hosted Checkmk deployment

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Checkmk, that means we help teams decide whether a self-hosted site fits their network and data rules, then build and hand over the monitoring server they choose.

How we scope

  • Written scope lists the Checkmk edition, the number of hosts and services, and the sites and locations to be monitored.
  • We record where monitoring data must stay and which network zones the server can reach.
  • Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.

How we build

  • We install Checkmk on the Linux distribution your team already supports, using the packages or container images in scope.
  • We configure distributed monitoring, agents and notification paths to match the agreed service count and alert routing.
  • We test failover, backup restore and alert delivery against the written acceptance criteria before sign-off.

How we hand over

  • You receive documentation of the site layout, configuration, backup routine and upgrade steps in your environment.
  • Your operators are walked through daily tasks, such as adding hosts, reviewing alerts and applying patch releases.
  • Compliance evidence, such as access logs and change records, is collected in a form your auditors can review.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers after handover.
  • Retainer scope covers patching to new Checkmk releases, which we confirm against the vendor's tag history before applying.
  • Ask for the support hours, response channels and upgrade policy in writing as part of any quote.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.