,

Gitea 28.0.0 Drops the 1.x Version Prefix, Adds Audit Logging

Close-up of source code running on a laptop screen in a data center

Gitea shipped version 28.0.0 on September 30, dropping the “1.” prefix the project had carried since its first stable release. The last version in the old line was 1.27.x; the next one is simply 28.0.0, not 1.28.0. It’s a small change on paper, but it says something about where the project sees itself now: less a perpetual 1.x work in progress, more a mature tool with its own independent version line.

The release notes, posted on the official Gitea blog, run long. Here’s what actually matters if you’re running your own instance.

Admin and security

The headline addition is audit logging. Gitea now records sensitive actions across admin settings, organizations, repositories, and user account changes, so instance owners can see who did what and when. Self-hosted Git forges have lagged behind GitLab and GitHub here for years, so this closes a real gap.

28.0.0 also introduces dedicated bot accounts that authenticate only with access tokens, never a password. That’s a cleaner setup for CI pipelines and automation scripts than reusing a human user’s login. On top of that, admins get an impersonation feature: they can view the instance as a specific user, which beats asking someone to screen-share just to reproduce a permissions bug.

One smaller but genuinely useful change: Redis configuration is now shared across subsystems instead of needing separate settings for caching, sessions, and queues. Anyone running Redis behind Gitea gets a shorter config file out of this.

Collaboration features

Repository-scoped HTTPS deployment tokens show up in this release, the HTTPS answer to SSH deploy keys. If you’ve stuck with HTTPS clones and avoided SSH key management, you now get a scoped-token option instead of handing out full account credentials.

Pull request reviews gain diff search and file-extension filtering, both useful on large PRs where scrolling through every changed file wastes time. Branch protection can now require approval from a code owner specifically, not just any reviewer with write access. There’s also a repository switcher in the header for moving between repos under the same owner, more granular per-repository notification settings, and REUSE-style license detection that handles multi-licensed repositories properly instead of assuming one license covers everything.

Actions and CI/CD

Gitea Actions gets queue visibility, so you can actually see which jobs are running or waiting instead of guessing from a blank screen. Artifact previews now render text files, images, PDFs, and HTML reports right in the browser. Build matrices evaluate dynamically, you can cap how many jobs run in parallel, and the workflow run list refreshes on its own instead of needing a manual reload.

Breaking changes to plan for

A handful of changes in 28.0.0 will break existing setups if you skip the config updates:

  • Git network operations like migrations and mirroring now route through an internal proxy with new egress rules. You’ll need to set EGRESS_MODE for these to keep working.
  • Completed Actions runs expire after 400 days by default. Set RUN_RETENTION_DAYS = 0 if you want to keep them indefinitely.
  • Git 2.25.0 or newer is now required on the server.
  • Self-registration is off by default. If your instance relies on open sign-ups, set DISABLE_REGISTRATION = false explicitly.
  • Workflow and matrix condition evaluation is stricter, which may change how existing Actions workflows behave.

What about security fixes?

The Gitea team kept most of the security details under wraps for this release, but confirmed a few fixes: invalid Git objects are now rejected outright, SSH key fingerprint identification has been improved, and pull requests coming from forks now get approval locks, closing off a known abuse path.

Gitea and Forgejo, still circling each other

Gitea and its fork Forgejo have kept a wary distance since the 2022 split, and this year gave both projects their own security scares. Gitea patched two critical vulnerabilities back in January with 1.27.1. Forgejo fixed a critical repository-template RCE, tracked as CVE-2026-89094, in its 16.0.4 and 15.0.8 builds in September. Neither incident should weigh much on which one you pick today. 28.0.0 stands on its own as a substantial release, and the audit log alone is something self-hosters have wanted for a long time.

Should you upgrade?

If you’re running Gitea, read the breaking changes section before you touch the upgrade button, especially the egress mode and self-registration defaults. Those are the kind of setting that quietly locks out a mirror job or an expected sign-up flow if you don’t catch them first. The full write-up is on the official Gitea 28.0.0 release post. For context on how Gitea stacks up against Forgejo and GitLab for self-hosting, see our Gitea and Forgejo app pages.

Related guides