Gitea 28.0.0 drops 1.x versioning, adds audit logging, bot accounts and HTTPS deploy tokens

Gitea has shipped version 28.0.0, and the version number itself is the first piece of news: the project has dropped the "1." prefix it has carried since its early days, so the release is numbered 28.0.0 rather than 1.28.0. According to the Gitea release announcement, the update also brings audit logging, bot accounts, HTTPS deploy tokens, administrator impersonation, code-owner approval rules, diff file filters and a new Actions queue view.

Administration gains audit trails, impersonation and bots

The most consequential addition for operators is audit logging. Once enabled, Gitea records security-relevant events and shows them in the admin panel as well as in organization, repository and user settings, with filters for actor, action and origin plus JSONL export. The feature is switched off by default and keeps entries for 30 days unless configured otherwise; setting retention to zero preserves them indefinitely.

Administrators can now also impersonate a user to view the instance exactly as that person sees it, which makes it easier to reproduce permission problems without ever needing their password. The session displays a banner with a route back to the administrator account, and when audit logging is on, events capture both identities involved.

Bot accounts target automation workloads. They authenticate exclusively with access tokens, cannot sign in interactively, and receive no notifications or email. Administrators can create them, manage their tokens, and convert eligible local accounts between the user and bot types via the admin interface, API or command line.

Two infrastructure changes also landed. A new [redis] configuration section lets deployments define a single connection string that becomes the default for cache, session, queue, global lock and WebSocket pub/sub. Meanwhile, notification counts, stopwatch updates and logout events now use a WebSocket instead of server-sent events: reverse proxies must forward WebSocket upgrade headers or clients fall back to polling, and multi-process deployments need Redis-backed pub/sub.

Collaboration: deploy tokens, code owners and diff filtering

Deploy tokens give repositories an HTTPS-based counterpart to SSH deploy keys. Each token is tied to a single repository, grants either read-only or read-write access, and works as the password for Git and LFS operations over HTTPS. Deploy tokens and personal access tokens can both be regenerated in place.

For code review, a new branch protection option can block merging until each matching CODEOWNERS rule has been approved by one of its owners or a member of a listed team. The diff file tree gains a search box and a file-extension filter — the filter persists in the URL, so a narrowed view can be shared — and the repository watch button has been rebuilt as a menu with finer-grained notification options.

Breaking changes to review before upgrading

The announcement lists several defaults that have moved. Git network operations such as migrations, mirrors, webhooks and OAuth2 now pass through an internal proxy enforcing refreshed egress rules. The external preset is gone; strict mode works as a default-deny policy in which host entries without a port only allow ports 80 and 443, IP entries no longer accept wildcards, and domain matching follows curl's syntax. Older migration allow and deny settings are deprecated in favour of new host lists, and invalid blocked-host entries will stop Gitea from starting.

Actions users should note that completed runs — including their jobs, logs and artifacts — are now deleted after 400 days by default through a new nightly cleanup task; setting retention to zero keeps everything. Gitea also refuses to start on Git versions older than 2.25.0.

Self-registration is now disabled unless explicitly turned on, and the [server] DOMAIN setting is no longer read: the instance domain, including the default SSH domain, comes from ROOT_URL instead. Workflow authors face changes as well, since job-level conditions are evaluated before matrix expansion with a limited set of contexts, matrix fail-fast behaviour is enforced, public repositories can no longer call reusable workflows from private ones, and nested workflows cannot exceed the caller's token permissions.

On packaging, release binaries drop 32-bit x86 and gogit builds, the Snap package is no longer built for armhf, and download filenames have lost their OS version suffix, so scripted downloads need updating.

Security fixes land quietly, for now

The release contains security fixes, but the Gitea team is withholding details for roughly a week to give operators time to upgrade first. That makes the recommended sequence — back up, read the breaking changes, then replace the binary or container and restart — more than a formality.

Why it matters

The renumbering is cosmetic; the substance signals where Gitea is heading. Audit logging, impersonation and bot accounts are governance features that organisations weigh when choosing a forge, and deploy tokens close a long-standing gap against GitHub and GitLab. At the same time, this is one of the more demanding upgrades in the project's recent history: egress handling, registration defaults, Actions data retention and real-time notifications all change behaviour, and some misconfigurations now block startup entirely. Operators should treat the move to 28.0.0 as a small project rather than a routine binary swap.