![\"Mascote](\"\/wp-content\/uploads\/2026\/10\/gitea-28-novidades-v1.webp\")
<\/p>\n<\/p>\n
O Gitea pulou da 1.27 para a 28 \u2014 e n\u00e3o, n\u00e3o foram 27 vers\u00f5es perdidas. A 28.0.0<\/a>, anunciada em 30 de setembro de 2026, \u00e9 a vers\u00e3o que se chamaria 1.28.0: o projeto simplesmente abandonou o \u201c1.\u201d que nunca sa\u00eda do lugar. Por tr\u00e1s do n\u00famero novo h\u00e1 uma release grande, com log de auditoria, contas de bot, deploy tokens, impersona\u00e7\u00e3o pelo administrador e v\u00e1rias melhorias nas Actions \u2014 e mudan\u00e7as incompat\u00edveis que exigem revisar seguran\u00e7a, reten\u00e7\u00e3o e workflows antes de atualizar. Este post resume o que mudou e conta o que aprendemos atualizando uma inst\u00e2ncia de produ\u00e7\u00e3o.<\/p>\n Desde o fork do Gogs, em 2016, o Gitea numerava as vers\u00f5es como 1.x. O primeiro n\u00famero nunca mudou; quem carregava a informa\u00e7\u00e3o era o segundo. A partir desta release, esse segundo n\u00famero passou para a frente: 1.27 \u2192 28. N\u00e3o h\u00e1 reescrita nem quebra geral de compatibilidade por causa do n\u00famero \u2014 h\u00e1 mudan\u00e7as incompat\u00edveis que precisam ser avaliadas, descritas mais abaixo.<\/p>\n O efeito pr\u00e1tico \u00e9 em automa\u00e7\u00e3o: scripts que procuram tags Um recurso importante para quem administra Gitea em empresa. Eventos relevantes de seguran\u00e7a passam a ser registrados no estilo do GitHub: a\u00e7\u00e3o, autor, escopo, origem (interface, API, CLI ou sistema) e metadados. Os eventos aparecem nas configura\u00e7\u00f5es do administrador, da organiza\u00e7\u00e3o, do reposit\u00f3rio e do usu\u00e1rio, com filtros. A\u00e7\u00f5es feitas durante uma impersona\u00e7\u00e3o registram as duas pessoas.<\/p>\n O detalhe que importa: a grava\u00e7\u00e3o vem desligada<\/strong>. Para ligar, no A limpeza dos eventos antigos \u00e9 feita pela tarefa Automa\u00e7\u00e3o no Gitea costumava significar criar um usu\u00e1rio comum, gerar um token e torcer para ningu\u00e9m logar com ele. A 28 traz contas de bot<\/strong> de verdade: usu\u00e1rios sem senha, que s\u00f3 autenticam por token, n\u00e3o recebem notifica\u00e7\u00f5es nem e-mails e n\u00e3o conseguem abrir sess\u00e3o interativa \u2014 nem por login, nem por proxy reverso, nem por fonte externa. Elas podem ser administradas pela interface, pela API ou pela CLI. O comando Os deploy tokens<\/strong> s\u00e3o o par das deploy keys para HTTPS: uma credencial limitada a um reposit\u00f3rio, com leitura ou leitura e escrita, usada como senha numa opera\u00e7\u00e3o Git \u2014 inclusive LFS. Servem para o servidor de produ\u00e7\u00e3o puxar um reposit\u00f3rio sem chave SSH e sem a conta de uma pessoa.<\/p>\n Completam o pacote os tokens pessoais regener\u00e1veis<\/strong>: d\u00e1 para trocar o valor de um token mantendo nome e permiss\u00f5es, \u00fatil quando ele vazou ou foi entregue a terceiros \u2014 o pr\u00f3prio PR cita o caso de um token passado a um agente de IA.<\/p>\n As Actions \u2014 o CI\/CD embutido, com YAML compat\u00edvel com o da GitHub Actions \u2014 ganharam:<\/p>\n No lado do executor, o runner chegou \u00e0 4.1.0 em 1\u00ba de outubro, com um backend para rodar os jobs no Kubernetes.<\/p>\n Comece pela reten\u00e7\u00e3o dos dados e pelas permiss\u00f5es de sa\u00edda. H\u00e1 outros requisitos de compatibilidade na se\u00e7\u00e3o seguinte.<\/p>\n At\u00e9 a 1.27, execu\u00e7\u00f5es conclu\u00eddas ficavam no banco para sempre. A 28 cria o Aten\u00e7\u00e3o ao Migra\u00e7\u00f5es, espelhos e outras opera\u00e7\u00f5es de rede do Git agora passam por um proxy interno, que aplica as regras de egress \u00e0s conex\u00f5es diretas. As regras ganharam um modo:<\/p>\n O alerta das notas de vers\u00e3o \u00e9 espec\u00edfico: em H\u00e1 uma exce\u00e7\u00e3o importante na migra\u00e7\u00e3o de configura\u00e7\u00e3o: em As listas controlam conex\u00f5es diretas. Se houver um proxy de sa\u00edda configurado, o bloqueio dos destinos encaminhados passa a ser responsabilidade desse proxy.<\/p>\n Al\u00e9m disso:<\/p>\n Esses pontos fazem parte das mudan\u00e7as incompat\u00edveis documentadas pelo projeto<\/a>.<\/p>\n Na atualiza\u00e7\u00e3o de uma inst\u00e2ncia instalada como bin\u00e1rio com systemd e MySQL, com runner pr\u00f3prio e espelhos, tr\u00eas pontos mereceram aten\u00e7\u00e3o.<\/p>\n A configura\u00e7\u00e3o legada de migra\u00e7\u00f5es merecia revis\u00e3o.<\/strong> O Uma configura\u00e7\u00e3o expl\u00edcita com a lista nova pode usar o modo estrito. N\u00e3o \u00e9 uma equival\u00eancia exata: entradas sem porta passam a permitir apenas 80 e 443. Al\u00e9m disso, O exemplo permite redes privadas e loopback: remova esses presets se n\u00e3o forem necess\u00e1rios e prefira destinos espec\u00edficos. Confira tamb\u00e9m de onde v\u00eam os espelhos \u2014 no modo estrito, um Git interno numa porta como 3000 precisa de uma entrada com a porta, como O hist\u00f3rico de Actions seria parcialmente apagado.<\/strong> Com o padr\u00e3o de 400 dias, execu\u00e7\u00f5es acima desse prazo seriam removidas na limpeza agendada. Definimos O nginx n\u00e3o repassava o WebSocket.<\/strong> Depois do upgrade, o handshake em Para uma configura\u00e7\u00e3o nova, o exemplo abaixo usa o Para testar, sem navegador:<\/p>\n Depois de receber As notifica\u00e7\u00f5es continuam funcionando se voc\u00ea esquecer \u2014 a interface cai para consulta peri\u00f3dica \u2014, mas as notifica\u00e7\u00f5es deixam de ser instant\u00e2neas. Quem usa o Caddy<\/a> na frente n\u00e3o precisa fazer nada: o No proxy nginx 1.18.0 verificado, acrescentar O passo a passo completo de instala\u00e7\u00e3o \u2014 Docker Compose com MariaDB, bin\u00e1rio com systemd, runner e tea CLI \u2014 est\u00e1 no guia Gitea: Git self-hosted com Actions, runner e tea CLI<\/a>, j\u00e1 atualizado para a 28.<\/p>\n A 28 traz corre\u00e7\u00f5es de seguran\u00e7a, entre elas a rejei\u00e7\u00e3o de objetos Git inv\u00e1lidos ou duplicados no push, a identifica\u00e7\u00e3o de chaves SSH por impress\u00e3o digital, a garantia de que execu\u00e7\u00f5es de PR vindas de fork continuem esperando aprova\u00e7\u00e3o mesmo depois de canceladas, uma corre\u00e7\u00e3o de nega\u00e7\u00e3o de servi\u00e7o no SSH e a verifica\u00e7\u00e3o de autoriza\u00e7\u00e3o por reposit\u00f3rio em acessos de times, exclus\u00f5es e pacotes. Os detalhes completos \u2014 com identificadores e gravidade \u2014 ficaram para cerca de uma semana depois do lan\u00e7amento e, at\u00e9 5 de outubro de 2026, ainda n\u00e3o tinham sido publicados. Isso, por si s\u00f3, j\u00e1 \u00e9 motivo para n\u00e3o adiar o upgrade.<\/p>\n Sim, depois de revisar as mudan\u00e7as incompat\u00edveis e ter um backup restaur\u00e1vel. A 28 \u00e9 uma release de amadurecimento: auditoria, bots, deploy tokens e aprova\u00e7\u00e3o por code owners ampliam os controles dispon\u00edveis para equipes, sem perder o que sempre foi sua vantagem \u2014 um bin\u00e1rio, um banco e pouca mem\u00f3ria. O n\u00famero novo assusta mais do que a atualiza\u00e7\u00e3o.<\/p>\n Leia tamb\u00e9m: a hist\u00f3ria do GitLab<\/a>, o Gogs, de onde o Gitea saiu<\/a> e DevOps: o que \u00e9 CI\/CD?<\/a>.<\/p>\n Refer\u00eancias: release 28.0.0<\/a>, configura\u00e7\u00f5es do Gitea<\/a> e runner 4.1.0<\/a>. Revisado em 5 de outubro de 2026.<\/p>\n","protected":false},"excerpt":{"rendered":" Audit, bots, deploy tokens, and Actions in Gitea 28: what changed and the precautions with retention, egress, and WebSocket before upgrading.<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[46,2,25,120],"tags":[105,48,201,240,479,203],"class_list":["post-1802","post","type-post","status-publish","format-standard","hentry","category-devops","category-linux","category-noticias","category-servidores","tag-ci-cd","tag-git","tag-gitea","tag-nginx","tag-seguranca","tag-self-hosted"],"_links":{"self":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/1802","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/comments?post=1802"}],"version-history":[{"count":3,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/1802\/revisions"}],"predecessor-version":[{"id":1806,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/1802\/revisions\/1806"}],"wp:attachment":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/media?parent=1802"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/categories?post=1802"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/tags?post=1802"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Por que 28 e n\u00e3o 1.28<\/h2>\n
1.*<\/code>, comparam vers\u00f5es como texto ou montam a URL de download na m\u00e3o. Junto com a mudan\u00e7a, a 28 deixou de publicar bin\u00e1rios x86 de 32 bits e as variantes gogit<\/code>, e os nomes de arquivo perderam o sufixo de vers\u00e3o do sistema operacional. Para Linux amd64, o bin\u00e1rio continua em https:\/\/dl.gitea.com\/gitea\/28.0.0\/gitea-28.0.0-linux-amd64<\/code>, com .sha256<\/code>, assinatura GPG e pacote Sigstore ao lado.<\/p>\nLog de auditoria<\/h2>\n
app.ini<\/code>:<\/p>\n[audit]\nRECORD_OUTPUT = database\nRETENTION_DAYS = 90 ; padr\u00e3o 30; 0 guarda para sempre<\/code><\/pre>\ncron.delete_old_audit_events<\/code>.<\/p>\nContas de bot e deploy tokens<\/h2>\n
gitea admin user change-type<\/code> converte uma conta local existente em bot ou faz a convers\u00e3o inversa.<\/p>\nAdministra\u00e7\u00e3o e revis\u00e3o de c\u00f3digo<\/h2>\n
\n
CODEOWNERS<\/code>.<\/li>\n\/-\/ws<\/code>. Se o WebSocket n\u00e3o conectar, a interface cai para consulta peri\u00f3dica.<\/li>\n<\/ul>\nGitea Actions<\/h2>\n
\n
strategy.matrix<\/code> de um job pode ser montado a partir das sa\u00eddas de jobs anteriores.<\/li>\nmax-parallel<\/code><\/strong> na matriz, cancelamento for\u00e7ado de execu\u00e7\u00f5es pela API e mais endpoints para gerenciar execu\u00e7\u00f5es e logs.<\/li>\nReten\u00e7\u00e3o e egress: dois cuidados antes do upgrade<\/h2>\n
1. O hist\u00f3rico de Actions passa a expirar<\/h3>\n
RUN_RETENTION_DAYS<\/code>, com padr\u00e3o de 400 dias<\/strong>: na limpeza da meia-noite seguinte ao upgrade, execu\u00e7\u00f5es mais antigas que isso s\u00e3o apagadas, junto com jobs, logs e artefatos. Sem um backup, n\u00e3o h\u00e1 restaura\u00e7\u00e3o autom\u00e1tica. Para manter o comportamento antigo, defina antes de atualizar:<\/p>\n[actions]\nRUN_RETENTION_DAYS = 0 ; 0 = guardar para sempre<\/code><\/pre>\n0<\/code>: agora ele significa \u201cguardar para sempre\u201d tamb\u00e9m em LOG_RETENTION_DAYS<\/code> e ARTIFACT_RETENTION_DAYS<\/code>. At\u00e9 a 1.27, quem pusesse 0<\/code> nessas duas chaves tinha logs e artefatos apagados na limpeza seguinte.<\/p>\n2. O tr\u00e1fego Git de sa\u00edda passa por um proxy interno<\/h3>\n
\n
EGRESS_MODE = lax<\/code> (padr\u00e3o): permite hosts p\u00fablicos em qualquer porta, salvo bloqueios expl\u00edcitos; endere\u00e7os privados e de loopback exigem permiss\u00e3o.<\/li>\nEGRESS_MODE = strict<\/code>: s\u00f3 libera o que estiver na lista de permitidos, respeitando os bloqueios; entradas sem porta valem apenas para 80 e 443.<\/li>\n<\/ul>\n![\"Fluxo](\"\/wp-content\/uploads\/2026\/10\/gitea-28-egress.webp\")
[security]<\/code>, uma ALLOWED_HOST_LIST<\/code> que antes restringia os destinos p\u00fablicos deixa de ser exclusiva no modo padr\u00e3o lax<\/code>. Para manter essa restri\u00e7\u00e3o em webhooks e OAuth2, configure EGRESS_MODE = strict<\/code>. N\u00e3o copie essa configura\u00e7\u00e3o sem listar os destinos realmente necess\u00e1rios.<\/p>\n[migrations]<\/code>, se a lista nova estiver ausente, uma ALLOWED_DOMAINS<\/code> legada mant\u00e9m o modo estrito por compatibilidade e permite todas as portas dos hosts listados. Ao adotar a lista nova, revise as portas explicitamente. Consulte a refer\u00eancia de migra\u00e7\u00f5es<\/a>, em vez de presumir equival\u00eancia entre chaves antigas e novas.<\/p>\n\n
external<\/code> deixou de existir.<\/li>\n*<\/code> n\u00e3o s\u00e3o mais aceitos.<\/li>\nexample.com<\/code> vale para o dom\u00ednio e todos os subdom\u00ednios; *.example.com<\/code>, s\u00f3 para os subdom\u00ednios.<\/li>\n[migrations] BLOCKED_HOST_LIST<\/code> impede o Gitea de subir.<\/li>\nALLOWED_DOMAINS<\/code>, BLOCKED_DOMAINS<\/code> e ALLOW_LOCALNETWORKS<\/code> ficam obsoletas em favor de ALLOWED_HOST_LIST<\/code> e BLOCKED_HOST_LIST<\/code>.<\/li>\n[migrations]<\/code> controla migra\u00e7\u00f5es e espelhos; o [security]<\/code>, webhooks e OAuth2.<\/li>\n<\/ul>\nOutras mudan\u00e7as incompat\u00edveis<\/h2>\n
\n
git --version<\/code> no ambiente que executa o Gitea.<\/li>\n[service] DISABLE_REGISTRATION = false<\/code>.<\/li>\n[server] DOMAIN<\/code> deixa de ser lido; revise ROOT_URL<\/code>, usado tamb\u00e9m para derivar o dom\u00ednio SSH padr\u00e3o.<\/li>\nif:<\/code> do job \u00e9 avaliado antes da expans\u00e3o da matriz. Condi\u00e7\u00f5es com matrix<\/code> precisam ser movidas para etapas ou para a configura\u00e7\u00e3o da matriz.<\/li>\nstrategy.fail-fast<\/code> passa a ser aplicado; configure false<\/code> quando todas as combina\u00e7\u00f5es precisarem terminar.<\/li>\nNa pr\u00e1tica: atualizando uma inst\u00e2ncia de produ\u00e7\u00e3o<\/h2>\n
app.ini<\/code> tinha:<\/p>\n[migrations]\nALLOW_LOCALNETWORKS = true\nALLOWED_DOMAINS = github.com,api.github.com,gitlab.com<\/code><\/pre>\ngithub.com<\/code> j\u00e1 cobre api.github.com<\/code>:<\/p>\n[migrations]\nEGRESS_MODE = strict\nALLOWED_HOST_LIST = github.com,gitlab.com,private,loopback<\/code><\/pre>\n10.0.0.15\/32:3000<\/code> (substitua pelo IP real do seu ambiente). Valide a configura\u00e7\u00e3o e o acesso aos destinos antes da virada.<\/p>\nRUN_RETENTION_DAYS = 0<\/code> antes do upgrade.<\/p>\n\/-\/ws<\/code> respondia 101 Switching Protocols<\/code> direto no Gitea, mas 426 Upgrade Required<\/code> pelo nginx. O bloco de proxy at\u00e9 repassava os cabe\u00e7alhos Upgrade<\/code> e Connection<\/code>, mas faltava a vers\u00e3o do protocolo \u2014 no nginx 1.18.0 verificado, o padr\u00e3o para o upstream \u00e9 HTTP\/1.0, que n\u00e3o permite esse upgrade:<\/p>\nmap<\/code> recomendado na documenta\u00e7\u00e3o do nginx<\/a>. O map<\/code> pertence ao contexto http<\/code>; o location<\/code>, ao bloco server<\/code> existente:<\/p>\n# Dentro de http {}, fora de server {}\nmap $http_upgrade $connection_upgrade {\n default upgrade;\n '' close;\n}\n\n# Dentro do server {} existente\nlocation \/ {\n proxy_pass http:\/\/127.0.0.1:3000;\n proxy_http_version 1.1; # a linha que faltava\n proxy_set_header Upgrade $http_upgrade;\n proxy_set_header Connection $connection_upgrade;\n proxy_set_header Host $host;\n proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n proxy_set_header X-Forwarded-Proto $scheme;\n}<\/code><\/pre>\ncurl -s --max-time 5 -o \/dev\/null -w '%{http_code}\\n' --http1.1 \\\n -H 'Connection: Upgrade' -H 'Upgrade: websocket' \\\n -H 'Sec-WebSocket-Version: 13' -H 'Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==' \\\n https:\/\/git.exemplo.com.br\/-\/ws\n# 101 = handshake conclu\u00eddo; 426 = investigar o upgrade no proxy<\/code><\/pre>\n101<\/code>, a conex\u00e3o permanece aberta; o timeout e o c\u00f3digo de sa\u00edda 28 do curl ao fim dos cinco segundos s\u00e3o esperados neste teste. Valide a configura\u00e7\u00e3o com nginx -t<\/code> antes de recarregar o servi\u00e7o.<\/p>\nreverse_proxy<\/code> trata WebSocket sem configura\u00e7\u00e3o extra.<\/p>\nproxy_http_version 1.1<\/code>, mantendo os cabe\u00e7alhos de upgrade j\u00e1 existentes, mudou a resposta de 426<\/code> para 101<\/code>. A p\u00e1gina inicial continuou respondendo 200<\/code> depois da recarga.<\/p>\nRoteiro de upgrade<\/h2>\n
\n
ROOT_URL<\/code>, cadastro e workflows antes de reiniciar.<\/li>\nRUN_RETENTION_DAYS<\/code> antes de subir a 28.<\/li>\nALLOWED_DOMAINS<\/code>, BLOCKED_DOMAINS<\/code>, ALLOW_LOCALNETWORKS<\/code> ou o preset external<\/code>, reescreva com ALLOWED_HOST_LIST<\/code>, BLOCKED_HOST_LIST<\/code> e EGRESS_MODE<\/code>. Se a lista precisa ser exclusiva, use strict<\/code>.<\/li>\ndocker.gitea.com\/gitea:28.0.0<\/code>) e reinicie. Confira a soma SHA-256 antes.<\/li>\n\/api\/healthz<\/code>, a vers\u00e3o em \/api\/v1\/version<\/code>, os avisos no log de inicializa\u00e7\u00e3o e o teste de WebSocket acima.<\/li>\n<\/ol>\nSeguran\u00e7a<\/h2>\n
Vale atualizar?<\/h2>\n