Category: Development
Managed Gitea: lightweight Git and your own CI on your server
Repositories, code reviews and pipelines in a single application that fits on a small server, with backups we actually restore and upgrades without surprises.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
- Licence
- Open source, MIT
In short
Gitea is a lightweight code forge written in Go that brings Git repositories, issues, pull requests, packages and CI together in a single binary. We install it in your account or on your server, connect it to your sign-in, set up the Gitea Actions runners, take full backups that we restore in tests and keep it up to date.
What do we look after?
Gitea starts in a minute, and that is why it is often left as it is: a container with SQLite, no backups and the runner on the same machine. While the team is three people, nothing happens. Once the company’s code lives there, every piece needs someone behind it:
Repositories
Properly sized disk storage, with Git garbage collection and warnings before it fills up.
Database
PostgreSQL for users, issues and pull requests, with backups independent from the repository ones.
Actions runners
act_runner on separate machines, with isolated containers per job and image cleanup.
Access
SSH, HTTPS, tokens and deploy keys, with single sign-on and two-factor authentication.
Packages
Container, npm, Maven and other registries, with policies so that not every version is kept forever.
Monitoring
Disk, certificates, the internal task queue and runners that stop responding.
Which architecture do we recommend?
Gitea does not need a big platform. The separation that is worth making is between the forge and whatever runs other people’s code:
Reverse proxy
Terminates HTTPS, limits upload size and lets Git SSH through on its own port.
Gitea
A single process that serves the web, the API and Git. The repositories go on their own volume, not on the system disk.
PostgreSQL
Managed by the provider or set up by us, with separate backups. SQLite only for testing.
Runners
act_runner on another machine: a pipeline that runs out of control must not bring down the forge or read its data.
Attachments, Actions artefacts and packages go to S3-compatible object storage once they grow, so that the server disk only holds the repositories.
Which problems do we find in a self-hosted Gitea?
- SQLite with the whole team on it: write locks when several people comment and merge at the same time.
- Runner on the same server: a job that fills the disk with images leaves the repositories with no space.
- Package registry with no cleanup: every build pushes a new image and nobody deletes the old ones.
- SSH port conflict: the system SSH and Gitea’s compete and
git pushfails without a clear message. - Skipped versions: jumping from a very old version straight to the latest leaves the database migration half done.
- Local users nobody removes: with no connection to the directory, people who leave keep their access to the code.
How do we handle backups and upgrades?
Gitea comes with gitea dump, which packages repositories, database, configuration and attachments. We use it on small instances; on large ones we back up the database separately with its native tool and the repositories with an incremental backup, because a full daily dump of several hundred gigabytes makes no sense. In both cases the backup leaves the server and, every so often, we bring up a separate instance from it, clone a repository and open a pull request to check that everything fits together.
Gitea publishes minor releases with fixes often and a major one every few months. We read the notes, upgrade a copy of your instance first, check that the runners still connect and then upgrade production in an announced window. If you are several versions behind, we go from major to major, with no shortcuts.
How do we protect the instance?
We disable open registration, enforce two-factor authentication or delegate it to your Keycloak through OpenID Connect, and review which repositories are public. The runners execute each job in a disposable container, with no access to the internal network beyond what is essential, and Actions secrets are stored per repository or organisation, never in the code. If Gitea does not need to be visible from the internet, we keep it behind the VPN.
How do we migrate from GitLab or GitHub?
Gitea has a migration wizard that brings over each repository with its history and, if the source allows it, its issues, pull requests, labels and releases. We prepare the list of organisations, teams and permissions beforehand, because that structure does not move on its own. GitLab CI pipelines have to be rewritten as Actions workflows; GitHub Actions ones usually work with few changes. We keep the source read-only for a few days until nobody misses it.
If what you need is the complete platform, deployments included, it is in internal platform and PaaS. If you are still unsure between the two forges, the managed self-hosted GitLab page will help you compare.
Where do we set it up?
In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.
Providers we set it up on
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Own server
| Provider | How we set it up | Things to bear in mind |
|---|---|---|
| Hetzner | One cloud server for Gitea and PostgreSQL, and another for the runners. Repositories on a volume and backups to Hetzner Object Storage, which is S3-compatible. | Gitea uses few resources: a modest server is enough for a whole team. What grows most is the repository disk. |
| AWS | Gitea on EC2 with an EBS volume, RDS for PostgreSQL and S3 for attachments, packages and backups. | The runners can use spot instances if the jobs can tolerate an interruption. |
| Google Cloud | Compute Engine with a persistent disk, Cloud SQL for PostgreSQL and Cloud Storage for attachments and backups. | A good fit if the rest of your platform already lives on Google Cloud. |
| Azure | A virtual machine with a managed disk, Azure Database for PostgreSQL and Blob Storage for the backups. | Sign-in connects to Microsoft Entra ID through OpenID Connect. |
| DigitalOcean | A Droplet with Gitea, a managed PostgreSQL database and Spaces for attachments and backups. | |
| OVH | A Public Cloud instance, an OVHcloud managed database and Object Storage for the backups. | |
| Own server | Gitea and PostgreSQL in containers on your server or in a virtual machine, alongside your directory. | If access is internal only, we keep it behind the VPN and publish, at most, the webhooks that need it. |
What is included
- Gitea in your cloud account or on your server, in your company's name, with the configuration (app.ini) in your repository.
- PostgreSQL as the database instead of SQLite once the team works with the instance every day.
- Gitea Actions runners (act_runner) on separate machines, with labels per type of job.
- SSH and HTTPS access behind a reverse proxy, with sign-in through OpenID Connect or LDAP.
- Package and container registry enabled if you use it, with cleanup of old versions.
- Daily backups of repositories, database and attachments, with a regular test restore.
- Upgrades following each release's notes, tested first on a copy.
- Migration of repositories, issues and pull requests from GitLab, GitHub or another forge.
Frequently asked questions
Is Gitea a good lightweight alternative to GitLab?
For many teams, yes. It offers repositories, reviews, issues, packages and CI with far fewer resources and fewer pieces to maintain. It falls short if you need portfolio planning, built-in security scanning or very fine-grained permissions across hundreds of groups; there GitLab goes further.
Will our GitHub Actions workflows work in Gitea Actions?
Largely, because the syntax is compatible and many public actions work as they are. There are differences: some actions depend on the GitHub API and not every option is implemented. We review your workflows one by one and adapt the ones that fail.
Gitea or Forgejo?
Forgejo is a community fork of Gitea that now follows its own path, with its own release schedule and its own governance. For everyday use they are very similar. We maintain either; if you already have one, the normal thing is to stay with it, and if you are starting from scratch we discuss it based on what matters most to you.
Can we bring our repositories over from GitLab or GitHub without losing the history?
Yes. Gitea's migration copies the full Git history and, depending on the source, also issues, pull requests, labels, milestones and releases. What does not move on its own is pipelines, secret variables and webhooks, which we prepare separately.
Who manages users and permissions?
Your company's administrator, from Gitea or from your directory if it is connected through LDAP or OpenID Connect. We take care of the server, the runners, the backups and the upgrades.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Official documentation consulted
The technical details on this page are based on:
Reviewed on