Nornir has been around for eight years, and has reached an interesting point in its life.
The project now sees roughly 100,000 PyPI downloads a month. People run it across hundreds or thousands of devices. And it has continued growing despite relatively little active investment in the project over the past few years.
When OpsMill took on stewardship of Nornir in June, we wanted to preserve what made the project successful: its small core, plugin architecture, pure Python approach, and ease of debugging.
But there are also capabilities the community has been asking for and changes in infrastructure automation that Nornir needs to accommodate.
So we’ve published the first Nornir roadmap under our stewardship. It includes seven proposals, and we’re sharing them before the designs are finalized because we want the community involved in deciding what comes next.
I recently presented an early version of this roadmap at CHNUG #4 in Switzerland. Here’s the full talk if you’d like to watch it.
The Nornir roadmap adds capabilities without breaking existing code
Our priority is to move Nornir forward without forcing existing users to change what already works.
There are three rules behind everything we’re proposing.
- The roadmap will be built with the community. Each major proposal has its own GitHub discussion, and none of the designs should be considered final yet.
- Nornir’s architecture stays the same. The core remains small and focused on loading inventory and running tasks concurrently. Where we need new capabilities, our preference is for the core to provide the protocol, entry point, and default while implementations remain plugins.
- Any changes are additive. We don’t plan to change existing public signatures, protocols, defaults, or entry points. Existing code should continue to work, and our goal is for the current test suite to pass without modification.
That’s why we’re calling the next release Nornir 3.7 rather than 4.0. A major-version bump would imply breaking changes and a migration for existing users, and we specifically want to avoid that.
As I said at CHNUG, our aim is to “keep everything that people love about the project.”
Seven proposals define the near-term Nornir roadmap
The roadmap currently contains seven proposals. Some address limitations people have run into for years. Others prepare Nornir for the way infrastructure automation is being built today.
1. Add an async runner
Python’s async ecosystem has matured considerably since Nornir was created in 2017. That matters because much of network automation is I/O bound. We spend a lot of time waiting for devices, APIs, and other remote systems.
Today, putting nr.run() inside an async service can block the event loop. Async connection libraries also have nowhere to plug into Nornir’s execution model.
The proposal is to add an opt-in asyncio runner and an async execution path such as await nr.arun().
The existing threaded runner isn’t going anywhere. This gives users another execution option when they’re building async applications or using async transports.
Async runner proposal on GitHub: Issue #1855
2. Add async inventory
Async support also needs to extend beyond the runner.
Inventories increasingly retrieve data from HTTP or GraphQL APIs. Infrahub, NetBox, and Nautobot are all examples of sources of truth where an inventory plugin may spend much of its time waiting on remote requests.
The proposal introduces an optional async inventory protocol so those plugins can use async clients without forcing existing inventory plugins to change.
Async inventory proposal on GitHub: Issue #1087
3. Add async processors
Processors have the same problem.
A processor that sends a webhook, writes to a database, or performs another I/O operation can block other work when it runs inside an async execution path.
An optional async processor protocol would give plugin developers a native way to handle those operations while leaving the existing processor interface intact. Together, these first three proposals give async support a path through the Nornir stack instead of adding it to one part of the framework and leaving the rest blocking.
Async inventory proposal on GitHub: Issue #1090
4. Give runners more control over long-running work
Nornir’s current runner model makes it difficult to monitor or control work before the entire run finishes.
Consider a software upgrade across hundreds of devices. You probably want to know how hosts are progressing before the last device finishes.
We want runners to support partial results so applications can report progress as hosts complete. The proposal also explores timeouts, cancellation, and detached execution. Those capabilities become particularly useful when Nornir sits behind an API or another orchestrator. The caller could submit work, follow its progress, stop it when necessary, or reconnect to a run later instead of holding one process open until every device finishes.
Runner enhancements proposal on GitHub: Issue #1086
5. Make multi-vendor automation easier with operations
Operations is probably the biggest new abstraction we’re proposing.
Today, running the same logical action across multiple vendors often means writing the vendor dispatch yourself. If your inventory contains EOS, NX-OS, and Junos devices, for example, your code has to determine which implementation applies to each device and then reconcile the results.
Operations would introduce a typed, vendor-agnostic contract for an action, with separate implementations for individual platforms or connection plugins.
You could define a get_config operation with a known input and output. One package might provide the operation definition, while separate packages provide implementations for EOS, NX-OS, or Junos. When you run get_config against a mixed inventory, Nornir would select the appropriate implementation for each device.
The proposal also uses typed Pydantic inputs and outputs, allowing Nornir to validate an operation before contacting a device.
Normal Nornir tasks remain available. Operations give you another option when you need stronger contracts and a consistent abstraction across vendors.
I think operations could also become important as AI agents take on more orchestration work.
During the CHNUG Q&A, one attendee raised a problem his team is already dealing with: LLMs are non-deterministic, but production network operations need predictable behavior. His team has been using Nornir to provide a deterministic interface between an agent and the network.
Operations could make that pattern stronger.
Instead of giving an agent broad access to devices and letting it determine which commands to execute, you could expose a catalog of pre-defined operations. Each operation would have validated inputs and known implementations for the vendors in your environment.
An agent could then choose from capabilities you’ve already defined and tested. We’re still early in thinking through this model. But I believe a predictable execution layer becomes more valuable as agents and general-purpose orchestrators take on more of the orchestration above it.
Operations proposal on GitHub: Issue #1089
6. Make Nornir’s documentation and plugins easier to navigate
Nornir’s distributed plugin ecosystem makes it harder than it should be to find the right plugin and documentation.
The core is intentionally small. In practice, you build with Nornir by combining it with connection, inventory, task, runner, and processor plugins maintained across many different projects.
That flexibility is valuable, but it means the documentation is distributed too.
We want to improve Nornir’s documentation with better search, clearer tutorials, how-to guides, reference material, and a better way to discover plugins and understand their maintenance status.
We heard a good example of why this matters during the CHNUG Q&A. One attendee described choosing Ansible over Nornir for a project partly because Ansible Galaxy made the modules and documentation he needed easier to find in one place. That’s exactly the kind of friction we need to address.
We haven’t decided whether the right answer is a shared entry point, a plugin catalog that links to independently maintained documentation, or something else. Whatever we build needs to improve discovery without taking ownership away from the people who maintain those plugins.
Documentation refresh proposal on GitHub: Issue #1088
7. Make the project easier to develop with coding agents
The final proposal concerns how we develop Nornir itself.
We’re exploring repository-level guidance such as AGENTS.md, shared agent skills and rules, and spec-driven development workflows for larger changes.
I care particularly about the last part.
There’s a big difference between prompting a coding agent to produce code and giving it a specification, developing a plan, breaking that plan into tasks, and validating the implementation against the original spec.
We’ve been investing heavily in spec-driven development at OpsMill. For a framework that other people depend on, I think writing down the specification before generating the implementation gives both humans and agents a much stronger basis for reviewing changes.
None of this means contributors need to use AI. It doesn’t change the Nornir package users install either. The goal is to give maintainers and contributors better tools for developing the project.
Agent readiness proposal on GitHub: Issue #1084
The timeline to Nornir 3.7
The seven proposals describe where we think Nornir should go. They don’t represent finished APIs—because the best time to tell us an interface is wrong is before people start depending on it.
For roughly the next four to six weeks, we’ll be discussing and refining the designs with the community. We expect alpha releases to appear in parallel as implementations become available. Some of these ideas need working code before we can evaluate them properly.
Once the APIs have converged, we’ll move toward beta and freeze the specifications. If testing goes well, the current goal is a stable Nornir 3.7 release roughly four to six weeks later.
That makes the next few weeks particularly important.
How to contribute your feedback
Direct feedback is much more useful to us than polite agreement.
If you use Nornir, read the proposals that affect your environment and tell us what we’ve missed. If an API feels awkward, say so. If we’re solving the wrong problem, challenge the premise. If you maintain a Nornir plugin, tell us where a proposal could create compatibility problems.
Once alpha releases become available, try them against real automation.
Nornir will remain open source and community-driven. The role of OpsMill as steward is to invest in the project and coordinate the core while preserving the architecture and ecosystem that have grown around it.
The roadmap we’ve outlined on GitHub is our first substantial step in that direction. Now we need you—the people who actually use Nornir—to help determine what makes it into 3.7.
In addition to commenting on the issues in GitHub, I also invite you to join the conversation in the #Nornir channel in the OpsMill Discord community.
