Skip to content
rauto Docs

Reusable Execution Templates

Reusable execution templates are one of the clearest signs that rauto is more than a simple command runner.

They allow you to store structured execution JSON as reusable templates in SQLite and render runtime variables before execution.

What counts as an execution template

Section titled “What counts as an execution template”

Current execution template families include:

  • tx block templates
  • tx workflow templates
  • orchestration templates

From the README, the current API families are:

  • /api/tx-block-templates
  • /api/tx-workflow-templates
  • /api/orchestration-templates

Why these templates matter

Section titled “Why these templates matter”

Use them when you want to move from:

  • one-off JSON files
  • operator-specific local artifacts
  • duplicated rollout logic across teams

into:

  • centrally stored execution blueprints
  • parameterized rollout patterns
  • reusable change logic across targets and time windows

Supported execution input modes

Section titled “Supported execution input modes”

Tx block execution

Section titled “Tx block execution”

POST /api/tx/block supports:

  • tx_block_template_name
  • tx_block_template_content
  • tx_block_template_vars

Tx workflow execution

Section titled “Tx workflow execution”

POST /api/tx/workflow supports:

  • workflow_template_name
  • workflow_template_content
  • workflow_vars

Orchestration execution

Section titled “Orchestration execution”

POST /api/orchestrate supports:

  • plan_template_name
  • plan_template_content
  • plan_vars

This means the same logical rollout can be supplied in three ways:

  • inline JSON payload
  • reference to a saved template
  • raw template content plus variable input

Rendering context

Section titled “Rendering context”

The README documents a richer render context than the current high-level docs previously exposed.

Template rendering can reference:

  • vars
    • request-level runtime variables
  • connection
    • resolved single-target connection data such as host, username, password, port, and device profile
  • connection.saved
    • metadata when the target comes from a saved connection
  • defaults
    • global default connection settings, mainly relevant in orchestration rendering
  • now
    • current time helpers such as rfc3339 and timestamp_ms

There is also top-level shorthand resolution:

  • request vars are checked first
  • current target connection params are used as fallback

Direct connection object references

Section titled “Direct connection object references”

The README explicitly notes that template strings can also reference connection objects directly.

Examples:

  • {{ edge94.host }}
  • {{ edge94.password }}
  • {{ edge94.vars.site }}

This is important when orchestration or workflow logic needs to stitch together data from peer targets or named saved connections.

Example string rendering

Section titled “Example string rendering”

Any string field can use Minijinja syntax.

{
  "command": "scp /tmp/{{ image_file }} {{ edge94.username }}@{{ edge94.host }}:/tmp/{{ image_file }}"
}

This shows that the template model is not limited to top-level metadata. Operational string fields inside execution payloads can be rendered too.

Where this shows up in Web UI

Section titled “Where this shows up in Web UI”

The current README notes that Operations -> Orchestrated Delivery includes dedicated runtime-var inputs for:

  • Tx Workflow: workflow_vars
  • Orchestration: plan_vars

That makes template-driven rollout practical for operators who are not directly editing raw JSON.

Relationship to JSON files and examples

Section titled “Relationship to JSON files and examples”

You do not need to choose only one model.

A common maturity path is:

  1. start from example JSON files in the repository
  2. adapt them to your environment
  3. convert stable patterns into saved execution templates
  4. feed runtime vars through Web UI or API at execution time

Relevant example families:

  • core-vlan-workflow.json
  • fabric-change-workflow.json
  • campus-vlan-orchestration.json
  • fabric-advanced-orchestration.json
  • Linux image rollout examples

When to use execution templates

Section titled “When to use execution templates”

Use JSON files directly when

Section titled “Use JSON files directly when”
  • the rollout is still evolving quickly
  • you are iterating locally
  • the change is not yet standardized

Use reusable execution templates when

Section titled “Use reusable execution templates when”
  • the structure is stable
  • the same rollout happens repeatedly
  • multiple operators need the same pattern
  • review and governance matter
  • you want Web UI users to reuse controlled execution blueprints

Enterprise guidance

Section titled “Enterprise guidance”

Treat templates as governed assets

Section titled “Treat templates as governed assets”

Execution templates often represent approved operational procedures.

Document for each template:

  • purpose
  • required vars
  • expected targets
  • rollback semantics
  • ownership team
  • last validation date

Separate structure from runtime data

Section titled “Separate structure from runtime data”

The best reusable templates keep:

  • structure in the template
  • environment-specific values in runtime vars

This improves reuse and reduces change drift.

Prefer saved connections over inline secrets

Section titled “Prefer saved connections over inline secrets”

Because render context can include resolved connection objects, enterprise teams should prefer saved connection references over duplicating raw credentials across JSON content.

Section titled “Related pages”