Gitea: lightweight self-host Git server with Gitea Actions

What is Gitea?

Gitea is a Git hosting server written in Go that largely replicates GitHub functionally while running fully self-host. The project started in 2016 as a fork of Gogs (after Gogs maintainer activity declined) and as of May 2026 is in version 1.22 – an established player with over 45,000 GitHub stars and an active community.

Licence: MIT – fully free, no clauses. Since 2022 Gitea Ltd. exists as a commercial entity offering Gitea Cloud – but the open-source core remains MIT and fully self-hostable. That triggered a late-2022 licensing dispute that birthed Forgejo as a Codeberg fork. In May 2026 both projects are functionally near-identical, with slightly different release cadences.

Architecture: one Go binary plus a database (SQLite, MySQL, or PostgreSQL). The binary is around 130 MB, RAM footprint at idle around 100 MB. Gitea therefore runs comfortably on a 1-vCPU server with 1 GB RAM. Compared to GitLab Omnibus (4 GB RAM minimum, Postgres + Redis + nginx + Sidekiq), Gitea is drastically more frugal.

Feature scope: repositories, issues, pull requests, code review, wiki, releases, container registry (OCI-compliant), package registry (npm, pypi, maven, NuGet, Helm, Gem, Cargo, Conan, Debian, RPM), SSH/HTTPS access, webhooks, OAuth2 provider, LDAP integration. Since 2023: Gitea Actions – GitHub-Actions-compatible YAML pipelines.

May 2026 status: Gitea 1.22 stabilises the Actions engine, improves performance on large repositories, and adds advanced security features (TLS pinning, GPG signatures, action token scopes). The default choice for SME self-host in 2026.

Why it matters

Gitea solves two hard problems for Swiss SMEs: data residency and lock-in.

Data residency: source code is a trade secret. Anyone building client software, internal tooling, or proprietary algorithms should not park code on a US server. GitHub is owned by Microsoft, servers sit in the US, the CLOUD Act gives US authorities access rights. For Swiss fiduciary clients under professional secrecy (Art. 321 SCC) that is problematic – Gitea self-host on Hetzner Falkenstein definitively resolves it.

Lock-in: GitHub workflows do not port trivially via issue-tracker tools. Later migration is painful. Gitea is Git-repository standard with a built-in migration tool to/from GitHub – migration in both directions in under an hour for standard SME repos.

SME suitability: Gitea setup is a docker-compose file and 10 minutes. Compared to GitLab Omnibus (1-2 days setup, high learning curve, monitoring needed), Gitea is the markedly more rational choice for 1-15-person teams. Functionally the differences are small – issues, PRs, reviews, CI/CD all work in Gitea like in GitLab.

Licence cost: zero. MIT licence without restrictions. GitHub Team is USD 4 per user per month – 5 developers USD 240/year. GitLab Premium USD 29 per user/month – 5 devs USD 1740/year. Gitea: zero per user, only hardware cost (Hetzner CX22 CHF 6/month = CHF 72/year).

Gitea Actions as game changer: since 2023, Gitea is no longer "Git-only" but a full CI/CD platform. Workflows live in .gitea/workflows/*.yml – syntax almost 1:1 compatible with GitHub Actions. GitHub workflows can be adopted directly with minimal changes.

Compliance advantage: for regulated sectors (fiduciary, law, insurance) the audit trail is easier to maintain. Gitea logs, Postgres audit logs, and Gitea-own activity logs are all on-premise – no third-party access, clean line for DPIA documentation.

How it works

Gitea runs as a single Go binary. Configuration in an INI file (app.ini), data in a directory (data/) plus database.

docker-compose.yml example:

```yaml services: gitea: image: gitea/gitea:1.22 environment: USER_UID: 1000 USER_GID: 1000 GITEA__database__DB_TYPE: postgres GITEA__database__HOST: db:5432 GITEA__database__NAME: gitea GITEA__database__USER: gitea GITEA__database__PASSWD: ${DB_PASSWORD} volumes: - gitea-data:/data ports: - "3000:3000" - "22:22" depends_on: [db] restart: unless-stopped db: image: postgres:16 environment: POSTGRES_USER: gitea POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_DB: gitea volumes: - db-data:/var/lib/postgresql/data restart: unless-stopped volumes: gitea-data: db-data: ```

After first start: browser to http://server:3000, click through the installation wizard, create admin, done. Behind an nginx reverse proxy with Lets-Encrypt cert this runs in production at git.firm.ch.

Gitea Actions setup: an additional runner container executing actions.

```yaml runner: image: gitea/act_runner:latest environment: GITEA_INSTANCE_URL: https://git.firm.ch GITEA_RUNNER_REGISTRATION_TOKEN: ${RUNNER_TOKEN} volumes: - /var/run/docker.sock:/var/run/docker.sock - runner-data:/data ```

After that, every .gitea/workflows/*.yml file runs on push – build, test, deploy, container push.

Container registry: integrated. A Docker image can be pushed directly to git.firm.ch/owner/image:tag without a separate registry service. Authentication via Gitea user or token.

Backup: simple strategy. Postgres dump plus rsync of the data/ directory (contains LFS objects, avatars, issue attachments). Restore: copy data directory back, replay Postgres dump, done. Backup cron daily, retention 30 days, classic.

LDAP/OAuth: Gitea can bind to LDAP/AD (for companies with central identity) or serve as an OAuth2 provider for other apps. Single sign-on in an SME toolchain is therefore possible without an extra component.

Setup in 5 steps

1. 01Create docker-compose with gitea:1.22 plus postgres:16, persist volumes, expose ports 3000 and 22.
2. 02Walk through the install wizard: Postgres for database (SQLite only for tests), admin account with strong password, SSH keys for push access.
3. 03nginx reverse proxy on git.firm.ch with Lets-Encrypt cert, HSTS header, rate limit on /login endpoint.
4. 04Deploy Gitea Actions runner: act_runner container with registration token, Docker socket mount, write first .gitea/workflows/test.yml.
5. 05Set up backup cron: pg_dump + rsync data/ to a second disk or Hetzner Storage Box, daily, 30-day retention.

When to use Gitea

Gitea is the right choice when (a) the team has 1 to 20 developers, (b) code should stay in Switzerland/EU, (c) setup time under half a day is expected, (d) the budget does not allow GitLab Premium or GitHub Enterprise.

Concrete SME cases: a fiduciary office with an internal tooling team (2-3 people) – Gitea as code home plus Gitea Actions for build/deploy of Bexio integrations. A law firm with a self-built client platform – Gitea hosts code, Actions deploy automatically on every push. A SaaS boutique with 5-10 developers – Gitea as central hub for issues, reviews, releases, container registry.

Gitea also fits compliance-driven mandates well: fiduciary software processing client data should be versioned under professional-secrecy protection. Gitea self-host solves that without having to explain commercial vendors.

When not to use

Gitea is the wrong choice when (a) the project is open source and needs community discoverability – GitHub is strategically better, (b) the team is over 25 developers and needs enterprise features like very granular permissions or compliance-grade audit logs – GitLab Premium fits better, (c) very large monorepos (5+ GB) need hosting – Gitea works, but GitLab or GitHub Enterprise are more optimised.

Pitfalls: running Gitea without backup – a disk crash takes all repos and issues. Daily backup cron is mandatory. Running Gitea Actions without resource limits – a misconfigured build can fill the host. Keeping the Gitea database on SQLite as the team grows – migrate to Postgres at about 10 users.

Not recommended: running Gitea as a sidecar to GitHub – synchronising both repos in parallel is configuration pain. Decide: either GitHub or Gitea, not both. Exposing Gitea directly to the internet without a TLS reverse proxy – brute-force attacks on SSH port 22 are daily.

Trade-offs

FAQ

Related topics

Sources

1. Gitea – Documentation · 2026-05
2. Gitea – GitHub repository · 2026-04
3. Gitea Actions – Workflow syntax · 2026-03
4. Forgejo – Codeberg fork comparison · 2026-04