Gitea
temaki.gitea
A Docker Compose file for Gitea alone, generated from the catalog and checked by the safety inspector. No account needed.
Self-hosted Git service with repository browsing, pull requests, issues, releases, package registries and a built-in CI runner, in a single binary with modest resource needs.
Gitea provides the collaboration layer around Git repositories — pull requests with review and branch protection, issues with labels and milestones, wikis, releases and organisation-level teams — from one Go binary that runs comfortably on hardware where heavier forge software will not. Gitea Actions offers workflow automation with syntax closely following the widely used format, executed by a separate runner process. Package registries cover the common ecosystems, so artefacts can live beside the code that produced them. A first deployment completes the installation screen, which fixes the database and the public URL, then creates the first account as administrator.
You know it worked when
- The installation completes and the administrator account can sign in.
- A repository can be created and cloned over both HTTP and SSH.
- A pushed commit appears in the repository view.
- A pull request can be opened, reviewed and merged.
- Repositories and issues survive a container restart.
Known sharp edges
- The installation page is unauthenticated and the first account registered becomes administrator, so the instance must not be publicly reachable before setup is finished.
- The public and SSH URLs are written into configuration at install time and appear in every clone command shown, so a later address change requires editing the configuration file.
- Repositories on disk and the configured database must be backed up together; a database restored against a mismatched repository directory produces missing or orphaned repositories.
- Actions workflows need a separately deployed runner registered with a token, and without one they queue indefinitely rather than reporting an error.