Build an AAP Self-Service Template: Backup Network Switch Configs to Git

Why Network Config Backup Belongs in a Self-Service Catalog

Backing up switch configurations is one of those tasks every network team knows it should do religiously, and yet it's frequently the first thing skipped when things get busy. It's repetitive, it's low-risk when done right, and it doesn't require deep automation expertise to run — which makes it a textbook candidate for self-service.

At Red Hat Tech Day Netherlands 2026 in Bunnik, Fred van Zwieten and Ismail Dhaoui demoed exactly this idea as part of Ansible Automation Platform 2.7's new Automation Portal. The portal introduces a self-service template gallery where every template exposes a single "Start" button — operators click it, answer a couple of prompts if needed, and the job runs. No one browsing the catalog needs to know which project the playbook lives in, which execution environment it uses, or how credentials are wired up. Among the templates shown live in the demo catalog was Network - Backup Switch Configs, described simply as: back up running configs from Cisco and Arista switches to Git.

This article walks through what that template represents, why it's a strong first candidate for self-service automation, and how you'd structure the underlying job template and playbook in AAP.

See also: Build an AAP Self-Service Template: Branch Network Health Check

What the Template Does

The premise is straightforward. On demand — or on a schedule — the job template connects to a defined inventory of network switches, pulls the running configuration from each device, and commits the result to a Git repository. Over time this builds a version-controlled history of every configuration change across the estate, which is invaluable for troubleshooting, compliance audits, and disaster recovery.

Because it was demoed inside the Automation Portal rather than the classic AAP controller UI, the emphasis was on the operator experience: a network engineer (or even a first-line support technician) can trigger a full backup run without touching the underlying automation content at all.

How It Fits the Self-Service Template Gallery

The Bunnik demo catalog included eleven templates spanning branch operations, cloud provisioning, patching, and network management. Seeing "Network - Backup Switch Configs" alongside templates like Network - Firewall Remediation and Network - Firewall Rule Request illustrates a pattern: network operations are being decomposed into discrete, well-scoped, self-service actions rather than left as tribal-knowledge playbooks that only the automation team can run.

See also: Build an AAP Self-Service Template: Firewall Misconfiguration Remediation

Building the Job Template

Behind the "Start" button in the Automation Portal is a standard AAP job template, pointed at a project that contains the backup playbook. A realistic structure looks like this:

---
- name: Network - Backup Switch Configs
  hosts: network_switches
  gather_facts: false
  connection: network_cli
  vars:
    backup_repo_path: /tmp/switch-config-backups
    backup_repo_url: "git@git.example.com:netops/switch-configs.git"

  tasks:
    - name: Back up running configuration (Cisco IOS)
      cisco.ios.ios_config:
        backup: true
        backup_options:
          filename: "{{ inventory_hostname }}_{{ ansible_date_time.iso8601_basic_short }}.cfg"
          dir_path: "{{ backup_repo_path }}"
      when: ansible_network_os == "cisco.ios.ios"

    - name: Back up running configuration (Arista EOS)
      arista.eos.eos_config:
        backup: true
        backup_options:
          filename: "{{ inventory_hostname }}_{{ ansible_date_time.iso8601_basic_short }}.cfg"
          dir_path: "{{ backup_repo_path }}"
      when: ansible_network_os == "arista.eos.eos"

    - name: Commit and push backups to Git
      ansible.builtin.shell: |
        cd {{ backup_repo_path }}
        git add .
        git commit -m "Automated backup: {{ inventory_hostname }} $(date -Iseconds)" || true
        git push origin main
      delegate_to: localhost
      run_once: false

A few things worth calling out for anyone assembling this as a real job template:

• Multi-vendor handling. The when conditions branch on ansible_network_os, so a single playbook can service both Cisco IOS and Arista EOS devices as described in the demo — a mixed-vendor inventory is treated as one job, not two.
• Idempotent commits. The || true after git commit prevents job failure on nights when nothing changed — a common gotcha in config backup automation that otherwise generates noisy false failures.
• Credentials stay hidden. In the Automation Portal experience, the SSH credentials for the switches and the Git deploy key are attached to the job template by the automation team ahead of time. The self-service operator never sees or handles them.

Designing It for Self-Service

Turning a working playbook into a genuinely self-service template is less about the YAML and more about what you strip away from the operator's view. A few practices make the difference:

• Minimize prompts. If the template needs a survey at all, keep it to one or two fields (for example, "target site" or "device group"), not a wall of technical parameters.
• Sensible defaults everywhere else. Inventory scope, Git branch, retention path — bake these into the job template so "Start" really does mean start.
• Clear naming. The "Network - " prefix used across the demo catalog groups related templates visually in the portal gallery, which matters once dozens of templates exist side by side.
• Read-only blast radius. Config backup only reads from devices, which is precisely why it's a low-risk, high-confidence first template to expose broadly — a useful lesson when deciding what else to promote into your own self-service catalog.

Key Takeaways

• The Network - Backup Switch Configs template, demoed at Red Hat Tech Day Netherlands 2026, backs up running configs from Cisco and Arista switches straight to Git.
• It's exposed through AAP 2.7's new Automation Portal, where a single "Start" button hides all the underlying playbook, inventory, and credential complexity from the operator.
• Read-only, low-risk automations like config backup are ideal first candidates for a self-service template gallery.
• A practical implementation branches on ansible_network_os to support multiple vendors in one playbook, then commits results to Git for full version history.
• Good self-service design is mostly about restraint: minimal prompts, strong defaults, and clear naming conventions so the template is genuinely usable by non-automation staff.