rConfig - Templates

Community connection templates for rConfig V8 Core and Pro.

_{Badge counts are scoped to vendor directories. The repository total is higher, including _base and pro-features.}

This is not a list of supported vendors

The directories here are the templates people have contributed so far. They are a starting point, not the boundary of what rConfig works with.

rConfig connects to networking hardware, IoT and OT devices, servers, appliances and anything else that will accept a session or hand over a file. If a device presents a CLI over SSH or telnet, a template can drive it. If it does not, rConfig Pro can run a script or accept an inbound file push instead.

If your vendor is not listed, that is not a limitation, it is a gap waiting to be filled.

• Copy _base/base.yml and adapt it. Most devices need only the prompts, the paging command and the enable mode setting changed. docs/CONTRIBUTING.md walks through it
• Look for a device with a similar CLI. Anything Cisco-like is usually a short edit away
• Ask for help: open an issue or contact us through the rConfig community. Tell us the vendor, the model and how you reach it today, and we will help you get a template working

Templates that come back from that process are the ones that grow this library, so please contribute yours once it works.

Quick start

1. Find your vendor directory, or copy _base/base.yml if your vendor is not here yet.
2. Import the template into rConfig, then assign it to the device.
3. Attach your retrieval commands to the device in rConfig Command Groups.

That third step matters, because the split is not obvious: a template handles the connection, Command Groups handle the commands. The template says how to log in, get past the banner, enter enable mode and turn paging off. It does not say show running-config. If you are looking for where the commands live, they are Command Groups, attached to the device, not the template.

Documentation

Document	What it covers
docs/TEMPLATES.md	The legend. Every key, what it means, what values it takes, which protocols read it
docs/ORDER-OF-OPERATIONS.md	When each key fires during a session, per protocol, plus debugging by stage
docs/CONTRIBUTING.md	Naming, headers, content rules and how to submit
docs/EDITIONS.md	Which template capabilities work on Core and which need Pro
docs/MIGRATION.md	Old path to new path for the 2026 restructure
docs/noninteractive-ssh.md	The SSH non-interactive shell mode

Repository layout

_base/            Starter template to copy when adding a new vendor
<vendor>/         One directory per vendor, holding its templates and a README
pro-features/     Pro-only material: sie/, ssh-private-key/, xftp/
docs/             The legend, order of operations, contributing guide, migration map
scripts/          Header tooling and the template validator
.github/          Issue forms and the validation workflow

Pro-only material lives under pro-features/: the Script Integration Engine templates and example scripts, the SSH private key template, and the xFTP inbound-only template.

Branches

main is the default branch. Work lands on dev and is merged to main from there.

master is kept as a mirror of main. It carries no unique work and nothing should be branched from it or merged into it directly. It exists because this repository was renamed from master to main, and older documentation, bookmarks and raw file URLs still point at .../rConfig-templates/master/.... Deleting it breaks those links.

Keep it in sync when main moves, otherwise those old links silently start serving stale templates, which is worse than them breaking outright:

git push origin origin/main:refs/heads/master

Template status

Every template declares a status in its header.

Status	Meaning
rconfig-verified	Tested by the rConfig team
community-tested	Someone ran it against real hardware and reported the result
untested-starter	A best guess at the right shape, not yet run against real hardware

9 templates are currently untested-starter. If you have the hardware, running one and filing a template test report is the single most valuable small contribution you can make here. Reports are welcome whether the template worked, needed changes, or failed outright.

Naming

<vendor>-<osfamily>[-<versionqualifier>]-<protocol>-<authmode>[-<variant>].yml

Two real examples from this repository:

cisco/cisco-ios-ssh-enable.yml
cisco/cisco-ios-telnet-noenable.yml

The vendor prefix repeats the directory name deliberately, because filenames travel without their paths. See docs/CONTRIBUTING.md for the full rules, including when a hardware model belongs in the filename and when it does not.

Template keys

This README carries no key documentation. The full reference lives in docs/TEMPLATES.md: 48 keys across 7 sections, each with its type, accepted values, default, and which protocols read it.

If your device needs behaviour no existing key can express, open a new key request.

Optical transport (TL1)

Ciena 6500, Infinera DTN-X and Cisco ONS 15454 are managed over TL1 rather than a CLI, which behaves differently enough to have its own guide: docs/TL1.md. Their templates sit with their vendor like everything else. TL1 is Pro only on every platform.

Community

• Open an issue for a bug, a question, or a template request
• Join the rConfig community
• Browse the rConfig documentation

Thanks for helping grow the rConfig community. Every template here came from someone who had the hardware in front of them and took the time to write it down.