How One Automator Stopped Losing Workflows: A Story About n8n Backups to Gitea

On a quiet Tuesday afternoon, Lina, a marketing operations lead turned accidental automation engineer, stared at her n8n dashboard in disbelief. A single misclick had just overwritten a critical workflow that synchronized leads between their CRM and email platform. There was no Git history to roll back to, no backup to restore from, and the last export she had made was weeks old.

That was the moment she decided that “I will back this up someday” was no longer good enough.

The Problem: Fragile Automations With No Safety Net

Lina’s team relied heavily on n8n. Dozens of workflows handled lead routing, reporting, notifications, and campaign triggers. Over time, these flows had evolved through countless tweaks and experiments. The trouble was that all this logic lived inside n8n only.

Every change felt risky. If someone edited a workflow and broke it, there was no easy way to see what had changed or to revert to a previous version. If the n8n instance went down, or if a migration went wrong, the team could lose days of work.

She knew what she wanted:

• A versioned history of every n8n workflow
• Easy recovery after accidental edits or system issues
• Collaboration and review via Git, not just screenshots and exports
• Offsite storage in a reliable Git server like Gitea

Her DevOps colleague had already set up a Gitea instance for internal projects. The missing piece was a bridge between n8n and Gitea that would keep workflows backed up automatically.

The Discovery: An n8n Template That Talks to Gitea

While searching for a better way, Lina found an n8n workflow template designed specifically to back up n8n workflows to a Gitea repository. It promised to:

• Run on a schedule, for example every 45 minutes
• Retrieve all workflows from n8n via the API
• Convert each workflow into a JSON file
• Base64-encode the content for Git and Gitea compatibility
• Check Gitea for an existing file for each workflow
• Create new files or update existing ones only when changes were detected

It sounded like exactly what she needed: a reusable, automated backup pipeline between n8n and Gitea.

Setting the Stage: What Lina Needed in Place

Before she could turn this template into her safety net, Lina gathered the essentials:

• An n8n instance with API access so workflows could be listed programmatically
• A Gitea instance, already running inside the company network
• A dedicated Gitea repository to store workflow JSON backups
• A Gitea personal access token with repository read and write permissions

With those pieces ready, she imported the template into n8n and began shaping it to fit her environment.

Rising Action: Turning a Template Into a Reliable Backup System

Defining the “Where” With Global Variables

The first step was to tell the workflow where to send everything. Inside the template, Lina opened the Globals (Set) node. This node acted like a central configuration panel.

She filled in three key variables:

• repo.url – her Gitea base URL, for example https://git.example.com
• repo.owner – the user or organization that owned the repository
• repo.name – the repository name, such as workflows

With those values in place, every HTTP call in the workflow would know exactly which Gitea repository to use.

Gaining Access: Creating and Wiring the Gitea Token

Next, Lina needed a secure way for n8n to talk to Gitea. She logged into Gitea, navigated to Settings → Applications, and clicked Generate Token. She granted it repository read and write permissions, then copied the token somewhere safe.

Inside n8n, she opened the credentials manager and created a new credential using HTTP Header Auth. She named it Gitea Token and configured it as follows:

• Header name: Authorization
• Header value: Bearer YOUR_PERSONAL_ACCESS_TOKEN (with a space after Bearer)

This single credential would be reused by all Gitea-related HTTP request nodes in the workflow.

Connecting the Dots: Attaching Credentials to HTTP Nodes

The template contained three HTTP request nodes that interacted with Gitea. Lina attached her new credential to each of them:

• GetGitea – to read an existing file from the repository
• PostGitea – to create a new file when there was no existing backup
• PutGitea – to update an existing file using its SHA hash

Once these nodes were wired to the Gitea Token credential, the workflow had authenticated access to the repository.

Ensuring n8n Can See Its Own Workflows

Of course, backing up workflows required that n8n could first list them. The template included a node that fetched workflows via the n8n API. Lina opened that node and confirmed that it had valid API authentication configured, either an API key or Basic Auth.

She ran the node manually and checked the output. All her workflows appeared in the response. That meant the first half of the pipeline, getting data out of n8n, was working correctly.

The Turning Point: How the Template Handles Files and Changes

At this stage, Lina understood how the pieces connected, but the real magic was in how the workflow treated each n8n workflow as a proper Git-tracked file.

From Workflow to JSON File

For every workflow returned by the n8n API, the template performed a series of transformations:

• It converted the workflow into a pretty-printed JSON string for readability.
• It then base64-encoded that JSON content, since the Gitea REST API expects file content in base64 format for create and update operations.

The filename convention used by the template was straightforward:

<workflow-name>.json

Lina realized that if any of her workflow names were not unique, she might end up with collisions in the repository. For those cases, she considered tweaking the template to append the workflow ID to the filename to ensure uniqueness.

Checking If a File Already Exists in Gitea

Before creating or updating any file, the template needed to know what already lived in the repository. For each workflow, it called the Gitea endpoint:

/api/v1/repos/{owner}/{repo}/contents/{path}

If a file existed, GetGitea returned two crucial pieces of information:

• The current file’s sha, required for updates
• The file content, which could be base64-decoded and compared with the new JSON

The workflow then compared the decoded repository content with the freshly generated JSON from n8n. Only if there was a difference would it proceed to update the file.

If the file did not exist, Gitea responded with a 404. Rather than treating this as an error, the template used it as a signal to create a new file backup.

Deciding Between Create and Update

Once the comparison was done, the workflow followed a simple decision path:

• If the file did not exist (404), it used a POST request (or PUT depending on the Gitea version) to create a new file in the repository.
• If the file existed and the content had changed, it used a PUT request, including the existing file sha, to update the file.
• If nothing had changed, it skipped any write operations, keeping the Git history clean and meaningful.

Behind the scenes, these operations used the standard Gitea API endpoints:

• Get file: GET /api/v1/repos/{owner}/{repo}/contents/{path}
• Create file: POST /api/v1/repos/{owner}/{repo}/contents/{path} (or PUT in some versions)
• Update file: PUT /api/v1/repos/{owner}/{repo}/contents/{path} with the sha of the file

Each create or update call included an Authorization header:

Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN

and a JSON body similar to:

{  "content": "BASE64_ENCODED_FILE_CONTENT",  "message": "Backup: update workflow <name>",  "sha": "EXISTING_FILE_SHA"  // only for updates
}

For Lina, this meant that every workflow change would be recorded as a Git commit with a clear message, ready for code review or rollback if needed.

Resolution: From Anxiety to Confidence

First Test: Watching the Backups Appear

With everything wired up, Lina decided it was time to test. She:

1. Ran the workflow manually inside n8n.
2. Watched the execution logs as it fetched workflows, checked Gitea, and created or updated files.
3. Opened the Gitea repository in her browser and refreshed the page.

There they were: a neatly organized list of JSON files, one for each n8n workflow. Each file had a commit message starting with “Backup” and contained the full, pretty-printed definition of the workflow.

She made a small change to one workflow in n8n, ran the backup workflow again, and saw a new commit appear in Gitea, with only that file updated. The change detection logic was working exactly as intended.

Automating the Schedule

Now that the manual run looked good, Lina enabled the schedule trigger in the template. She configured it to run every 45 minutes, which was frequent enough to capture changes without being noisy.

From that point on, backups were no longer a manual chore. They were part of the fabric of her automation platform.

Staying Safe: Best Practices Lina Adopted

Once the system was running, Lina and her DevOps team added a few best practices to keep it secure and maintainable:

• They rotated the Gitea token periodically and stored it only in n8n credentials or a dedicated secrets manager.
• They limited the token scope to the specific backup repository whenever possible.
• They stored the backups in a protected repository under a locked-down organization.
• They improved commit messages with timestamps and brief summaries to make changes easier to trace.
• They monitored the scheduled workflow for failures and configured n8n alerts and logging.

These small steps ensured that the backup pipeline was not just convenient, but also secure and auditable.

When Things Go Wrong: Troubles Lina Avoided (and How)

During her setup, Lina anticipated a few common errors and learned how the template handled them.

404 When Checking a File

If GetGitea returned a 404, it simply meant the file did not exist yet. For new workflows, this was expected. The template treated it as a signal to create a new file backup rather than as a failure.

401 or 403 Authorization Errors

For authentication issues, she double-checked:

• That the token itself was correct.
• That the Authorization header used the format Bearer YOUR_TOKEN with the space included.
• That the token had write permissions for the target repository.

Files Not Updating

If a file did not update when expected, the usual culprits were:

• An incorrect or missing sha in the update request.
• A comparison step that did not properly decode the repository content before checking for differences.

By ensuring the workflow computed the correct SHA and compared decoded repository content against the local JSON, she kept updates accurate and deterministic.

What Changed For Lina and Her Team

After a few weeks of running the backup workflow, the impact became clear:

• Accidental edits were no longer disasters. The team could inspect Git history, see exactly what changed, and restore previous versions.
• New teammates could review workflow definitions in Gitea without logging into n8n, making collaboration easier.
• Migrations and upgrades felt less risky, since all workflows lived in a separate, version-controlled system.
• The team could treat n8n workflows like any other code asset, with reviews, branches, and pull requests if they wanted.

Most importantly, Lina stopped worrying every time she hit “Save” in n8n. Her automations finally had a safety net.

Your Next Step: Turn This Story Into Your Own Backup Strategy

If you recognize yourself in Lina’s situation, you can follow the same path:

1. Import the n8n template that backs up workflows to Gitea.
2. Configure the Globals node with your repo.url, repo.owner, and repo.name.
3. Create a Gitea personal access token with repo read and write permissions and add it to n8n as an HTTP Header Auth credential.
4. Attach that credential to the GetGitea, PostGitea, and PutGitea nodes.
5. Ensure your n8n workflow fetch node has valid API credentials and returns all workflows.
6. Run the workflow manually, verify that JSON files appear in your Gitea repository, then enable the schedule trigger.

From there, you can refine commit messages, adjust the backup frequency, and tighten security according to your needs.

Call to action: Import this template into your n8n instance, run it once to validate the backups, then switch on the schedule so your workflows are protected around the clock. If you run into questions, share them with the n8n community or your internal DevOps team so others can benefit from your setup and improvements.