eNMS: a workflow builder on top of Netmiko, NAPALM and Ansible

A platform for the network engineer who is not a programmer

eNMS is described as an enterprise-grade vendor-agnostic network automation platform, and the README calls it a vendor-agnostic NMS designed for building workflow-based network automation solutions. Both halves of that phrase matter.

Vendor agnostic is the technical commitment. eNMS does not implement a protocol of its own for talking to switches and routers. It works through Netmiko and NAPALM, which means the device support is whatever those libraries support, and it inherits their coverage rather than adding to it. The topic tags on the repository list napalm, netmiko, configuration-management, infrastructure-as-code, network-automation, network-inventory and network-visualization, which is an accurate map of the surface.

Workflow-based is the product commitment. The central idea in the documentation is the service. A service is a discrete piece of automation that you run against the inventory, and any Python script with input parameters can be turned into one, with eNMS generating the form in the web UI for those parameters automatically. That single feature is what makes the platform usable by people who do not write code, because a colleague can drop a script into the repo and the interface appears by itself.

Around services sit the other capabilities: configuration management with backup, change and rollback; validation of device state with Netmiko and NAPALM; an Ansible service for storing and running playbooks; a REST service for calls with variable URL and payload; workflows that combine services graphically; scheduling by time or CRON; and event-driven automation triggered from the REST API.

The target user is a network operations team that has outgrown a pile of cron jobs and shell scripts but does not want to build a full custom platform.

Inventory and visualization as the front door

Everything else in the platform depends on the inventory, so that is where the documentation starts.

Your network topology can be created manually or imported from an external Source of Truth, with OpenNMS, LibreNMS and Netbox all named. The README makes the point that the external systems are treated as sources of truth rather than as things to keep in sync, which is the right relationship: you already run a monitoring system, and duplicating device lists by hand is how inventories rot. Once created, the topology is displayed in a sortable and searchable table, and a dashboard provides a graphical overview with dynamic charts.

Visualization comes in two flavors. There is a geographical view that places each device at its GPS coordinates on a world map, using either Google Maps or Open Street Maps. There is also a logical network builder, where topology diagrams are drawn from the devices and links in the inventory, with labels added for clarity.

The geographical view is the less obvious of the two and the more interesting for some teams. Placing devices on a map is not decoration when your estate spans sites, because it turns a list of hostnames into something you can reason about spatially, and it makes a missing site obvious at a glance. The Open Street Map option also means the map does not require a Google account or an API key for a self-hosted install.

The demo instance is public, at demo.enms.io, with direct links to the inventory table, the dashboard, the geographical view, the network builder, the workflow builder, the configuration search table, the configuration history table and the task calendar. Clicking through those is the fastest way to understand what the platform looks like before you install anything.

Trying eNMS before you install it

The documentation does not give a pip install or a docker run line in the README, so there is no install command to copy here. The paths the project points you at are the ReadTheDocs site at enms.readthedocs.io, the setup directory inside the repository, and a live demo at demo.enms.io.

The demo is the fastest first use. It exposes the actual interface rather than a screenshot, and the README links specific views: the inventory table at demo.enms.io/table/device, the dashboard, the geographical view, the network builder, the workflow builder, the configuration search and configuration history tables, and the task calendar. A sensible first pass is to look at the inventory table and the workflow builder, because those two show the two halves of the product, the fleet you are describing and the actions you are defining against it.

For a real first use in your own environment, the sequence the documentation implies is short. Create the inventory by importing from your existing source of truth, or by hand for a handful of devices. Write a Python script that does one thing against a device, with the parameters you would want a colleague to fill in, and register it as a service so the form is generated. Combine it with a second service in the workflow builder. Then schedule the workflow, and check it in the calendar before you let it near a production device.

The last point is not a documentation instruction but it follows from how the platform is built. The REST API and the CLI can trigger a service, so anything you wire up can be invoked from outside the UI, and the configuration management service can change and roll back configurations. Getting the workflow visible in the calendar before it is reachable from an API is a cheap way to avoid a surprise.

Configuration management with Git as the history

The configuration management service is the part of eNMS with the most familiar provenance. The README states plainly that eNMS can be used as a device configuration backup tool, like Oxidized or Rancid, and then lists what it does beyond that baseline.

It polls network devices and stores the latest configuration in the database. It stores any operational data retrievable from the device CLI, with show version and get facts given as examples. It can search for any text or regular expression across all configurations, which is the feature that turns a backup tool into an investigative tool: finding every device with a particular ACL line or a particular NTP server is a query rather than a script.

Configurations can be downloaded to a local text file, and the REST API can return a specified device's configuration. All configurations can be exported to a remote Git repository, for example Gitlab, and the interface can show git-style differences between various revisions of a configuration.

That last combination is the interesting design decision. A database holds the current state for fast search, and Git holds the history for real diffing, which is a much better diffing engine than anything a database table would give you. The cost is that the Git export is a separate mechanism with its own configuration, and a team that expects a single authoritative store has to think about which is which.

The comparison with Oxidized and Rancid is the useful one. Those tools exist to answer a single question, what does this device's configuration look like, and they do it well. eNMS adds rollback, change management, validation and workflow automation on top of the same poll and store operation, at the price of a much larger dependency footprint.

Services, workflows and scheduling

The automation model has three layers and each one is worth understanding separately.

A service is one task. eNMS ships default services leveraging libraries such as ansible, requests, netmiko and napalm to perform simple automation tasks, and any Python script can be turned into a service, with a form generated automatically for its input parameters. That automatic form generation is the mechanism that makes the platform extensible without a plugin API: the script's signature becomes the UI.

A workflow combines services. The workflow builder is graphical, and the demo instance links directly to it. This is where the platform earns its keep, because a change window usually means several steps in sequence, and being able to see the sequence, reorder it, and add a step without touching code is what a team with mixed skill levels needs.

Scheduling adds time. Services and workflows can be run directly and immediately from the UI, or scheduled to run later, or periodically by defining a frequency or a CRON expression. All scheduled tasks are displayed in a calendar, which matters more than it sounds: a platform where scheduled jobs disappear into a queue is a platform nobody trusts. The calendar view lets you see what is going to touch the network and when.

Event-driven automation closes the loop. Services can be executed programmatically through the REST API, and eNMS has both a REST API and a CLI interface that can be used to create, update and delete any type of object, and to trigger execution of a service. That is the difference between a tool you use and a tool you can plug into a ticketing system or a monitoring alert.

The open core and Enterprise Edition split, feature by feature

This is the part to read carefully, because the README is explicit that eNMS ships in two versions: an Open Core version, which is this repository, and an Enterprise Edition with advanced features for production deployments.

What the open core includes is workflow automation, configuration management, network visualization and the REST API. That is the entire automation core, and it is enough to build the workflows described above.

What it does not include is the operational layer. Multi-user authentication is absent, which means the open core has no login page and no per-user identity. Role-based access control is absent. The advanced scheduler, TACACS+ and LDAP and Duo 2FA integration, service import and export, the migration mechanism, change revert and audit trail, the administration panel, production scripts and tools, and professional support are all Enterprise Edition features.

Read that list as a description of what a production network tool needs. Multi-user authentication and RBAC are the reason a device automation platform is dangerous to run without: the people who can push configuration changes to production switches are the people who can break production. An audit trail is what a compliance regime asks for, and a migration mechanism is what an upgrade across versions requires. Without them, the open core is a tool for a single trusted operator on a lab network, and the Enterprise Edition is what an organisation actually deploys.

The Enterprise Edition is described as ideal for organisations deploying eNMS in production where security, compliance, multi-tenancy and professional support are critical. The open core repository is GPL-3.0, so the code you can read and modify is copyleft, and the paid edition is a commercial offering layered on top.

What the repository tells you about the build

The repository layout shows a Python web application with a small JavaScript toolchain. At the top level there is an app.py entry point, a gunicorn.py, a setup directory with the install steps, a build directory, an eNMS package directory, a terminal directory, a docs directory, a files directory and a metadata.json.

The JavaScript side is minimal and clearly a linting and formatting concern rather than a build system. The package.json for eNMS at version 5.3 declares just two scripts, prettier for formatting the eNMS and setup directories using a config in build/linting, and eslint for linting, with prettier and eslint as dev dependencies and a single runtime dependency on lint. The engines field pins node 20.18.0.

Two details in that metadata are worth flagging. The repository URL recorded in package.json is https://github.com/afourmy/eNMS, while this repository lives under the eNMS-automation organisation, so the upstream history and the current home are not the same URL. And the version numbers do not line up between the two package manifests in a way that would surprise you if you are comparing the JavaScript metadata with the Python distribution, since the version in package.json is only the JavaScript metadata for this project.

The documentation is on ReadTheDocs, with the structure visible in the links the README uses: inventory with network creation and network visualization, automation with services, workflows and scheduling, and configuration management. A demo instance runs at demo.enms.io.

On maintenance, the repository is not archived and the last push was on 2026-05-08, which is also the date of the v5.3 release, titled Version 5.3: JSON Migration and Performance Improvements. Before that the release history goes back to v4.2 in April 2022 and v4 in October 2021, so v5.3 looks like the first release in a while and the JSON migration in its title suggests a change in how data is stored between versions. That migration concern is precisely what the Enterprise Edition migration mechanism exists to address.

Editorial conclusion

Adopt eNMS if you run a mixed vendor network and want a browser driven workflow layer over Netmiko, NAPALM, Ansible and plain Python scripts, especially if you want configuration history in Git. Do not adopt the open core version for a production deployment that needs multi-user authentication, role-based access control, an audit trail or LDAP, because the documentation puts all of those in the Enterprise Edition. Verify first that your device models are handled by the Netmiko and NAPALM versions eNMS expects, that the demo instance at demo.enms.io behaves like the version you will install, and that the split between the open core and the Enterprise Edition matches what your compliance requirements need.

Frequently asked questions

Official sources

1. eNMS-automation/eNMS on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases