Nagios Core vs Checkmk: when each platform fits your estate
If your estate is stable and modest, Nagios Core is still a sound choice. Nagios Core is a GPL-2.0 engine that runs host, service and network checks, and it suits a team whose monitored systems change slowly, whose staff are comfortable editing text configuration and writing or maintaining plugins, and who do not need a web layer for configuration. Nagios.org describes Core as free with manual text-based configuration and a basic web interface, and the Nagios Plugins project supplies the check programs it runs. If that describes your team, staying is a legitimate decision, and the 4.5.x maintenance releases (4.5.14 was published on August 5, 2026) keep the engine current.
Checkmk fits when the estate is growing or changing often. Checkmk's Community edition is built on the Nagios core, but it adds rule-based configuration, auto-discovery and agents, which reduce the hand-editing that Nagios requires for each new host and service. Checkmk's own migration guide says it can take over large parts of an existing Nagios configuration, but that this usually means more effort, and that large environments may need a Livestatus-based approach and good Linux knowledge. Push-mode agents and automatic host registration are Ultimate features, so confirm in the editions page which capabilities your team actually needs before you assume they are included.
Three factors decide the choice. First, host count against the roughly 100-host scope Checkmk gives Community: if you are near or above that figure, or expect to grow past it, price Pro or Ultimate from the editions page, which lists Pro from 190 euros per month and Ultimate from 275 euros per month, both billed annually. Second, whether you need Pro features such as distributed monitoring and advanced reporting, or Ultimate features such as automatic host registration and multi-tenancy. Third, how much existing configuration must be rebuilt. Count your host objects, service templates and notification rules, then ask a migration partner or Checkmk to estimate the rebuild in writing before you commit.
Nagios Core vs Checkmk by scenario: which platform is the better fit
This table maps common Nagios Core and Checkmk situations to the platform that usually fits better, with the condition that makes each advantage matter. Read each row against your own host count, staffing and plugin dependencies, then confirm the open items with Checkmk and your own environment before deciding.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Small, stable estate with a working Nagios configuration | Nagios Core | Staying put avoids a migration project. Checkmk Community is scoped for small infrastructures, so the case for moving is weaker unless growth or new requirements are coming. |
| Estate expected to pass about 100 hosts | Checkmk (commercial edition) | Checkmk describes Community as scalable to about 100 hosts. Beyond that, the Pro or Ultimate editions are the path, and the paid editions use the Checkmk Micro Core by default. Confirm the paid edition scope and pricing with Checkmk. |
| Team without spare Linux capacity | Checkmk | Auto-discovery and rule-based setup reduce hand-edited text files. Checkmk's migration guide notes that taking over large parts of a Nagios configuration usually means more effort, so budget migration time before choosing. |
| Estate built around custom Nagios plugins | Nagios Core, or Checkmk after a plugin review | Nagios Core runs any plugin that fits its plugin interface, and Nagios Plugins supplies the check programs. Checkmk can run many familiar Nagios concepts, but confirm each custom plugin's behavior in a test site before committing. |
| Team needing push-mode agents or automatic host registration | Checkmk Ultimate | Push-mode agents and automatic host registration are Ultimate features per the Checkmk setup guide. Nagios Core has no equivalent built in, and Community does not include these features. |
| Team needing distributed monitoring or 8x5 support | Checkmk Pro or Ultimate | Pro adds distributed monitoring and 8x5 support according to the Checkmk editions page. Nagios Core relies on its own configuration and third-party support arrangements, so confirm what Nagios Enterprises offers for your needs. |
| Team that wants to keep the GPL-2.0 engine and its CGI interface | Nagios Core | Nagios Core is GPL v2 with a basic web interface. Checkmk Community is also GPL-2.0 open source, but its commercial editions move new sites to the Micro Core, so check which parts of your workflow depend on the CGI interface. |
How Nagios Core text configuration differs from Checkmk rules and agents
Nagios Core and Checkmk Community share a lineage, but they hand operators different daily work. The cards below separate the engine, the configuration model, the web interface, plugins, the agent layer and the commercial core, and note who maintains each piece.
Nagios Core C engine and text objects
Nagios Core is a host, service and network monitoring program written in C under GPL v2, and its objects are defined in plain text files that operators edit by hand. Day-to-day work means editing those files, validating them and reloading the daemon after each change. Nagios Core releases are maintained by the Nagios Core project, and the nagioscore GitHub releases page lists 4.5.14 as the August 5, 2026 release. Check who in your team owns those text files and how changes are reviewed.
Nagios Core CGI web interface
Nagios Core ships an optional CGI web interface, and Nagios.org describes it as basic. It shows host and service state but does not manage the configuration itself, so configuration changes still go through the text files. Ask whether your operators rely on the CGI views for daily triage or need dashboards, reporting and access control, which Nagios.org attributes to the commercial Nagios XI product rather than Core.
Plugin execution model
Nagios Core runs check programs from the separate Nagios Plugins project, and the community has built thousands of them. Each check is a command bound to a host or service in a text definition, so reuse of existing plugins is straightforward. Checkmk Community also runs Nagios-style checks, but many hosts are instead monitored through Checkmk's own agents and checks. Inventory your current plugins and confirm which ones Checkmk supports natively before migration.
Checkmk Community on the Nagios core
Checkmk Community is free, 100 percent open-source software that incorporates Nagios as its core, and Checkmk's own docs state that Community is built on that Nagios core. Checkmk GmbH maintains the Checkmk layer on top, including its rule-based setup, while the Nagios engine underneath continues to run checks and notifications. The editions page describes Community as suited to small infrastructures and scalable up to about 100 hosts, so confirm your host count against that scope before choosing it.
Rule-based setup and agents
Checkmk replaces hand-written object definitions with rules that apply to groups of hosts, and it uses agents on monitored systems. Automatic host registration and push-mode agents are Ultimate features, so Community operators work with the pull-style setup described in Checkmk's setup guide. The shift changes the skill set: teams need to understand rule precedence and agent deployment rather than object inheritance in text files. Test how your existing host groups and escalations map onto Checkmk rules before committing.
Checkmk Micro Core in paid editions
The commercial Pro and Ultimate editions create new sites with the Checkmk Micro Core (CMC) by default, and they keep the Nagios core only as an optional core for migration. This means the engine a paid customer runs is not the Nagios code path that Community uses. Checkmk's docs report benchmark figures for the CMC, but those are vendor measurements, so validate performance against your own host and service counts. Ask Checkmk which core a new site uses and whether an existing Nagios-based site would need to move.
Nagios Core against Checkmk on the capabilities that decide the choice
This table compares Nagios Core and Checkmk on the capabilities that usually decide a migration. Read each row against your host count, agent requirements and support needs. Where the published sources are silent, the cell tells you what to confirm with the vendor.
| Capability | Nagios Core | Checkmk |
|---|---|---|
| License | GPL-2.0 for the Core engine, per the NagiosEnterprises README | Source repository is GPL-2.0, and the Community edition is free and open source |
| Configuration model | Manual text-based configuration files, per nagios.org | Rule-based setup, which replaces most hand-edited text files for new hosts and services |
| Auto-discovery | Not described in the sources. Confirm whether any discovery tooling is in scope for your setup | Positioned as a replacement for manual text-file edits, per Checkmk's Nagios alternative page |
| Agents | No agent layer described. Checks run through plugins that Nagios Core invokes | Agents are installed on monitored hosts. Push-mode agents and automatic host registration are limited to paid editions |
| Host scope in the free edition | No host limit is published in the sources. Confirm your sizing with the project and its forums | Community is positioned for small infrastructures and scales easily to about 100 hosts |
| Core engine | The Nagios Core C engine itself | Community runs on the Nagios core. Commercial editions use the Checkmk Micro Core by default and keep Nagios as an optional migration core |
| Plugin reuse | Works with thousands of community plugins from the Nagios Plugins project | Confirm with Checkmk whether your existing Nagios check commands run unchanged in its setup |
| Distributed monitoring | Not confirmed in the sources for Core. Confirm the approach with the vendor or the Nagios XI product | Distributed monitoring is listed as a Pro feature and above, per the editions page |
| Paid editions and pricing | Nagios XI is the commercial product built on the same engine. Confirm current pricing with Nagios Enterprises | Pro from 190 euros per month and Ultimate from 275 euros per month, both billed annually, per the editions page |
| Support options | Community forums and documentation on nagios.org. Paid professional support comes with Nagios XI | Community is free. Pro adds 8x5 support, per the editions page |
What each license and edition covers, and what is paid for
Nagios Core is a host, service and network monitoring program written in C and released under the GNU General Public License version 2. Nagios.org describes it as free under GPL v2, with manual text-based configuration and a basic web interface that works with thousands of community-developed plugins. There is no license fee for the engine, so the recurring cost is staff time spent writing, reviewing and maintaining configuration files, plugins and notification logic.
- License: GPL-2.0 for the Core engine, with Nagios Plugins as a separate project that supplies the check programs.
- Interface: an optional CGI web interface, which the Core README describes as optional rather than a full management console.
- Commercial product: Nagios XI is built on the same Core engine and adds configuration, reporting, access control, advanced dashboards and professional support. Existing Nagios Core configuration imports into it.
- Engine features: parent host hierarchies that separate down from unreachable hosts, notifications and event handlers.
- Recurring cost: community support and internal staff time, unless you buy Nagios XI or a support contract from Nagios Enterprises.
Confirm with Nagios Enterprises which support and licensing terms apply to your use before assuming Core covers your audit or support needs.
Checkmk Community is the free, self-hosted edition. Checkmk's setup guide describes it as 100 percent open-source software that incorporates Nagios as its core, and the Checkmk source repository on GitHub is licensed under GPL-2.0. The Checkmk editions page describes Community as free and open source monitoring for small infrastructures, easily scalable up to about 100 hosts. Cost is therefore the infrastructure to run it and the staff who operate it, not a subscription.
- License: GPL-2.0 source, with no subscription fee listed for the Community edition.
- Core: Checkmk Community is built on the Nagios core, so it keeps the Nagios processing model.
- Scope: the editions page positions Community for small infrastructures, up to about 100 hosts.
- Installation: Linux packages for Red Hat-based systems, SUSE Linux Enterprise Server, Debian and Ubuntu, or Docker container images.
- Missing from Community: virtual and physical appliances are available only for commercial editions, and push-mode agents and automatic host registration are Ultimate features.
Before relying on the 100-host guidance, confirm the host count and service load of your estate with Checkmk, since the editions page gives this as a scalability description rather than a hard limit.
Checkmk Pro is the first paid tier. The Checkmk editions page lists Pro from 190 euros per month, billed annually. It adds advanced analytics and reporting, automation, distributed monitoring and 8x5 support. Synthetic Monitoring is available as an add-on for Pro and Ultimate only. Pro also moves new sites to the Checkmk Micro Core by default, while Nagios stays available as an optional core for migration.
- Price source: the Checkmk editions page, from 190 euros per month, billed annually.
- Added features: advanced analytics and reporting, automation, distributed monitoring and 8x5 support.
- Add-on: Synthetic Monitoring, only with Pro or Ultimate.
- Core change: new sites use the Checkmk Micro Core (CMC) by default, and the Nagios core stays only as an optional migration core.
- Recurring cost: the annual subscription, plus any add-ons and the staff time to operate the distributed setup.
Ask Checkmk how the 8x5 support window matches your incident obligations, and confirm the subscription scope, such as the number of hosts or services, before you sign.
Checkmk Ultimate is the highest self-hosted tier. The Checkmk editions page lists it from 275 euros per month, billed annually. It adds full-stack observability, multi-tenancy, advanced security compliance and automated mass rollouts. The Checkmk setup guide places push-mode agents and automatic host registration in Ultimate, which matters for large or fast-changing fleets. Ultimate also includes the Checkmk Micro Core by default.
- Price source: the Checkmk editions page, from 275 euros per month, billed annually.
- Added features: full-stack observability, multi-tenancy, advanced security compliance and automated mass rollouts.
- Agent features: push-mode agents and automatic host registration, per the Checkmk setup guide.
- Appliances: virtual and physical appliances are available only for commercial editions.
- Recurring cost: the annual subscription, plus the staff time to run multi-tenant and mass rollout workflows.
Check whether push-mode agents and automatic registration are needed for your fleet, because those features are what separate Ultimate from Pro for many estates.
What drives the running cost of each platform
The running cost of either platform is mostly people time, with licences a smaller and more visible line item. For Nagios Core, the biggest recurring cost is the staff hours spent writing and maintaining the text object files that define hosts, services, contacts and commands, plus keeping the check plugins from Nagios Plugins current on every monitored system. For Checkmk Community, the same engineering time goes into rule sets, host tags and agent rollouts instead of text files, and the software itself carries no subscription fee. Infrastructure for the monitoring servers is paid to whoever hosts them, whether that is your own virtual machines or a cloud account. Checkmk's Community edition is described as suited to small infrastructures and scalable to about 100 hosts, so the first cost question is whether your estate stays inside that scope or will need a commercial edition.
Subscription fees arrive only when you choose a paid tier. The Checkmk editions page lists Pro from 190 euros per month and Ultimate from 275 euros per month, both billed annually, and a Cloud edition at 240 euros per month billed yearly and capped at 50,000 services. Nagios XI is the commercial product built on the same Core engine, and its pricing is not in the supplied facts, so ask Nagios Enterprises for it directly. Note that push-mode agents and automatic host registration are Checkmk Ultimate features, so a fleet that depends on them prices differently from one that does not. One-time migration work is separate from these recurring costs: converting existing Nagios configuration, rebuilding alerts and retiring the old server are project costs, and Checkmk's own migration guide notes that taking over large parts of a Nagios configuration usually means more effort. Outside help is also a mix of one-time and recurring spend, and a fixed-scope project should be quoted separately from any ongoing support retainer.
When you request a quote, ask each vendor or partner to itemize hosts and services in scope, the number of monitoring servers and distributed sites, the edition and billing term, and whether migration, plugin rewrites and training are included. Ask who maintains custom checks after handover and at what rate. Ask Nagios Enterprises and Checkmk to confirm which features your team needs fall under which tier, and ask for the renewal and price-change terms in writing. Confirm any cost you plan around, because the supplied facts give list prices and scope limits, not your total cost of ownership.
Moving an existing Nagios estate to Checkmk, step by step
This sequence moves a Nagios estate to Checkmk without a cutover on day one, so each host, check and alert is proven on the new server before Nagios is switched off.
Inventory the existing Nagios configuration
Your team exports and reads every host, service, contact, time period and command definition in the current Nagios text files, and groups them by what they monitor and who receives their alerts. Identify custom plugins, event handlers and any CGI pages people rely on, because these are the items that will need rebuilding rather than copying. The step is done when you have a written list of hosts, checks and notification paths, with each custom item marked as transfer or rebuild. Ask Checkmk and your migration partner to review the list before you build anything.
Build a separate Checkmk server
Install a new Checkmk server alongside Nagios on its own host, using one of the supported Linux package families or a Docker image for the Community edition, and keep Nagios running untouched. Checkmk's migration guide describes this as building a separate server rather than converting the existing one in place. The step is done when the site starts, the web interface loads and you can log in as the administrator. Confirm your chosen edition and its host limits before you go further, since the Community edition is scoped to about 100 hosts.
Add hosts and install agents
Register the hosts from your inventory in Checkmk and install the Checkmk agent on each Linux or Windows system, so host data is collected through the agent instead of only through network checks. Plugins that already run as Nagios checks can often be carried over as Checkmk checks, but each one should be confirmed on a real host and its output compared with the Nagios result. Start with a small group, such as one site or one application stack. The step is done when every migrated host reports the same up or down state and the same key metrics in both systems.
Recreate rules, users and roles
Replace the Nagios service definitions and host groups with Checkmk rule sets, which apply settings to hosts and services by condition instead of by individual definition. Create user accounts and map the roles you need, noting that role behavior should be checked against the edition you run. Rebuild notification logic in Checkmk's notification rules, including any escalation or time-based routing that Nagios handled with custom contacts and commands. The step is done when every rule your inventory marked as rebuild has a Checkmk equivalent that a named engineer has reviewed.
Validate notifications in parallel
Run both systems at the same time, with Nagios still sending alerts for production hosts and Checkmk sending alerts to a test channel or a subset of contacts. Trigger controlled failures on test hosts, such as stopping a service or filling a disk in a test environment, and compare when each system detects the problem and what each notification contains. Record every difference and fix it before moving on. The step is done when each critical alert path has fired correctly in Checkmk at least once and the on-call team agrees the message content is usable.
Plan the Livestatus route for large estates
If your estate is large or depends on Nagios-specific integrations, Checkmk's migration guide describes a Livestatus-based approach that can take over more of the existing Nagios configuration directly. The guide notes this usually means more effort and that it needs good Linux knowledge, so assign an engineer who can work with sockets, the file system and the Nagios configuration directly. The step is done when you have a tested decision on which hosts use rebuilt rules and which, if any, go through this route, and the effort estimate for that route comes from a written scope rather than an assumption.
Cut over and retire Nagios
Once parallel alerts have matched expectations for the agreed period, move production notifications to Checkmk, disable Nagios notifications, and then stop the Nagios service. Keep the Nagios configuration files and a read-only copy of the host inventory for audit and rollback reference. The step is done when no production host is still monitored only by Nagios, Checkmk is the sole source of alerts, and the retired configuration is archived where your change records can find it.
Where Nagios-to-Checkmk projects usually run long
Projects usually run long on the Nagios side before they run long on the Checkmk side. On Nagios Core, the effort is keeping the text configuration and the plugins you depend on working and documented. Hosts, services, commands and contacts live in object files that someone edits by hand, and checks are often custom scripts from the Nagios Plugins project or in-house programs with no owner. Before any migration starts, inventory every custom check, record what it reads and who maintains it, and confirm each one still runs on the Nagios Core release you are on, which the nagioscore releases page shows is actively published in 2026. Undocumented custom checks are the most common reason a migration stalls, because nobody can say whether a check is still needed.
On the Checkmk side, the work is installation on a supported Linux distribution or as a Docker image, then rule design, agent rollout and one decision that shapes everything after it: whether new sites use the Checkmk Micro Core or the Nagios core. The commercial editions create sites with the Micro Core by default, and the Nagios core is kept only as an optional core for migration. Rules replace many of the object definitions, so notification rules tied to old contact and object files must be rebuilt, not copied, and each one should be tested against a real alert. Agent deployment is where mixed estates slow down, because push-mode agents and automatic host registration are Ultimate features, so Community teams roll out agents by their own tooling. Confirm which edition you need before you design the rules.
Parallel running is the planning item most teams underestimate. Keep Nagios sending alerts until each Checkmk notification path has been verified, and compare both systems for the same hosts over a full cycle of maintenance windows and on-call rotations. Ask your implementation partner to write the cutover criteria before work starts, including how alert duplicates are suppressed during overlap and who signs off each host group. Checkmk's migration guide notes that taking over large parts of an existing Nagios configuration usually means more effort, and that large environments may need a Livestatus-based approach that calls for good Linux knowledge. Confirm the skills and the scope of that work in writing before the project is scheduled.
Questions buyers ask before moving from Nagios Core to Checkmk
What does moving from Nagios Core to Checkmk cost in effort, and what drives it?
The effort depends on how much of the current estate is hand-written text configuration, how many hosts and services must be recreated, and how much custom logic sits in plugins, event handlers and notification rules. Checkmk's migration guide says it can take over large parts of an existing Nagios configuration directly, but that this usually means more effort, so plan for review rather than a straight copy. Software and labor are separate costs. Checkmk Community is free and open source, while the Pro edition lists 190 euros per month, billed annually, according to the Checkmk editions page. Labor is usually the larger line, whether it comes from your own staff or from a DeployOpen engagement. DeployOpen's engagements are fixed-scope and agreed in writing before work starts. Ask any quote to list host count, check types, notification paths, integrations, parallel-run period and cutover approach.
Can an existing Nagios configuration be imported into Checkmk directly?
Partly, and only after review. Checkmk's migration guide says it can take over large parts of an existing Nagios configuration directly, but that this usually means more effort than building the setup fresh. Plain host and service definitions usually map with the least work. Custom plugins, event handlers, hand-tuned contact logic and CGI-based workflows need manual checking. For large environments, the guide describes a Livestatus-based approach that requires good Linux knowledge. Checkmk Community runs on the Nagios core, so the engine behaves familiarly, but the rule-based setup and agents replace much of the text-file workflow. Run a pilot on a representative subset of hosts before estimating the full move, and compare alert behavior during a parallel run.
What skills does the internal team need for a Nagios to Checkmk move?
The team needs Linux administration skills, since the migration guide describes building a separate Checkmk server, installing it from Linux packages or Docker images, and then adding hosts and agents. Familiarity with Nagios concepts helps, because Checkmk supports many of them. Someone must also own the inventory of existing checks and document what each one is for. Notification and on-call owners should review users and alerts before cutover. Agent rollout is a recurring task: push-mode agents and automatic host registration are features of the top paid edition, so on Community you manage agent deployment yourselves. Decide early who will own Checkmk rules, change control and upgrades after the move, since that ownership is ongoing work.
Can our team migrate from Nagios to Checkmk without outside help?
A small estate with Linux skills and protected time can often migrate in-house. Checkmk's guide walks through moving a small Nagios environment step by step, which makes that path realistic for simple setups. Larger estates with many custom plugins, unusual notification logic or strict change windows usually benefit from outside help. Check four things before deciding: whether a named owner has time, whether a documented list of checks exists to test against, whether you can run both systems in parallel, and whether the team has the Linux depth the large-environment approach needs. DeployOpen works to a written scope and can plan and implement the move, or support your team's own work. Request a quote that states what is in and out of scope.
How does the roughly 100-host Community scope affect the decision?
Checkmk's editions page describes Community as free and open source monitoring for small infrastructures, easily scalable up to about 100 hosts. If your estate is well under that and will stay there, Community may be the no-license target, and the decision becomes mostly about effort. If you are near or growing past that size, price the paid options. The editions page lists Pro at 190 euros per month and the top paid edition at 275 euros per month, both billed annually, and the Cloud edition at 240 euros per month billed yearly, capped at 50,000 services. Pro adds distributed monitoring and automation, which matters for multi-site estates. Confirm current scaling limits with Checkmk before committing, because the figure is guidance, not a hard cap.
Is Nagios Core still a viable choice for monitoring in 2026?
Yes, for teams with stable checks, a small change rate, and plugins they rely on. Nagios Core is GPL v2 licensed, and release 4.5.14 was published on August 5, 2026, after 4.5.13 on May 28, 2026, so the project is still maintained. Nagios.org describes Core as free, with manual text-based configuration, a basic web interface and support for thousands of community plugins. The cost of staying is ongoing manual work: hand-edited files, a basic interface and no built-in auto-discovery. Nagios XI is the commercial product built on the same engine, adding configuration tools, reporting, access control and professional support. Move when the cost of manual upkeep grows faster than the cost of migration, such as when host counts rise or changes become frequent.
How DeployOpen helps choose, implement or migrate monitoring
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For Nagios Core vs Checkmk, we start by confirming which monitoring path fits your estate, then work from a written scope agreed before any work begins.
How we scope
- Inventory existing Nagios Core hosts, services, plugins, contacts and notification rules before choosing a target
- Agree in writing which Nagios configuration is migrated, rebuilt or retired
- Confirm the Checkmk edition, host count and agent or push-mode needs before quoting
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing
How we build
- Stand up the chosen Checkmk edition in your own cloud, data center or air-gapped network
- Rebuild checks, rules and notifications in Checkmk's rule-based model rather than copying text files
- Reuse existing Nagios plugins where the Checkmk edition supports them, and test each one
- Run parallel monitoring against the current Nagios estate until alert behavior is verified
How we hand over
- Document the rule model, host onboarding steps and alert routing for your operations team
- Deliver a cutover plan and rollback steps for retiring the Nagios Core server
- Walk administrators through backup, upgrade and edition-specific operating tasks
- Provide evidence of configuration and test results for your own audit or compliance records
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer
- Review Checkmk patch releases and plan upgrades against your change windows
- Revisit host counts and edition fit when the estate grows past the Community scope
- Confirm support terms, response expectations and escalation paths in the written agreement
