Backup n8n Workflows to Gitea: A Story of Lost Work and Automatic Safety Nets

On a quiet Tuesday evening, Mia, a marketing operations lead, watched her n8n dashboard with a sinking feeling. A misconfigured update had broken several of her carefully crafted workflows. One of them powered the company’s lead routing, another handled reporting, and both had been tweaked endlessly over the last few months.

There was no easy way to roll back. No history of changes. No simple “undo.”

That was the night Mia decided she would never trust her memory alone again. She needed automated backups of every n8n workflow, stored safely in Git, with real version history. A colleague mentioned a ready-made n8n template that could back up all workflows to a Gitea repository. Curious and a bit desperate, she opened it up.

The Problem: Fragile Workflows and No Version History

Mia’s team relied heavily on n8n automations. They pushed experiments quickly, adjusted workflows on the fly, and shipped changes multiple times per week. It was fast, but fragile.

Her pain points were clear:

• No built-in version history for every small workflow tweak
• No simple rollback when a change broke something
• No central place for the team to review or audit workflow changes
• Anxious late nights whenever she edited a critical workflow

She already used Gitea for code and documentation. What she wanted was simple in theory: “Back up my n8n workflows to Gitea automatically, keep versions, and only commit when something actually changes.”

The n8n template she found promised exactly that: automated Git-based backups of all workflows to a Gitea repository, with change detection and minimal noise in the commit history.

The Discovery: An n8n Template Built for Git-based Backups

As Mia explored the template, she realized it was designed for her exact problem. The workflow would:

• Fetch all workflows from her n8n instance using the n8n API
• Export each one as a JSON file
• Check Gitea to see if that file already existed
• Create or update the file via the Gitea API
• Skip commits when nothing had changed to keep the Git history clean

In other words, it would turn her n8n instance into a source-controlled, auditable system, with every workflow stored as a JSON file in a private Gitea repository.

How the Workflow Operates Behind the Scenes

Mia liked understanding how things worked before trusting them. So she walked through the high-level flow of the template. It looked like this:

1. Schedule Trigger – Runs every N minutes, for example every 45 minutes, to back up workflows on a regular schedule.
2. Globals node – Stores the Gitea repository URL, the owner, and the repository name in one place.
3. n8n API node – Calls the n8n API to fetch all workflows from her instance.
4. ForEach / Split node – Iterates through each workflow returned by the API.
5. GetGitea – Checks if the JSON file for that workflow already exists in the Gitea repo.
6. Exist If node – Branches logic based on whether the file exists or not.
7. Base64 encode nodes (create/update) – Converts the workflow JSON into base64, which is what the Gitea API expects.
8. PostGitea / PutGitea – Creates a new file or updates an existing one using the encoded content.
9. Changed If node – Compares old and new content to avoid unnecessary commits when nothing has changed.

This was not just a backup. It was a disciplined Git-based safety net with version history, easy rollback, and a clean audit trail of every workflow change.

Rising Action: Mia Sets Up Her Automated n8n to Gitea Backups

Convinced this could save her from future disasters, Mia decided to set up the template in her own environment. The process was straightforward, but she followed it carefully.

1. Defining the Global Repository Settings

First, she opened the Globals node. This node would keep all key Git-related details in one place, so she would not need to hard-code URLs or repo names in multiple nodes.

She filled in:

• repo.url – Her Gitea instance URL, such as https://git.example.com
• repo.owner – The account or organization that owned the repository
• repo.name – The repository name, for example workflows

By centralizing these values, she made the workflow easier to maintain. If the repo ever moved, she would only change it here.

2. Creating a Gitea Personal Access Token

Next, she needed a way for n8n to talk securely to Gitea. In her Gitea UI, Mia went to Settings → Applications → Generate Token and created a new personal access token with repository read and write permissions.

She copied the token once, knowing she would not see it again, and went back to n8n to store it safely.

Inside n8n, she created an HTTP header credential and named it something clear, such as Gitea Token. In the header, she added:

Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN

She double-checked that there was a space after Bearer, a small detail that often causes 401 errors when forgotten.

3. Wiring Up the Gitea Credentials to the Right Nodes

With the token stored, Mia attached these credentials to each node that would call the Gitea API. In the template, those nodes were:

• GetGitea – To read file metadata and check if a workflow backup already existed
• PostGitea – To create new JSON files when a workflow backup did not exist yet
• PutGitea – To update existing JSON files when a workflow had changed

By connecting the same credential to all three, she ensured consistent authentication for every API call.

4. Connecting n8n to Its Own API

Now she needed n8n to list all of its workflows. The template included an n8n API node dedicated to this task.

Mia configured it to point to her n8n instance. Since her instance required authentication, she added the appropriate token or credentials so the node could successfully call the n8n API and retrieve the full list of workflows.

This was the heart of the backup process. Without this node, there would be nothing to export.

5. Deciding on File Names and Repository Layout

Before letting the workflow run, Mia took a moment to think about how her backups would be organized in Gitea.

The template wrote each workflow as a single JSON file, typically using a safe filename pattern like:

{workflowName}.json

She considered a few best practices:

• Sanitizing workflow names to remove invalid characters that Git or the file system might not accept
• Including the workflow ID in the filename to avoid collisions, for example {workflowName}-{workflowId}.json
• Optionally including timestamps in filenames if she ever wanted immutable snapshots

For now, she chose a naming scheme that included both the name and the ID, which gave her uniqueness and clarity.

The Turning Point: Smart Change Detection That Keeps History Clean

One feature impressed Mia more than anything else: the workflow did not blindly commit every time it ran. Instead, it checked whether anything had actually changed.

Here is how the change detection logic worked for each workflow:

1. The workflow retrieved the existing file from Gitea, including its base64 content and SHA if it existed.
2. It encoded the current workflow JSON from n8n as base64.
3. It compared the stored base64 content in Gitea with the freshly encoded content from n8n.
4. If the content was different, the workflow called the Gitea API with a PUT request to update the file, passing along the new base64 content and the repository SHA.
5. If the file did not exist yet, the workflow created it with a POST request and the encoded content.
6. If there was no difference, the Changed If node prevented any update, which reduced noise in the Git history and saved unnecessary API calls.

This was the turning point for Mia. She realized she would not be drowning in hundreds of meaningless commits. Instead, each commit would represent a real change in a workflow, making audits and rollbacks much easier.

Staying Safe: Security and Best Practices Mia Adopted

As someone responsible for marketing data and automation, Mia was careful about security. The template aligned well with common best practices, and she followed them closely:

• She granted the Gitea token only the permissions it needed, specifically repository read and write.
• She stored the token as an n8n credential instead of hard-coding it into any node.
• She used a private Gitea repository for the backups so no internal workflow logic leaked publicly.
• She considered adding signed commit messages or a signature file later if her team required stronger verification.

With these safeguards, she felt confident that the automated backup process would not introduce new risks.

When Things Go Wrong: How Mia Handled Issues

Mia knew that even the best setups can run into problems. She kept a small checklist handy for common pitfalls.

Authentication Errors

If a Gitea node returned a 401 or 403, she verified:

• That the personal access token was correct and had the right scopes
• That the Authorization header followed the exact pattern Bearer YOUR_TOKEN
• That every Gitea node, including GetGitea, PostGitea, and PutGitea, used the same credential

File Name Collisions

She discovered that workflows with identical names could overwrite each other if they shared the same filename. To avoid this, she included the workflow ID in the filename or used a slugified version of the workflow name to ensure uniqueness.

Large Workflows

Some of her more complex automations were quite large. She knew that very large workflows created larger base64 payloads, which could hit size limits in the Gitea API.

If that ever became a real issue, she planned to compress the content, for example with gzip, before encoding it. She would then store a small metadata file in the repository describing the compression method, so future readers would know how to decode it.

Testing the Waters: How Mia Validated Her Setup

Before trusting the workflow on a schedule, Mia decided to run a few careful tests.

1. She ran the template manually for a single workflow and confirmed that the PostGitea path created a new JSON file in the repository.
2. She made a small change to that workflow in n8n, for example updating a node description, then ran the workflow again and verified that the PutGitea path updated the existing file.
3. She opened the Gitea repository, inspected file contents, and checked commit messages and authors to ensure everything looked correct.
4. Once satisfied, she enabled the Schedule Trigger with an interval of around 45 minutes, which gave her frequent backups without overusing the API. A range of 30 to 60 minutes worked well for her pace of changes.

After a day of successful test runs, she finally relaxed. Her workflows were no longer a fragile black box. They were versioned assets in Git.

Going Further: How Mia Extended the Template

As her confidence grew, Mia started thinking about how to extend the template for even better visibility and control. The template made it easy to add extra steps.

• She customized commit messages to include the workflow name and a timestamp, which made audits much easier.
• For major changes, she experimented with storing historical snapshots in timestamped folders, so she could browse past states of key workflows.
• She considered adding Slack or email notifications to alert her team when a backup failed or when a significant change was detected.
• For workflows that touched sensitive data, she looked into encrypting specific fields before committing them, especially for any repository that might not be fully private.

One of her favorite commit message patterns looked like this:

Backup: Update workflow "Order Processing" (workflow-id-1234) - 2025-04-15T09:30:00Z

At a glance, anyone on the team could see exactly what changed and when.

The Resolution: From Anxiety to Confidence

A few weeks later, another risky change went wrong. A new node in a critical workflow broke a key integration. Instead of panicking, Mia opened her Gitea repository, browsed the commit history, and pulled up the last working version of the workflow JSON.

Within minutes, she restored the workflow in n8n. No late-night rebuild. No guesswork. No lost experiments.

By backing up her n8n workflows to a Gitea repository, she had:

• Git-based version control for every workflow
• Automated, scheduled backups that ran every 30 to 60 minutes
• Change detection that prevented noisy, redundant commits
• A clear audit trail of who changed what and when

The template had quietly taken care of the heavy lifting: fetching workflows via the n8n API, encoding them in base64, checking the repository state, and creating or updating files only when needed.

Start Your Own Story: Put Your n8n Workflows Under Git Protection

You do not have to wait for a broken workflow to feel the pain Mia did. If you run anything important on n8n, putting your workflows under Git-based backups is one of the simplest ways to protect your work and gain peace of mind.

Use this template to:

• Automate backups of all n8n workflows to a private Gitea repository
• Gain full version history and easy rollback
• Collaborate with your team by reviewing JSON files and commit logs
• Keep your Git history clean with smart change detection

If you need help tailoring the setup to your environment, such as filename conventions, encryption strategies, or notification rules, you can adapt the template or extend it with additional n8n nodes.

Call to action: Download the template, configure your Gitea token, run a manual backup today, and give your n8n workflows the safety net they deserve. Subscribe for more n8n automation templates, implementation stories, and deep dives.