Block 1 - On clicking 'execute'
- Type / Role
- n8n-nodes-base.manualTrigger - manualTrigger
- Config choices
- Version 1
This workflow is provided as-is. Please review and test before using in production.
Basics Provides a mechanism to save all your workflows into a github repository and path (of your choosing). These can then be shared through your entire org and used to track changes (if you make ...
n8n-nodes-base.manualtrigger, n8n-nodes-base.function, n8n-nodes-base.httprequest, n8n-nodes-base.github, n8n-nodes-base.merge, n8n-nodes-base.switch, n8n-nodes-base.noop, n8n-nodes-base.cron
This workflow is cataloged by N8N Workflows and links back to its original n8n.io source page by Brian Burnett.
Original n8n.io sourceProvides a mechanism to save all your workflows into a github repository and path (of your choosing). These can then be shared through your entire org and used to track changes (if you make any sad 'oopsies'.
Most of the configuration is done in the Globals node which houses the repo detail for github nodes. The only other dependency is that it by default looks for a GitHub credential, if you use something other than that precise wording you will need to change the credential used on the respective nodes. We gave it 'Manage' rights, but that was only so that it was able to override a requirement for checks to complete? Most would probably only need 'Write' privileges.
Well, so we initially started using N8N just as a kubernetes-based service housed with its DB running inside the pod. Worked great for getting to know N8N and we jut kept all our workflows and credentials listed in a readme. Fast forward about a year...
We have migrated this into our 'production' toolsets and maintain a bunch of team worflows inside it (not company-wide, but LOTS of team fun). While trying to spin a copy of our production RDS database, the ++actual++ production database was deleted, and in doing so AWS was nice enough to wipe our snapshots too!! Yea!
Thankfully it only took us a few hours to get everything back up and running thanks to this, so I'm sharing it for everyone to benefit. We have used it to restore old workflows, changes, and now to test our full DR proceedures! (Ok, I might have taken that a bit far)
This catalog entry is organized from the workflow JSON. The node-level section below shows the executable blocks available for review before importing the template.
| Workflow | Save your workflows into a GitHub repository |
|---|---|
| Complexity | advanced |
| Nodes | 16 |
| Categories | DevOps |
| Author | Brian Burnett |
| Published | 09 Dec 2020 |
Use the JSON export at /data/workflows/817/817.json as the source template for this automation.
Open n8n, import the downloaded JSON, and review each node before activating the workflow.
Replace placeholder credentials, API keys, webhook URLs, account IDs, and environment-specific values with your own settings.
Run the workflow manually or in a staging workspace, inspect node output, and confirm downstream systems receive the expected data.
Enable the workflow only after testing, then monitor executions, errors, and rate limits during the first production runs.
Review imported nodes carefully before activation. This catalog entry is intended to help you inspect the workflow structure, understand required services, and find related templates faster.
Node names, credentials, schedules, webhook paths, and external service limits may need adjustment for your workspace.
Basics Provides a mechanism to save all your workflows into a github repository and path (of your choosing). These can then be shared through your entire org and used to track changes (if you make ...
Review the workflow JSON, configure any required credentials in n8n, and test the automation in a safe workspace before using it in production.
Yes. Use the block-by-block analysis and the downloadable JSON to inspect each node, then adjust credentials, prompts, schedules, filters, or destinations for your DevOps use case.