migrating from gitlab to gitea
GitLab is a full software development platform. it's also a 4GB+ container that idles at 4GB of RAM on a good day. for a homelab running half a dozen compose repos and a personal blog, that's a lot of overhead. Gitea does what actually gets used at a fraction of the cost.
what gitlab was being used for
the honest answer: git hosting and Portainer webhook integration. that's it. no CI/CD pipelines, no issue tracking, no merge requests, no container registry. just a place to push compose files so Portainer could pull from them.
GitLab was installed because it's familiar from work. it stuck around because switching takes effort.
the problem
GitLab needs regular updates, takes several minutes to fully start, and requires enough RAM that running it alongside the actual workloads required keeping an eye on memory pressure. the admin UI is complex relative to what it's actually being used for. for five compose repos and a personal blog, this is significant overkill.
gitea
Gitea is a self-hosted git service written in Go. the entire thing runs in a single container under 100MB of RAM at idle. it has a clean UI, supports SSH and HTTPS remotes, webhooks, deploy keys, and a full API. the web interface is fast.
most importantly: Gitea Actions is GitHub Actions-compatible syntax. the CI/CD for the blog (push to main, SSH into the server, rebuild Docker container) was written once and works the same as it would on GitHub.
what we gained
- memory footprint dropped significantly — Gitea idles at under 100MB vs GitLab's 4GB+
- faster startup — Gitea is up in seconds, GitLab takes minutes
- the same Portainer integration works unchanged — just updated the repo URLs
- Gitea Actions for the blog CI/CD uses standard GitHub Actions syntax, so the workflow is portable
what we lost
nothing that was actually being used. GitLab's extra features (container registry, advanced merge request workflows, built-in CI with runners) weren't in use. if they were needed, GitLab would be the right choice.
the migration
migrating five repos takes about 20 minutes:
- create repos in Gitea via API
- add the Gitea remote to each local clone
- push all branches
- update Portainer stacks to point at Gitea repo URLs
- update any deploy keys or webhooks
Portainer doesn't care which git server it's pulling from — changing the repo URL in the stack config and redeploying is all it takes.
GitLab was stopped but not deleted. the volumes stayed intact for a few weeks as a safety net, then removed once everything was confirmed working.
one gotcha
Gitea's default branch on new repos is master. Portainer defaults to looking for main. either update the default branch setting in Gitea's admin panel, or rename the branch on the repo after creation. the Portainer stack config also lets you specify the branch explicitly — refs/heads/main — which overrides whatever the remote default is.
eli5
GitLab is like renting a full commercial kitchen to make your morning coffee. it's extremely capable, but almost none of that capability is being used, and it takes up a lot of space. Gitea is like a good home coffee maker — it does the one thing you need (store and serve git repos) reliably and without wasting half the room. the migration is like moving your coffee beans and mug from the commercial kitchen to the home machine: a bit of effort upfront, then everything works the same but takes up much less space.