Automation & Change Management

Config templates (Jinja2)

Define changes once, render per device: templates take device attributes and variable profiles as input, so the same "set NTP/syslog/ACL" intent renders correct vendor syntax per platform.

Change workflow

Every bulk change runs through the same pipeline:

1. Draft — pick a template + target devices, preview the rendered config per device.
2. Approval — a second pair of eyes approves (RBAC-enforced; requesters cannot approve their own changes).
3. Execution — vConfig logs in, applies, and captures the session transcript.
4. Verification — a fresh backup is taken and diffed; compliance rules re-scan the touched devices.

Failed devices are reported individually; the transcript shows exactly what the device said.

Compliance-driven remediation

Compliance scan findings can be turned into remediation tickets with one click: the fix template is pre-filled from the violated rule and baseline value, and rides the same approval/execution/verification pipeline.

Drift detection

Set a device's approved config as its baseline; any deviation raises a drift event with a diff, webhook alert, and an audit trail of when it appeared. Combined with scheduled backups this catches out-of-band changes ("someone SSH'd in at 2am") within one backup cycle.

Git-backed history

Optionally keep the whole config archive in a local Git repository: every backup batch becomes a commit, giving you git log semantics over your network's history — handy for audits and postmortems.

Access paths

• Web terminal to any managed device, permission-gated and session-logged.
• Out-of-band console flows through console servers (menu-driven OOB access).
• Bastion gateway with session tickets for temporary, audited third-party access.