# Gitea: app.ini for the static half, the admin panel for the rest > Gitea is a self-hosted Git service written in Go, packaged as an all-in-one server with code review, issues, kanban, a wiki, a package registry and CI/CD that can reuse GitHub Actions. Its configuration is split in two, and its release line jumped from 1.27 to 28.0.0 in September 2026. **go-gitea/gitea** — Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD - Repository: https://github.com/go-gitea/gitea - Website: https://gitea.com - Stars: 58,222 · Forks: 7,190 - Language: Go - License: MIT - Published: 2026-08-04 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/go-gitea-gitea ## The release line jumped from 1.27 to 28.0.0 The release list contains v28.0.0 dated 2026-09-29, then v1.27.3 dated 2026-08-29 and v1.27.2 dated 2026-08-13, and the last push to main landed the same day as the 28.0.0 tag. A jump from a 1.x series to a 28.0.0 tag is the single most consequential fact for anyone automating against this project, because image tags, pinned versions in scripts and documentation references that assume a 1.x line all have to be revisited at once. The tree shows how the project itself keeps history: CHANGELOG.md sits at the root next to CHANGELOG-archived.md, so the record is split between the current line and everything archived behind it. Read the changelog diff for the 28.0.0 tag before assuming a minor upgrade, because the number of components in the all-in-one server is large and the version number is no longer a guide to the size of the change. ## Static options need app.ini and a restart, dynamic ones need the admin panel The configuration model is the part of Gitea most likely to surprise an operator, and the README states it plainly. Dynamic config options are changed in the admin panel's configuration section. Static options are edited in the app.ini file, and the instance has to be restarted for them to apply. The example file is app.example.ini under custom/conf, and the configuration cheat sheet on the documentation site covers the rest. A custom/ directory sits at the repository root, which is where that configuration tree lives, and it is also the conventional place to drop templates and other instance-specific files. The consequence for a fleet: anything you would want to templat across ten instances goes in app.ini and needs a restart, while the admin panel is per instance and interactive, so two installations can quietly diverge in their dynamic settings. ## The Go module is gitea.dev, and the project runs on itself go.mod declares module gitea.dev, with go 1.27 and toolchain go1.27.1, and a dependency list that reads like a map of the feature set. The HTTP layer is go-chi with cors and a proxy middleware, session and cache come from gitea.com/go-chi, search is blevesearch/bleve, scheduled jobs run on go-co-op/gocron, and the mail side pulls in emersion/go-imap and ProtonMail/go-crypto. Signing and verification show up as 42wim/httpsig and sshsig, and TLS is handled by caddyserver/certmagic. Two things follow. The import path is a domain, not a GitHub path, so anything vendoring or proxying this module resolves through gitea.dev. And the project's own infrastructure is Gitea: the documentation site, the documentation repository, the demo at demo.gitea.com and the package doc badge all live on Gitea instances. ## The frontend stage runs on the build host to avoid QEMU The Dockerfile is the clearest statement of how this thing gets built, and the first line of its comment explains the first stage: the frontend is built on the native platform to avoid QEMU related issues with the nodejs ecosystem. So the image is a two stage cross build, with a frontend stage running golang:1.27-alpine3.24, installing build-base, git, nodejs and pnpm, copying package.json, pnpm-lock.yaml and pnpm-workspace.yaml, and running pnpm install with a frozen lockfile before make frontend. The backend stage then copies the built assets across and runs make backend with the .git directory bind mounted, because version data is read from it. Two smaller details carry real consequences. The stage that copies the tree chmods the entrypoint and the s6 service directories to 755, because builds made on Windows strip the executable bit. And the final image exposes 22 and 3000, so both SSH and HTTP are in scope when you write a firewall rule. ## A Python manifest in a Go project, holding three linters pyproject.toml exists at the root of a Go codebase, and it is worth reading. The project name is gitea with version 0.0.0, so the version there is a placeholder and never the server version. requires-python is >=3.10, and the only dependency group is dev, holding djlint==1.46.2, yamllint==1.38.0 and zizmor==1.30.1. The djlint section sets profile to golang and ignores a specific list of rule codes, which means the HTML templates in the server are linted with the dialect Go templates need rather than the default. Yamllint covers the many YAML files, of which .yamllint.yaml and .spectral.yaml are themselves at the root. Zizmor is the interesting one, because it is a security linter aimed at CI workflow definitions, so a contributor is expected to catch unsafe workflow patterns locally before review. The consequence for anyone forking: the documented development setup expects a Python 3.10 toolchain even though the server itself is Go. ## Security patches are found by searching the changelog for the word SECURITY There is no advisory list in the README and no CVE index. The documented method is to look in the release log or in CHANGELOG.md and search for the keyword SECURITY, which is how you find the security patches among everything else. Reporting runs the other way: if you believe you have found a vulnerability you write privately to security@gitea.io, and there is a SECURITY.md at the root for the policy itself. For a team running an internal instance this is a real gap in practice. Deciding whether to upgrade means reading two changelogs by hand and searching them, and the granularity of that decision depends on the commit count between your current tag and the next one rather than on a machine-readable feed. If your process requires an advisory list, this project does not publish one in the places the README points to. ## The runner, the CLI and the SDK are separate installs Gitea does not ship everything in one box. The project maintains an official go-sdk, a command line tool called tea, and an action runner for Gitea Action, each at its own address on gitea.com, and it points to the awesome-gitea list for third-party SDKs, plugins and themes. The runner matters most for the CI claim, which is that the included CI/CD can reuse GitHub Actions: that compatibility is the reason a migration is cheap, and the reason a self-hosted runner becomes a separate machine or container you have to run, update and secure. On the hosting side there are four routes, each with a different cost: the free service at gitea.com with a limited number of repositories, a free trial at cloud.gitea.com, the official container image r/gitea/gitea for your own server, and a binary you build yourself, where ./gitea web starts the server and ./gitea help lists the commands. ## Conclusion Adopt Gitea when you need Git hosting with issues, pull requests, a package registry and CI on infrastructure you control, and when the team is willing to run the server themselves. Do not adopt it for the free hosted tier if your repositories are the point, since gitea.com is described as a free service with a limited number of repositories. Verify four things first. Which version line you are on, because v28.0.0 shipped on 2026-09-29 alongside patch releases in the 1.27 series and any automation pinning 1.x needs review. Whether your existing GitHub Actions workflows run unchanged, since reuse of that format is the project's own claim and your workflows are the test. That static settings go into app.ini and need a restart, while dynamic ones go through the admin panel. And how you will find security fixes, because the documented method is searching the changelog for the word SECURITY rather than tracking advisories. ## FAQ ### What is Gitea used for? It is a self-hosted, all-in-one software development service written in Go. It covers Git hosting, code review, issue tracking, project kanban, a wiki, team collaboration, a package registry, and CI/CD that can reuse GitHub Actions. ### What is the difference between Git and Gitea? Git is the version control system; Gitea is a server built around it. The repository describes itself as Git with a cup of tea, and the server adds hosting, pull requests, issues, a wiki, a package registry and CI on top of the Git protocol. ### Is Gitea completely free? The software is MIT licensed and the project is funded through OpenCollective backers and sponsors. The hosted service at gitea.com is free with a limited number of repositories, and cloud.gitea.com offers a free trial for a dedicated instance. ### How do I install Gitea? The documentation site covers installation, administration and usage, and the build documentation at docs/build-setup.md lists the prerequisites for building from source. The module requires Go 1.27 with toolchain go1.27.1, and after building you start the server with ./gitea web or list commands with ./gitea help. ### How do I run Gitea with Docker? The project points at the official image r/gitea/gitea on Docker Hub for your own server, and the repository Dockerfile exposes ports 22 and 3000. A Dockerfile.rootless also exists in the tree, and a free trial on Gitea Cloud is the other hosted option. ### How do I install the Gitea runner? The project provides an official action runner for Gitea Action as a separate project, since the CI/CD system is meant to reuse GitHub Actions workflows. An official go-sdk and a command line tool called tea are maintained the same way, apart from the server itself. ## Sources - [Official documentation](https://gitea.com) - [Official README](https://github.com/go-gitea/gitea#readme) - [Project repository](https://github.com/go-gitea/gitea) - [Release notes](https://github.com/go-gitea/gitea/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/go-gitea-gitea