NTC Templates, a corpus of TextFSM parsers for network device show commands

Why parsing CLI output is a solved problem here

Network automation has a recurring obstacle. A device tells you about its state through a command, and the command returns text formatted for a human. The automation tool needs that text as fields. Writing a regular expression per platform, per command, per software version is how automation codebases become unmaintainable, and the failures are quiet because a regex that stops matching does not error, it returns nothing. NTC Templates is a corpus of TextFSM templates that solve this for a wide range of vendors, and TextFSM itself is described as a tool to help make parsing cli commands more manageable. The approach is declarative. A template describes the shape of the output and the fields to extract, so the parsing logic lives in a data file that is reviewed and versioned rather than in code that is scattered through a tool. The repository is a Python project maintained by Network to Code, and the templates are packaged so they ship with the library.

The CliTable wrapper, and what it adds to raw templates

The templates are the substance, but the wrapper is what makes them usable, and the packaging shows exactly what it is. The poetry project is named ntc_templates at version 9.3.0, described as TextFSM Templates for Network Devices and a Python wrapper for TextFSM's CliTable, with a single runtime dependency on textfsm at 1.1.0 or newer and Python 3.10 or above. The templates themselves are shipped as package data, with the include list naming the templates directory and the index file inside it, and the LICENSE and README alongside. So the distribution is a small library plus a data payload, and the data payload is versioned with the library. That last point is the one to internalise: you are not just pip installing a parser, you are pip installing a specific snapshot of thousands of templates that correspond to specific vendor software versions, and the version of the package is the version of the corpus.

The documentation is split by audience

The documentation site is organised into three guides, which tells you the project has three distinct kinds of user and has thought about each. The User Guide covers the library overview, using the library and getting started, and it has its own frequently asked questions page that the README points at first for anyone with a question. The Administrator Guide covers how to install, configure, upgrade or uninstall the library, plus a release notes and changelog section, which is the reference to check before you move between versions. The Developer Guide covers extending the library, a code reference and the contribution guide, for people writing new templates. The separation matters practically: a team running the tool in production cares about the administrator guide, and a team adding support for a new platform cares about the developer guide, and the two have very different content. The project also points to the Network to Code Slack for questions, with a channel named networktocode.

The documentation site builds locally with invoke and mkdocs

The docs are built with mkdocs, and the project documents how to run them locally rather than only hosting them. The markdown source lives in the docs folder of the repository, and the README says that for simple edits a markdown capable editor is sufficient: clone the repository and edit away. When you want the fully generated site, you build it with mkdocs, and a container hosting the docs is started using the invoke commands, with the details in the Development Environment Guide. The site is then reachable on localhost:8001, and as your changes are saved the live docs reload automatically. The repository has a tasks.py at the root, which is where the invoke tasks live, a mkdocs.yml, and a .readthedocs.yml for the hosted build. The tree also shows a Dockerfile, a cli.py, a tests/ directory, and a ntc_templates/ package directory holding the templates and the index.

http://localhost:8001

The toolchain, and the quality gates around it

The development dependencies are a good picture of what the project considers important. On the linting side there is flake8 with a .flake8 config, pydocstyle with a .pydocstyle.ini, pylint, black with a line length of 120 targeting py310, yamllint with .yamllint and .yamllint.yml, bandit with a .bandit.yml, and ruamel.yaml for YAML handling. On the testing side there is pytest, coverage and a test extra that pulls in pytest, so a consumer can install the test dependencies. On the docs side there is the full mkdocs material stack, including mkdocs-material, mkdocstrings, mkdocstrings-python, griffe, mkdocs-version-annotations and sphinx-rtd-theme. There is a vale.ini for prose linting on the documentation, which is a detail that says the docs are treated as a product. The development status classifier is 4 - Beta, and the project is at version 9.3.0 with releases v9.3.0 from 2026-09-14, v9.2.0 from 2026-07-08 and v9.1.0 from 2026-04-01, so roughly every two months.

The container image, and how it installs

The Dockerfile shows the container build in full, and it is worth reading because it reveals the assumptions the project makes about where the library runs. The base image is a slim Python image whose version comes from a build argument, so the Python version is chosen by the caller rather than pinned in the file. The apt layer installs git, curl, libxml2, libmariadb3, openssl, build-essential, pkg-config, media-types and mailcap, with a hadolint ignore directive covering the apt install step, and then clears the apt lists. Pip and wheel are upgraded once, and Poetry is installed if it is not already present, with its bin directory added to the path. The dependency install is split for layer caching, with pyproject.toml, poetry.lock and README.md copied first and the project installed with virtualenvs.create false, then the rest of the source copied and the project installed again. That is a container built for reproducible installs, not for development.

The limits of a template corpus

There is a structural limit that no amount of template coverage removes, and it is worth stating before anyone builds a pipeline on this. A TextFSM template encodes the output of a command as it appears in a particular software version on a particular platform. When the vendor changes the output, the template stops matching, and a TextFSM template that does not match does not raise an error, it returns no records or partial ones. So the corpus reduces the work enormously and does not remove the maintenance. The second limit is scope: the templates cover show commands, so anything a device only exposes through an API, or through output with a timestamp and address prefix that no template accounts for, is still your problem. The third is the coordination point. The project is a shared corpus maintained by one community, so a template for your exact platform and command either exists or it does not, and if it does not, contributing one is a piece of work with a review process. The project does acknowledge the wider landscape, pointing to its Awesome Network Automation list for cases where one tool does not fit.

Licence, release cadence and what to check

Two facts need reconciling before you vendor this. The licence identifier in the repository metadata is a custom one that GitHub cannot classify, which points to the LICENSE file at the root, while the packaging metadata in pyproject declares the licence as Apache-2.0. Those two statements should agree, and the LICENSE file is the document to read. The release cadence is steady, with a minor version roughly every two months across the visible history, and the last push to the repository was on 2026-10-11 with the repository not archived. The three things to verify before a project depends on it are simple and concrete. Check that a template exists for the exact command and platform you need, because the corpus is organised per platform and per command rather than per problem. Check the version correspondence, since a template written for one release of a vendor's software may not match another. And check the licence question above. A fourth practical check is the behaviour on a mismatch, so that a broken parse in your pipeline fails loudly rather than producing an empty dataset that nobody notices for a week.

Editorial conclusion

Adopt NTC Templates if you are building network automation and need to parse vendor CLI output into structured records, because writing those parsers by hand is the single largest source of brittle automation code. Skip it if your devices expose a modern API and you can use structured output instead of scraping console text. Verify three things before you depend on it: that a template exists for the exact command you need, since the corpus is organised per platform and per command rather than per problem, and a missing template is a hard stop; that the version of the templates matches the software version on your devices, since command output changes between releases; and the licence terms in the LICENSE file, because the project metadata records a licence that GitHub cannot classify while the packaging metadata names Apache-2.0, and those two should be reconciled before you vendor the templates into a commercial product.

Frequently asked questions

Official sources

1. Issues
2. networktocode/ntc-templates on GitHub
3. Project website
4. README
5. Releases