How device management works in rConfig V8 Core

This page explains how the core device building blocks in rConfig V8 Core fit together, so the device-add process makes sense before you start. After reading it you can identify what command groups, commands, templates, vendors, tags, prompts and credentials each do, and the order to set them up in.

The building blocks

Every device in rConfig V8 Core depends on a small set of interconnected objects. Setting them up in the right order is what makes backups, scheduling and compliance work.

Command groups

Command groups are the starting point (previously called Categories). Every device must belong to one group. The group determines which commands run against the device, which tasks can schedule it, and which compliance rules apply. A device with no command group sits idle.

Commands

Commands are the CLI commands sent to a device when a backup runs. A command can be a single line or a full script. Each command carries toggles that control how its output is handled: Configuration Integrity Checks validate that the output is usable config, Keep Unchanged Config avoids writing a new file when nothing has changed, and change notifications alert you when output differs from the previous version.

Templates

Templates are YAML files that define how rConfig connects to a type of device. Write a template once and reuse it across hundreds of devices. A maintained repository on GitHub can be imported with one click (see Working with connection templates). Keep connection timeouts between 5 and 30 seconds: lower values cause premature timeouts, higher values waste time on unreachable devices.

Vendors

Vendors are labels for manufacturers (Cisco, Juniper, and so on). rConfig ships a starter list that you can edit to suit your environment (see Managing vendors and models). Vendors are mainly used for filtering and reporting.

Device credentials

Device credentials store the usernames and passwords rConfig uses to log in. Create these before bulk importing devices, otherwise imported devices have nothing to authenticate with and have to be fixed afterwards.

Prompts

Prompts are the exact CLI prompts rConfig watches for to know a command has finished, such as Router# or Switch>. Regex is supported (omit the delimiters) as long as special characters are escaped correctly.

Five ways to add devices

rConfig V8 Core gives you five ways to get devices in:

Add manually from the Devices table. Suited to one or two devices.
Clone an existing device. Everything copies across except the IP and name.
Use the REST API to POST devices programmatically, for scripting or integration (see the Device REST API reference).
Import a CSV through Settings » Import/Export, for bulk operations.
Sync from an integration where one is configured.

For bulk work, the CSV workbook is the most efficient route. Prepare the supporting objects first (vendor IDs, template IDs, command group IDs, credential IDs), then complete the CSV with device names, IPs, overrides, prompts and tag lists, and upload it. The full process is covered in the device addition workbook.

What to fill out when adding a device

Whether you add a device manually or via CSV, these fields matter:

Device name and IP. Names allow letters, numbers, underscores, dots and hyphens, a three-character minimum, and no spaces. IP addresses must be valid.
Override ports only when the device does not use the template default. Most devices do not need this.
Vendor, command group and template are required, and a device does nothing useful without the correct ones. Model is optional but improves reporting.
Tags and roles control visibility and access. Attach the relevant tags, and assign a role where role-based access control is in use. An SNMP toggle is available when the device is in SNMP monitoring.
Credentials can reference a stored credential record or use ad-hoc values, including enable passwords.
Prompts (main prompt and enable prompt) must be accurate or downloads hang. Use regex for flexibility, and test it first.

Working with your device list

Once devices exist, the device table supports search, column filtering, sorting and up/down status shortcuts. Each row offers actions to assign roles, edit, clone, disable or delete (deletion asks for confirmation).

Opening a device shows the detail view: latest configs, historical logs, a button to trigger a manual download, cloning options, and a copyable debug CLI command for connection troubleshooting (see device connectivity troubleshooting).

How backups run and changes are tracked

During a backup, rConfig logs into the device, runs the command group’s commands in order, captures the output and stores it. Three command toggles shape what gets saved:

Configuration Integrity Checks (CIC) validate that output is usable config data. Turn CIC off for commands that return non-config output, such as show version or inventory commands.
Keep Unchanged Config saves disk space. When output matches the last run, rConfig records that the version is unchanged instead of writing a duplicate file, preserving the audit trail.
Change notifications raise alerts when output differs from the previous version.

The diff engine has per-command options: exclude patterns (such as timestamps or uptime counters that change every run), adjust diff context, cap output size, and tune sensitivity for case, whitespace and line endings (see configuration comparison and diffs).

Diff exclusion files define patterns to ignore. They start with a // description comment, then #[global] or #[command name] blocks, followed by full regex patterns. Use the s and/or m flags for multiline matching (the g flag is not needed). Worked patterns are covered in diff exclusions.

The versioning workflow is straightforward: the first backup creates version 1 as the baseline, and each later backup increments the version when something changes. With Keep Unchanged Config enabled, an unchanged run writes no new file but still records the version state for audit logs.

Templates and healthy connections

When you need new templates, import them from the maintained repository and customise locally. YAML is whitespace-sensitive, so keep indentation exact, add comments for future maintainers, and test against lab devices first using the CLI troubleshooting commands (see connection templates).

Adjust timeouts to device responsiveness: slower devices may need 20 to 30 seconds, faster ones 5 to 10. If you build a solid template, consider sharing it back to the community repository.

Keeping metadata clean

Consistent metadata keeps filtering and reporting reliable. If some devices are labelled Cisco, others cisco, and others Cisco Systems, filters and reports fragment. Pick a naming convention and keep to it.

The same applies to tags. Purposeful tag sets make device filtering and scheduled-task scoping work as intended, so tag with intent rather than tagging everything.

Best practices

Design command groups deliberately. Build groups around what each device set actually needs rather than one catch-all group.
Stage objects before bulk imports. Set up credentials, tags and templates first to avoid incomplete device records.
Watch the Activity Logs after large imports. Catch authentication failures and prompt issues early and fix them once.
Clean up metadata regularly. Remove unused tags and vendors, and review diff exclusion patterns so you are not suppressing alerts that matter.
Test changes on non-production devices first. Validate new templates and prompt regex in a safe location before a wide rollout.