Workflow Restore icon

Workflow Restore

Restore n8n workflows from GitHub repository

Overview

This node restores n8n workflows from backups stored in a GitHub repository. It supports restoring the latest full backup, a backup from a specific date, or individual workflows by name. The node is useful for recovering workflows after accidental deletion, migrating workflows between instances, or synchronizing workflows from version-controlled backups.

Typical use cases include:

  • Quickly restoring all workflows to the state of the latest backup.
  • Restoring workflows as they existed on a particular date.
  • Selectively restoring specific workflows without affecting others.
  • Handling conflicts with existing workflows by skipping, renaming, or overwriting.
  • Optionally activating restored workflows immediately.

Properties

Name Meaning
Restore Mode Choose how to restore workflows:
- Latest Backup: Restore from latest full backup
- Specific Date: Restore from backup on specific date
- Individual Workflows: Restore specific workflows by name
Backup Date Date of the backup to restore (required if "Specific Date" mode is selected)
Workflow Names Comma-separated list of workflow names to restore (required if "Individual Workflows" mode is selected)
GitHub Repository Source GitHub repository in format owner/repository-name where backups are stored
Branch Name Git branch to restore from (default: main)
Conflict Resolution How to handle name conflicts when a workflow already exists:
- Skip: Do not restore conflicting workflows
- Rename: Auto-rename restored workflows to avoid conflict
- Overwrite: Replace existing workflows with restored ones
Activate After Restore Whether to activate workflows immediately after restoring (true/false)

Output

The node outputs an array of JSON objects summarizing the restore operation per input item. Each output contains:

  • success: Boolean indicating overall success of the restore attempt.
  • message: Summary message describing how many workflows were restored, skipped, or failed.
  • repository: The GitHub repository used as source.
  • branch: The Git branch used.
  • restoreMode: The selected restore mode.
  • restored: Array of objects for successfully restored workflows, each with:
    • id: Workflow ID in n8n.
    • name: Workflow name.
    • action: Either "created" or "updated".
  • skipped: Array of objects for workflows skipped due to conflicts, each with:
    • name: Workflow name.
    • reason: Reason for skipping (e.g., "Workflow already exists").
  • errors: Array of objects for workflows that failed to restore, each with:
    • workflow: Workflow name.
    • error: Error message.
  • totalProcessed: Total number of workflows processed from the backup.

No binary data is output by this node.

Dependencies

  • Requires access to a GitHub repository containing workflow backups.
  • Needs credentials for:
    • GitHub API access to fetch backups.
    • n8n API access to create, update, and activate workflows.
  • The node uses helper classes (GitHubHelper and N8nHelper) to interact with GitHub and n8n APIs respectively.
  • Proper permissions must be granted to these credentials to read repository contents and manage workflows.

Troubleshooting

  • No workflows found to restore: This occurs if the selected backup or workflows do not exist in the repository or branch. Verify the repository, branch, and restore mode parameters.
  • Unsupported restore mode error: Happens if an invalid restore mode is provided. Use one of the supported modes: latest, byDate, or individual.
  • Conflict resolution issues: If workflows are skipped unexpectedly, check the conflict resolution setting. Choosing "Rename" or "Overwrite" can help avoid skips.
  • API authentication errors: Ensure that both GitHub and n8n API credentials are correctly configured and have necessary permissions.
  • Restore failures for individual workflows: Errors during creation or update of workflows will be reported per workflow. Check error messages for details, such as invalid workflow data or API limits.
  • If the node is set to continue on fail, it will report errors in the output instead of stopping execution.

Links and References

Discussion