Network Device Management Fundamentals in rConfig V8 - Core Concepts Guide

Before you start adding devices to rConfig, let’s talk about how everything actually fits together. Trust us, understanding this up front will save you from a lot of head-scratching later.

The Building Blocks (aka “What You Need to Know First”)

Here’s the thing about rConfig—it’s not just about adding devices. You’ve got all these interconnected pieces, and if you don’t get how they work together, you’re gonna have a bad time.

Command Groups are where it all starts. We used to call them Categories, changed the name but same deal. Every single device you add has to belong to one of these groups. Why? Because that’s how rConfig knows what commands to run, what tasks to schedule, what compliance rules to check. There’s no way around it—pick a group or the device just sits there doing nothing.

Commands are pretty straightforward—they’re literally the CLI commands that get sent to your devices when a backup runs. Could be one command, could be a whole script. Whatever you need. Here’s where it gets interesting though: each command has these toggles you can flip. Want to check if the config is actually valid? Turn on Configuration Integrity Checks. Only want to save stuff when it actually changes? Hit that “Keep Unchanged Config” option and stop filling up your disk with identical files. Want to get pinged when something changes? There’s a toggle for that too.

Templates are YAML files that basically tell rConfig “here’s how you connect to this type of device.” The beauty of templates is you write one, and then you can use it across hundreds of devices. We’ve got a whole repository of them on GitHub—you can literally just click a button and import them all (check out Working with Templates when you’re ready). Two things though: never put actual passwords in your templates, and keep your connection timeouts somewhere between 5 and 30 seconds. Much less and you’ll get timeouts, much more and you’re just wasting time.

Vendors are just labels for manufacturers. Cisco, Juniper, whatever. We give you a starter list but you can change it however you want (see Managing Vendors and Models for the details). Mainly useful for filtering and reports.

Tags are where things get flexible. Slap tags on devices however you want—by location, by function, by team, whatever makes sense for you. The cool part is scheduled tasks can target tags, so you can say “back up everything tagged as ‘production’” without manually selecting 200 devices. Oh, and tags can also carry role permissions, which we’ll get to in a minute (more on that in Role-Based Access Control).

Device Credentials are where you store your actual usernames and passwords. Set these up first before you start bulk importing devices, otherwise you’ll end up with a bunch of devices that can’t actually connect to anything. Not fun to clean up.

Prompts are honestly one of the trickier bits. These are the exact CLI prompts that rConfig looks for to know when a command has finished running. Like Router# or Switch>. You can use regex if you need to (just don’t include the delimiters), but make sure you escape special characters properly. Pro move: test your regex on regex101.com before you roll it out to production. Ask me how I know.

Getting Devices Into rConfig (Five Ways to Do It)

Alright, so you need to add devices. You’ve got options:

Add them manually from the Devices table. Fine for one or two devices, tedious for more.
Clone an existing device. Everything copies over except the IP and name, which is actually pretty handy.
Use the REST API to POST devices programmatically. Great if you’re scripting or integrating with other systems (API docs: Device API Reference).
Import a CSV through Settings » Import/Export. This is your friend for bulk operations.
Sync from an integration if you’ve got one set up.

For bulk work, the CSV workbook approach is your best bet. The idea is to prep everything ahead of time—get your vendor IDs, template IDs, command group IDs, credential IDs, all of it lined up. Then fill out the CSV with device names, IPs, overrides, prompts, tag lists, whatever you need. Upload it and boom, you’re done. Detailed walkthrough here: Device Addition Workbook.

One thing to know: as soon as you save a device, rConfig immediately queues up a download job. So keep an eye on the Queue Manager and Activity Logs to make sure things are actually working (troubleshooting tips: Monitoring Jobs and Logs).

What You Actually Need to Fill Out

When you’re adding a device (whether manually or via CSV), here’s what matters:

Device name and IP are obvious, but there are rules. Names can use letters, numbers, underscores, dots, and hyphens. Minimum three characters, no spaces. IP addresses have to be valid (shocking, I know).

Override ports if your device isn’t using the default from the template. Honestly you probably won’t need this most of the time.

Vendor, command group, and template are all required. Pick the right ones or your device won’t do anything useful. Model is optional but helps with reporting down the line.

Tags and roles control visibility and access. Attach whatever tags make sense, and if you’re using role-based access control, assign a role here. There’s also an SNMP toggle if your device is in SNMP monitoring (more on SNMP: SNMP Configuration).

Credentials can either reference a stored credential record or you can type in ad-hoc values. For enable passwords and such.

Prompts—main prompt and enable prompt—need to be accurate or your downloads will just hang. Use regex if you need flexibility but test it first.

Working with Your Device List

Once you’ve got devices in there, the device table is pretty straightforward. Search, filter, sort by columns, use the up/down status shortcuts to find what you need.

Each row has actions—assign roles, edit, clone, disable, delete (with a confirmation, don’t worry).

Click into a device and you get the detail view. Latest configs, historical logs, a button to manually trigger a download, cloning options, and a debug CLI command you can copy/paste if you need to troubleshoot connection issues (debugging guide: Device Troubleshooting).

Who Can See What (RBAC Stuff)

By default, device RBAC is turned on. The built-in admin role sees everything, always. For everyone else, it depends on role assignments.

You can assign a role directly to a device, or you can tag the device and assign the role to the tag—those tag-based roles cascade down to every device with that tag. Pretty handy for managing access at scale.

If a device doesn’t have a role that matches a user’s permissions, that user just won’t see it. It’s invisible to them.

Sometimes role assignments get out of sync (usually after imports). If that happens, run php artisan rconfig:update-device-roles to reapply the default admin role to everything. More on this: Managing User Roles.

How Commands Run and Changes Get Tracked

So here’s what actually happens during a backup. rConfig logs into your device, runs the commands in your command group in order, captures the output, and stores it.

Configuration Integrity Checks (CIC) validate that the output is actually usable config data. Turn this off for commands that return non-config stuff (like show version or inventory commands).

Keep Unchanged Config is a space saver. If the output is identical to the last run, rConfig doesn’t write a new file—just records that the version hasn’t changed. Good for disk space, still maintains your audit trail.

Change notifications fire off alerts when output differs from the previous version. Pretty self-explanatory.

For the diff engine, you’ve got some options per command. You can exclude patterns (like timestamps or uptime counters that change every run), adjust how much context shows up in the diff, cap the output size, and toggle sensitivity for case, whitespace, and line endings. Details on tuning diffs: Configuration Comparison Settings.

Diff exclusion files let you define patterns to ignore. They use a specific format—start with a // description comment, then add #[global] or #[command name] blocks, followed by full regex patterns. If you need multiline matching, use the s and/or m flags (no g flag, it’s not needed). Example patterns: Diff Exclusion Examples.

The versioning workflow is simple: first backup creates version 1 as your baseline. Every subsequent backup increments the version if something changed. If nothing changed and you’ve got “Keep Unchanged Config” on, no new file gets written but the version state still gets recorded for your audit logs.

Templates and Keeping Connections Healthy

When you need new templates, just import from the maintained repo. Then customize locally as needed. A few things to keep in mind: YAML is whitespace-sensitive so keep your indentation exact, add comments so future-you knows what’s going on, and test against lab devices first using the CLI troubleshooting commands (see Template Testing).

Adjust timeouts based on how responsive your devices are. Slow devices might need 20-30 seconds, fast ones can get away with 5-10. If you create something solid, consider sharing it back to the community repo (contribution guide: Sharing Templates).

Keeping Your Metadata Clean

This is one of those things nobody thinks about until it becomes a problem. Keep your vendors, tags, and models consistent. Seriously.

If you’ve got some devices labeled “Cisco” and others “cisco” and others “Cisco Systems”, your filters and reports are gonna be a mess. Pick a naming convention and stick with it.

Same with tags. Purposeful tag sets make device filtering and scheduled task scoping actually work. Don’t just tag everything with everything—be intentional about it.

And remember: tags can carry RBAC roles. If you remove a tag from a device, you’re potentially changing who can see that device. Keep that in mind.

API Collections (For the Cloud Stuff)

If you’re backing up cloud controllers or API-based devices, API Collections are how you do it. They’re basically devices, but for HTTP endpoints instead of SSH/Telnet.

You set up a collection with a base URL, retry settings, SSL verification toggle, vendor, command group, and tags. Everything works the same way as regular devices after that—they show up in tasks, get backed up on schedule, participate in diffs and compliance checks.

Authentication modes: None, Basic Auth, Bearer token, API token, or Request token (where you exchange username/password for a session token).

Add your credentials, define one or more endpoints (you can override filenames and choose GET or POST per endpoint), and test them inline before you schedule anything. Full setup: API Collections Guide.

The downloads feed into the same diff engine, search functionality, and compliance workflows as device configs. It’s all the same on the back end.

Quick Wins and Best Practices

Before we wrap up, here’s what actually matters in practice:

Design your command groups thoughtfully. Don’t just throw every possible command into one group. Create groups based on what you actually need, then assign devices accordingly.

Stage everything before bulk imports. Get your credentials, tags, and templates set up first. Otherwise you’ll end up with incomplete device records and have to go back and fix them manually.

Watch the Activity Logs after big imports. Catch authentication failures and prompt issues early, fix them once, move on.

Clean up your metadata regularly. Remove unused tags and vendors. Review your diff exclusion patterns to make sure you’re not suppressing alerts that actually matter.

Test new stuff on non-production devices first. New templates, new regex prompts, whatever—validate them somewhere safe before rolling out to everything.

That’s the essentials. The rest is just iteration and refinement as you figure out what works for your environment.