Backup n8n Workflows to Gitea: A Story of One Broken Deploy

By the time the incident report landed in her inbox, Maya already knew what had gone wrong. She was the de facto automation owner at a fast-growing startup, and n8n was her playground. Over a year she had assembled dozens of workflows that kept marketing data in sync, enriched leads, and pinged the sales team at just the right moment.

Then one Friday afternoon, someone made a “small change” to a production workflow. A critical step was deleted, a variable misnamed, nobody remembered the exact state from last week, and the only backup was a vague hope that someone had exported a JSON file at some point.

They had not.

That weekend, while everyone else left the office, Maya stayed behind and decided something had to change. If code lived in Git, why not n8n workflows too? That decision led her to an n8n workflow template that automatically backs up every workflow into a Gitea Git repository. What started as a painful outage became the turning point for a far more robust automation setup.

The Problem: Fragile Workflows and No History

Maya’s reality was common:

• Dozens of n8n workflows, all edited directly in production
• No version history beyond “I think it looked like this last month”
• No easy way to roll back a broken change
• Zero alignment with the company’s DevOps practices

Every time a teammate asked her to tweak a workflow, she felt a quiet sense of dread. What if a change broke something subtle? What if they needed the previous version and she had no copy?

She wanted what the engineering team already had: Git history, pull requests, code review, and a reliable backup strategy. That is where the idea of backing up n8n workflows to Gitea came in.

Why Gitea + n8n Made Sense

The company already ran a self-hosted Gitea instance. Developers used it for application code, infrastructure definitions, and documentation. Maya realized that if she could get all n8n workflows into a Gitea repository, she would gain several benefits at once:

• Version history – Every workflow change would be tracked, diffed, and restorable.
• Secure storage – Workflows would live in a backed-up Git repository, not just inside n8n.
• DevOps alignment – Branching, code review, and approvals could apply to automation just like application code.
• Easy recovery – A broken workflow could be restored from a known good JSON file in seconds.

She did not just want a one-time export. She wanted a system that would:

• Automatically export all n8n workflows on a schedule
• Only commit when something actually changed
• Create new files for newly created workflows
• Run periodically, with the option to trigger it manually

That is when she found an n8n template to back up workflows to Gitea, already wired to do exactly this.

Setting the Stage: What Maya Needed First

Before she could use the template, Maya gathered a short checklist of prerequisites:

• An n8n instance with API access and a user allowed to list all workflows
• A Gitea server and a repository dedicated to workflow backups
• A Personal Access Token in Gitea with repository read and write permissions
• Basic familiarity with n8n nodes and credentials

Her plan was simple. Let n8n ask its own API for the list of workflows, then push each one into Gitea as a JSON file. The template she found already implemented this logic. She just had to wire it up correctly.

The Turning Point: Discovering the n8n Backup Template

The template came with a clear promise: automate backups of every n8n workflow into Gitea using the Gitea REST API. It handled export, comparison, base64 encoding, and file creation or update. All Maya needed to do was adapt it to her environment.

She opened the template and saw the key building blocks:

• A Schedule Trigger to run the backup regularly
• A Globals node to store repository information
• An n8n API node to fetch all workflows
• Logic to check whether each workflow already existed in Gitea
• Nodes to create or update files only when content changed

It was exactly what she needed, but it still had to be tuned to her Gitea instance and n8n credentials.

Rising Action: Wiring the Template to Her Stack

Configuring the Repository Globals

The first thing she noticed was the Globals node. This node controlled the core Gitea repository details that other nodes would reuse.

Inside it, she set three variables:

• repo.url – for example https://git.internal.company.com
• repo.owner – her team’s Gitea organization
• repo.name – the name of the backup repository, such as n8n-workflows

These values were used later by the HTTP Request nodes to construct the Gitea API URLs for listing, creating, and updating files. One change here would ripple through the whole workflow, which made maintenance easier.

Creating a Gitea Personal Access Token

Next, she logged into Gitea and navigated to:

Settings → Applications → Generate Token

She generated a new Personal Access Token with repo read/write permissions. Since this token would only be used for backups, she kept the scope as limited as possible.

Back in n8n, she created a new credential of type HTTP Header Auth named Gitea Token. She configured it like this:

• Header name: Authorization
• Header value: Bearer YOUR_PERSONAL_ACCESS_TOKEN

She made sure to include a space after Bearer and before the token. Missing that space is a classic source of 401 errors, and she did not want to debug something that simple later.

Connecting the Gitea Credentials to the Right Nodes

The template included several HTTP Request nodes that talked to Gitea. Each one had to use the Gitea Token credential she had just created.

She attached the credential to:

• GetGitea – checks if a workflow JSON file already exists in the repository
• PutGitea – updates an existing file when content has changed
• PostGitea – creates a new file for workflows that are not yet tracked

Now, any request to Gitea from those nodes would be properly authenticated.

Allowing n8n to Read Its Own Workflows

Then came the other side of the pipeline: n8n itself. The template included an n8n API node that lists all workflows. For that node to work, it needed valid credentials with permission to read workflows.

She configured the node with either:

• An API token for her n8n user, or
• Basic auth credentials

The important part was that this account could list every workflow that needed to be backed up. Once that was set, the node could fetch the full catalog of workflows on demand.

Adjusting the Schedule and Running the First Test

The template shipped with a Schedule Trigger set to run every 45 minutes. That was a reasonable default, but Maya decided to start with manual runs while she validated everything.

She opened the Schedule Trigger node and confirmed the interval settings, then disabled automatic execution temporarily. With a single click on “Execute workflow” she could run a manual backup test.

Her checklist for the first run:

• Does the workflow execute without errors?
• Do JSON files appear in the Gitea repository?
• Are new workflows created as new files?
• Are existing files only updated when content changes?

When the run finished, she switched over to Gitea. A new repository full of <workflow-name>.json files greeted her. Each commit represented a snapshot of her automation universe.

Inside the Machine: How the Template Actually Works

Now that the basics were running, Maya wanted to understand the inner workings. If this workflow was going to protect her automations, she needed to trust and possibly extend it.

Node by Node: The Backup Flow

The template followed a clear flow:

1. Schedule Trigger

   Starts the entire process at configured intervals. In Maya’s case, it would eventually run every 45 minutes, or on demand while testing.

2. Globals

   Injects the repository URL, owner, and name into the workflow. These values are reused to construct Gitea API endpoints.

3. n8n API node

   Calls the n8n API to list all available workflows. The result is a collection of workflow objects, each containing its JSON definition.

4. ForEach / Split

   Splits the list into individual items so each workflow can be processed separately. This pattern lets the workflow handle any number of workflows.

5. GetGitea

   For each workflow, this node tries to fetch a corresponding .json file from Gitea. If the file does not exist, Gitea returns a 404, which the workflow interprets as “this is a new workflow, we need to create it.”

6. Exist (If)

   An If node checks whether the file exists or not, based on the response from GetGitea. This decision point splits the flow into “create” and “update” paths.

7. SetDataCreateNode / SetDataUpdateNode

   Depending on the branch, these nodes prepare the payloads for the Gitea API. They set things like file path, commit message, and the content that will later be encoded.

8. Base64EncodeCreate / Base64EncodeUpdate

   Gitea expects file content in base64 format when creating or updating files through its API. These nodes take the workflow JSON and encode it to base64 so Gitea can accept it.

9. Changed (If)

   Before pushing an update, the workflow compares the newly encoded content with the existing file content in the repository. If they are identical, there is no need to commit anything. This avoids noisy commits and keeps Git history meaningful.

10. PutGitea / PostGitea

    Finally, the workflow calls the Gitea REST API to either update an existing file using PUT or create a new one using POST. Each write represents a real change in the workflow definition.

Important Implementation Details Maya Noticed

As she explored, a few details stood out:

• Files were stored as <workflow-name>.json in the repository root. If she wanted a folder structure, she could adjust the path in the HTTP Request nodes.
• Base64 encoding was not optional. The Gitea API required it for file content, so the encoding nodes were essential.
• The “Changed” check was what kept her Git history clean. Without it, every run would generate redundant commits even when nothing had changed.

Keeping It Safe: Security in the New Setup

As the person responsible for automation, Maya was also responsible for its security. She took a few deliberate steps to keep tokens and permissions under control:

• She stored the Gitea token only in n8n’s credentials store, never hard coded inside nodes.
• She gave the token the least privileges required, mainly repository read/write for the backup repo.
• She documented a simple process to rotate the token periodically and update the n8n credential when needed.

This way, even if someone gained access to the workflow configuration, they would not see the raw token in plain text.

When Things Go Wrong: How She Debugged Early Runs

The first few runs were not perfect. A typo here, a misconfigured header there, and Maya had to debug. The template’s structure made that process manageable.

Common Issues She Encountered

• 401 Unauthorized

  When she first wired the Gitea Token, she forgot the space in Bearer <token>. Fixing the Authorization header format resolved it.

• 404 on GetGitea

  At first this looked like an error, but it was actually expected for new workflows. The workflow correctly followed the “create” branch when it saw the 404.

• No files updated

  On one test, she changed a workflow but saw no new commit. It turned out the base64 comparison was not using the right field. After verifying that the Base64Encode node produced the correct string and that the “Changed” If node compared the right values, updates started to appear as expected.

Debug Techniques That Helped

• Running the workflow manually with a smaller subset of workflows while she validated each step.
• Inspecting node output in the n8n UI, including request and response bodies for the HTTP nodes.
• Temporarily logging or returning intermediate values, such as the base64 string, to confirm encoding was correct.

After a couple of iterations, the workflow ran cleanly and produced exactly the Git history she wanted.

Beyond Backups: How She Extended the Workflow

Once the core backup was stable, Maya started thinking like a DevOps engineer. Backups were just the beginning. With n8n and Gitea connected, new possibilities opened up.

She considered several enhancements:

• Branching for review

  Push workflow changes into a dedicated branch first, then open pull requests before merging to main. That way, changes to critical automations could be reviewed just like application code.

• Date-based folders

  Store backups inside paths like backups/2025-10-14/<workflow-name>.json to keep historical snapshots by date.

• Notifications

  Send a Slack or email notification whenever new workflows were created or existing ones were updated, giving the team visibility into automation changes.

The same pattern of “fetch, compare, encode, push” could be repurposed for many automation governance tasks.

The Resolution: From Panic to Confidence

A few weeks after setting up the backup workflow, another teammate accidentally broke a production automation. This time, nobody panicked.

Maya opened the Gitea repository, browsed to the affected workflow’s JSON file, and checked the commit history. In a few clicks, she had the last known good version. She restored it in n8n, and the incident was over before anyone outside the