Self Hosting Git the Simple Way with Gitea

A practical look at using Gitea as a lightweight, self-hosted Git platform.

Happy New Year, if you’re reading this! I’m pretty sure you’ve got your New Year resolutions all set up. As for me, I’m just going to explore FOSS more and more, I guess and just like that, we’ll be exploring Gitea today.

Self-hosting your own Git platform is one of those steps that quietly changes how you think about infrastructure. You stop relying on third-party services, gain full control over your data, and start understanding how developer tooling actually works behind the scenes. My journey didn’t start with Gitea, though it started with Gogs.

From Gogs to Gitea

Initially, I used Gogs as my self-hosted Git server. It was lightweight, simple, and got the job done. For a long time, it fit my needs perfectly. However, as my usage grew and I wanted more features and a more active ecosystem, the limitations became apparent.

That’s when I moved to Gitea. It felt like a natural evolution, familiar enough to feel comfortable, but actively developed and packed with features that mattered to me. Repository hosting, access control, issues, pull requests everything I needed, without unnecessary bloat. Github on steriods to be precise.

My initial CI/CD setup

When I first switched to Gitea, CI/CD was still missing from the core experience. To bridge that gap, I used Woodpecker CI. It integrated well with Gitea through webhooks and allowed me to define pipelines declaratively. Builds were reproducible, and everything ran inside my homelab.

Woodpecker worked reliably, but it also meant maintaining an additional service more configuration, more moving parts, and more things to keep an eye on.

Enter Gitea actions

Once Gitea introduced native runner support with Gitea Actions, things became much simpler. If you’ve used GitHub Actions before, you’ll feel right at home. The workflow syntax is nearly identical, YAML-based, and flexible enough for most automation needs.

Instead of managing an external CI system, workflows now live directly inside my repositories. Gitea runners execute these jobs locally, giving me a GitHub Actions like experience while keeping everything self-hosted.

Why the switch

The move away from Woodpecker wasn’t about dissatisfaction, it was about simplification. With Gitea Actions:

1. CI/CD is tightly integrated with the Git platform
2. Workflows live alongside the code
3. Runner management is straightforward
4. There’s minimal learning curve for anyone familiar with GitHub Actions

Most importantly, it reduced overall complexity. One less service to manage means fewer failures and less maintenance overhead. My current workflow for this very own site looks something like this:

name: Build Zola
run-name: ${{ gitea.actor }} building Zola 🚀
on: [push]

jobs:
  build-zola:
    runs-on: prod
    container:
      volumes:
        - /data-pool-2/webstack/aurora/public:/builds/aurora
    defaults:
      run:
        shell: sh
    steps:
      - name: Install dependencies
        run: apk add --no-cache nodejs npm zola
      - name: Checkout
        uses: actions/checkout@v4
      - name: Build Site
        run: |
          zola -c config.prod.toml build
          chown -R 1001:1001 /builds/aurora
      - run: echo "Job completed with status ${{ job.status }}."

How this fits into my homelab

Gitea and its runners run as containers in my homelab. Builds happen locally, artifacts stay within my network, and deployments never leave my infrastructure. For personal projects, this setup provides an excellent balance between control and convenience.

Gitea has grown into much more than just a lightweight Git server. With native CI/CD support, it’s now a complete, self-hosted development platform. If you’re someone who’s looking to self-host a GIT server, it’s worth giving Gitea a shot!

I’ll see you in the next one.