Templates and Command Flows

One of rauto’s core strengths is that reusable execution logic is split into two layers:

• command templates for generating final command text
• command flow templates for interactive prompt/response execution

Command templates

Command templates are based on Minijinja, which is compatible with Jinja2 syntax and well suited for parameterizing repeated command structures.

A typical template

conf t
{% for vlan in vlans %}
vlan {{ vlan.id }}
 name {{ vlan.name }}
{% endfor %}
end

Example variables:

{
  "vlans": [
    { "id": 10, "name": "MARKETING" },
    { "id": 20, "name": "ENGINEERING" }
  ]
}

Execute it with:

rauto template configure_vlan.j2 \
  --vars ./vars.json \
  --connection core-sw-01

How templates are stored

Command templates are not just loose local files. They are stored in rauto’s SQLite-backed runtime data and shared by both CLI and Web.

Common management commands:

rauto templates list
rauto templates show configure_vlan.j2
rauto templates delete configure_vlan.j2

Command flow templates

When your task is not “send a fixed list of commands once” but something like this:

• the device asks multiple questions
• each prompt needs a different response
• the flow may need runtime variables or data from another saved connection

then rauto flow is usually the better abstraction.

What command flows are good at

• Cisco-style copy scp: / copy tftp: operations
• installer-like CLI wizards
• multi-step confirmation flows
• device-side file transfer flows
• interactive command sequences driven by runtime input

Example: Cisco-like copy flow

The rauto repository ships with an editable example:

name = "cisco_like_copy"
description = "Generic interactive SCP/TFTP copy flow for Cisco-like CLIs."
stop_on_error = true
default_mode = "Enable"

[[vars]]
name = "command"
required = true

[[steps]]
timeout_secs = 300
command = "{{command}}"

[[steps.prompts]]
patterns = ["(?i)^Address or name of remote host.*\\?\\s*$"]
response = "{{server_addr}}"

The key ideas in this model are:

• each step represents one command execution phase
• prompts match device output and answer automatically
• vars can declare variable metadata for CLI validation and Web form rendering

Runtime variable rules

Command flows support multiple variable injection styles:

• --vars <file> to load variables from a JSON file
• --vars-json <json> to pass inline JSON
• top-level variable access such as {{server_addr}}
• nested access through vars, such as {{vars.server_addr}}
• connection-aware references such as {{peer.host}}

Additional runtime rules documented in the current README:

• runtime variables are merged into both top-level names and the nested vars object
• references can use connection_name.param_name for cross-connection lookup
• plain param_name resolves request vars first, then falls back to current target connection params
• command flow templates can declare current_connection_alias = "<alias>" so the selected target can be referenced directly as {{alias.host}}, {{alias.username}}, and similar fields
• one runtime variable can itself point to another saved connection name, enabling patterns such as peer=edge94 and then {{peer.host}}

Flow variable schema

Command flow templates can declare a vars schema so both CLI and Web can validate or render runtime inputs more reliably.

The README calls out these supported fields:

• name
• type
• required
• default
• options
• label
• description

This is important for enterprise usage because it turns a command flow into a more governable operator interface instead of a loose string template.

Built-in flows and selector behavior

The current README also documents built-in flow exposure:

• built-in templates are exposed via /api/flow-templates/builtins
• CLI execution accepts --template builtin:<name>
• Web selectors also use builtin:<name> values

That means a team can mix:

• built-in flows shipped with the product
• organization-managed saved flows in SQLite
• ad-hoc local TOML files for experimentation

Flow control and branching

The current flow model supports output-branch actions such as:

• next
• jump
• stop_success
• stop_failure

This is one of the reasons rauto flow is more powerful than a simple expect-style macro. It can model branching behavior in guided operational sequences.

Recording behavior for command flows

The README explicitly notes:

• every execution records a session by default
• --record-level key-events-only keeps the audit-friendly minimum
• --record-level full captures richer prompt and transition detail
• --record-file exports the same JSONL session to a file when needed

Managing command flow templates

rauto flow-template list
rauto flow-template show cisco_like_copy
rauto flow-template create cisco_like_copy --file ./my-flow.toml
rauto flow-template update cisco_like_copy --file ./my-flow.toml
rauto flow-template delete cisco_like_copy

flow vs upload

flow

Best for device-side interaction such as:

• the device running copy scp:
• the device asking for server, username, and password
• multiple prompts during one operation

upload

Best for directly uploading a local file through the remote host’s sftp subsystem:

rauto upload \
  --local-path ./configs/daemon.conf \
  --remote-path /tmp/daemon.conf \
  --connection linux-jump-01

Many network devices do not support SFTP, so upload is not a replacement for flow.

Best practices

• prefer command templates for pure command rendering
• prefer command flows when device interaction is involved
• store shared templates in rauto instead of scattering them in script folders
• use --dry-run or a test environment first for complex flows
• declare clear vars for file transfer and installer-like templates

If you are moving toward rollback-aware change execution, continue with Transactions and Orchestration.