![\"Mascote](\"\/wp-content\/uploads\/2026\/09\/gitea-v4.webp\")
<\/p>\n<\/p>\n
Gitea<\/strong> (Git with a cup of tea<\/em>) \u00e9 a forge self-hosted em Go: reposit\u00f3rio Git, PR, issues, wiki, registry de pacotes e CI\/CD no mesmo bin\u00e1rio. Fork do Gogs<\/a> em 2016, licen\u00e7a MIT, cabe num VPS de 1 GB. A vers\u00e3o est\u00e1vel \u00e9 a 28.0.0<\/strong>, de 29\/09\/2026. Este texto sobe a inst\u00e2ncia com Docker Compose e MariaDB<\/strong>, registra o Gitea Runner 4<\/strong> para rodar Actions e instala o CLI oficial tea 0.16<\/strong>.<\/p>\n <\/p>\n O Git em si \u2014 BitKeeper, os dez dias de Linus, o 2.55 \u2014 est\u00e1 em A hist\u00f3ria do Git<\/a>. O cheatsheet do dia a dia, em Git simples e r\u00e1pido<\/a>. Aqui o assunto \u00e9 a forge: o GitHub que voc\u00ea roda na sua m\u00e1quina.<\/p>\n N\u00e3o \u00e9 GitLab<\/a> CE. N\u00e3o puxa Elasticsearch, n\u00e3o pede 8 GB de RAM para o hello world. \u00c9 um bin\u00e1rio (ou um container) + um banco. O Gitea fala com SQLite3, MySQL\/MariaDB, PostgreSQL e MSSQL. SQLite<\/strong> vem embutido e resolve lab, Raspberry Pi e um usu\u00e1rio s\u00f3. Em produ\u00e7\u00e3o com time e Actions, use MariaDB<\/strong> (ou MySQL: o driver \u00e9 o mesmo, Actions existem desde a 1.19 e v\u00eam ligadas por padr\u00e3o desde a 1.21: o YAML \u00e9 o da GitHub Actions, mas quem executa \u00e9 um runner pr\u00f3prio, que voc\u00ea registra. O Tr\u00eas pe\u00e7as. O Gitea<\/strong> atende web, API e SSH e guarda os metadados no MariaDB<\/strong>. O runner<\/strong> pode ficar na mesma m\u00e1quina ou em outra: ele s\u00f3 abre conex\u00f5es de sa\u00edda para o Gitea, busca os jobs na fila e sobe um container por job no Docker. O ponto que mais derruba instala\u00e7\u00e3o nova \u00e9 o \u00faltimo passo: o container do job faz o checkout pela A vers\u00e3o que viria a ser 1.28.0 saiu como 28.0.0<\/strong>: o projeto deixou de usar o prefixo \u201c1.\u201d<\/a>. N\u00e3o houve 27 vers\u00f5es perdidas \u2014 o n\u00famero que antes ficava depois do \u201c1.\u201d passou para a frente. Ajuste scripts que comparam vers\u00f5es ou que procuram tags Os destaques: log de auditoria<\/strong>, contas de bot<\/strong> gerenciadas pela interface, API e CLI, deploy tokens<\/strong> por HTTPS, impersona\u00e7\u00e3o<\/strong> de usu\u00e1rio pelo administrador, prote\u00e7\u00e3o de branch que bloqueia o merge enquanto houver revis\u00e3o pendente de code owner<\/em>, filtros no diff e uma fila de builds<\/strong> para as Actions. As Actions tamb\u00e9m ganharam matriz din\u00e2mica, Duas mudan\u00e7as s\u00e3o incompat\u00edveis e pedem aten\u00e7\u00e3o antes<\/em> do upgrade:<\/p>\n Detalhe para quem baixa bin\u00e1rios por script: a 28 n\u00e3o publica mais builds x86 de 32 bits nem as variantes Imagem oficial: Abra Chave p\u00fablica: SSH sem senha<\/a>. Em produ\u00e7\u00e3o coloque HTTPS na frente (nginx ou Caddy<\/a>), troque a Para testar na m\u00e1quina ou num Pi, tire o servi\u00e7o Serve para um usu\u00e1rio e poucos repos. Com time, CI e registry, fique no MariaDB: o SQLite serializa as escritas e engasga quando v\u00e1rios jobs e usu\u00e1rios gravam ao mesmo tempo.<\/p>\n Caminho da documenta\u00e7\u00e3o oficial, com o Git do sistema e um usu\u00e1rio Mais sobre units e O Gitea n\u00e3o executa workflow sozinho. Quem pega o job \u00e9 o runner<\/strong>: o bin\u00e1rio chama-se Token de registro: Site Administration \u2192 Actions \u2192 Runners \u2192 Create new runner<\/em> (vale tamb\u00e9m por organiza\u00e7\u00e3o ou por reposit\u00f3rio, nas configura\u00e7\u00f5es de cada um). Se puder, rode o runner em outra m\u00e1quina \u2014 o job consome CPU e RAM de quem o executa, e a forge n\u00e3o deve disputar recurso com um build.<\/p>\n A imagem vem em tr\u00eas sabores:<\/p>\n O volume Quem vem da s\u00e9rie 3 deve ler as notas da 4.0: com Workflow m\u00ednimo no reposit\u00f3rio:<\/p>\n O label Token: Settings \u2192 Applications \u2192 Generate New Token<\/em>, com permiss\u00e3o de leitura e escrita em repository e issue. Login:<\/p>\n Dentro de um clone hospedado nessa inst\u00e2ncia o Para O N\u00e3o existe comando de restore: a volta \u00e9 manual (descompactar, devolver arquivos e importar o SQL). Por isso vale ter tamb\u00e9m o dump nativo do banco \u2014 Upgrade da 1.27 para a 28, na ordem:<\/p>\n N\u00e3o troque a imagem rootful pela rootless no mesmo volume.<\/p>\n Gitea 28 + MariaDB 11 + runner 4.1 + tea 0.16 \u00e9 uma forge completa num VPS pequeno. SQLite para o primeiro Mais: hist\u00f3ria do Git<\/a>, hist\u00f3ria do GitLab<\/a>, hist\u00f3ria do Docker<\/a>, cheatsheet do Git<\/a> e o Gogs em 2017<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Gitea es la forge auto-hospedada en Go: Git, PR, issues, registry y CI\/CD en el mismo binario. Gu\u00eda actualizada para Gitea 28.0.0 \u2014 la versi\u00f3n que abandon\u00f3 el prefijo \u201c1.\u201d \u2014, con Docker Compose y MariaDB, runner 4.1, tea CLI y la hoja de ruta de actualizaci\u00f3n de la 1.27.<\/p>","protected":false},"author":0,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[45,46,2,111,120],"tags":[105,156,48,201,204,203,202],"class_list":["post-502","post","type-post","status-publish","format-standard","hentry","category-desenv","category-devops","category-linux","category-opensource","category-servidores","tag-ci-cd","tag-docker","tag-git","tag-gitea","tag-runner","tag-self-hosted","tag-tea"],"_links":{"self":[{"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/posts\/502","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/comments?post=502"}],"version-history":[{"count":7,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/posts\/502\/revisions"}],"predecessor-version":[{"id":1800,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/posts\/502\/revisions\/1800"}],"wp:attachment":[{"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/media?parent=502"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/categories?post=502"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/tags?post=502"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}O que o Gitea \u00e9 (e o que n\u00e3o \u00e9)<\/h2>\n
DB_TYPE=mysql<\/code>).<\/p>\ntea<\/code> \u00e9 o gh<\/code> dessa casa. O Forgejo \u00e9 o fork comunit\u00e1rio de 2022; a base \u00e9 comum, mas os dois projetos j\u00e1 divergem. C\u00f3digo: github.com\/go-gitea\/gitea<\/a>. Docs: docs.gitea.com<\/a>.<\/p>\nArquitetura<\/h2>\n
ROOT_URL<\/code> da inst\u00e2ncia, ent\u00e3o ela precisa ser um endere\u00e7o que o job alcan\u00e7a \u2014 nunca localhost<\/code>.<\/p>\n![\"Diagrama](\"\/wp-content\/uploads\/2026\/09\/gitea-arquitetura-runner.webp\")
<\/p>\nO que muda na 28<\/h2>\n
1.*<\/code>.<\/p>\nmax-parallel<\/code> e mais endpoints de API para gerenciar execu\u00e7\u00f5es e logs. A release traz corre\u00e7\u00f5es de seguran\u00e7a, como a rejei\u00e7\u00e3o de objetos Git inv\u00e1lidos ou duplicados no push e a garantia de que execu\u00e7\u00f5es de PR vindas de fork continuem atr\u00e1s da aprova\u00e7\u00e3o; os detalhes seriam publicados uma semana depois do lan\u00e7amento.<\/p>\n\n
RUN_RETENTION_DAYS<\/code> apaga execu\u00e7\u00f5es conclu\u00eddas com mais de 400 dias, junto com jobs e tarefas, na limpeza da meia-noite. Para manter tudo, defina RUN_RETENTION_DAYS = 0<\/code> na se\u00e7\u00e3o [actions]<\/code> (no Compose, GITEA__actions__RUN_RETENTION_DAYS: \"0\"<\/code>). Agora 0<\/code> significa \u201cguardar para sempre\u201d tamb\u00e9m em LOG_RETENTION_DAYS<\/code> e ARTIFACT_RETENTION_DAYS<\/code>, que antes apagavam tudo na limpeza seguinte com esse valor.<\/li>\nexternal<\/code> deixou de existir: para negar tudo por padr\u00e3o, use EGRESS_MODE = strict<\/code> e liste o que \u00e9 permitido (em [migrations]<\/code> para migra\u00e7\u00f5es e espelhos; em [security]<\/code> para webhooks e OAuth2). Curingas em IP e o item *<\/code> n\u00e3o s\u00e3o mais aceitos, dom\u00ednios seguem a sintaxe do curl (example.com<\/code> inclui os subdom\u00ednios; *.example.com<\/code>, s\u00f3 os subdom\u00ednios) e uma entrada inv\u00e1lida em BLOCKED_HOST_LIST<\/code> impede o Gitea de subir. ALLOWED_DOMAINS<\/code>, BLOCKED_DOMAINS<\/code> e ALLOW_LOCALNETWORKS<\/code> ficam obsoletos em favor de ALLOWED_HOST_LIST<\/code> e BLOCKED_HOST_LIST<\/code>.<\/li>\n<\/ul>\ngogit<\/code>, e os nomes de arquivo perderam o sufixo de vers\u00e3o do sistema operacional.<\/p>\nSubir com Docker Compose e MariaDB<\/h2>\n
docker.gitea.com\/gitea:28.0.0<\/code> (testada aqui: sobe, cria o administrador pela CLI e responde {\"version\":\"28.0.0\"}<\/code> em \/api\/v1\/version<\/code>). Porta 3000 na web; 222 no host mapeada para o SSH do container (22), para n\u00e3o brigar com o sshd da m\u00e1quina. Troque SEU_IP<\/code> pelo IP ou dom\u00ednio da m\u00e1quina e as senhas por valores seus.<\/p>\nmkdir -p ~\/gitea && cd ~\/gitea<\/code><\/pre>\n# docker-compose.yml\nnetworks:\n gitea:\n\nvolumes:\n gitea-data:\n mariadb-data:\n\nservices:\n server:\n image: docker.gitea.com\/gitea:28.0.0\n container_name: gitea\n restart: always\n environment:\n USER_UID: \"1000\"\n USER_GID: \"1000\"\n GITEA__database__DB_TYPE: mysql\n GITEA__database__HOST: db:3306\n GITEA__database__NAME: gitea\n GITEA__database__USER: gitea\n GITEA__database__PASSWD: troque-esta-senha\n GITEA__server__ROOT_URL: http:\/\/SEU_IP:3000\/\n GITEA__server__SSH_DOMAIN: SEU_IP\n GITEA__server__SSH_PORT: \"222\"\n networks:\n - gitea\n volumes:\n - gitea-data:\/data\n - \/etc\/timezone:\/etc\/timezone:ro\n - \/etc\/localtime:\/etc\/localtime:ro\n ports:\n - \"3000:3000\"\n - \"222:22\"\n depends_on:\n - db\n healthcheck:\n test: [\"CMD\", \"curl\", \"-f\", \"http:\/\/localhost:3000\/\"]\n interval: 10s\n timeout: 5s\n retries: 6\n start_period: 30s\n\n db:\n image: docker.io\/library\/mariadb:11\n restart: always\n environment:\n MARIADB_ROOT_PASSWORD: troque-esta-senha-root\n MARIADB_DATABASE: gitea\n MARIADB_USER: gitea\n MARIADB_PASSWORD: troque-esta-senha\n networks:\n - gitea\n volumes:\n - mariadb-data:\/var\/lib\/mysql\n command: [\"--character-set-server=utf8mb4\", \"--collation-server=utf8mb4_bin\"]<\/code><\/pre>\ndocker compose up -d\ndocker compose ps\ndocker compose logs -f server<\/code><\/pre>\nhttp:\/\/SEU_IP:3000<\/code> e complete o assistente. Os campos do banco j\u00e1 v\u00eam preenchidos pelas vari\u00e1veis: host db<\/code> (nome do servi\u00e7o, n\u00e3o localhost), tipo MySQL<\/strong> (\u00e9 como a UI chama o MariaDB). O primeiro usu\u00e1rio criado vira administrador. Depois do wizard o app.ini<\/code> fica em \/data\/gitea\/conf\/app.ini<\/code> no volume; qualquer chave pode ser sobrescrita por vari\u00e1vel no formato GITEA__secao__CHAVE<\/code>.<\/p>\nSSH_PORT: \"222\"<\/code> s\u00f3 muda a URL de clone que a interface mostra; o SSH continua escutando na 22 dentro do container. Clone:<\/p>\ngit clone ssh:\/\/git@SEU_IP:222\/usuario\/repo.git<\/code><\/pre>\nROOT_URL<\/code> para https:\/\/git.seudominio\/<\/code> e, se ningu\u00e9m de fora deve criar conta, defina GITEA__service__DISABLE_REGISTRATION: \"true\"<\/code>.<\/p>\nSQLite: um container, zero banco extra<\/h2>\n
db<\/code> e as vari\u00e1veis GITEA__database__*<\/code>. No assistente escolha SQLite3<\/strong>; o arquivo fica em \/data\/gitea\/gitea.db<\/code>.<\/p>\nservices:\n server:\n image: docker.gitea.com\/gitea:28.0.0\n container_name: gitea\n restart: always\n environment:\n USER_UID: \"1000\"\n USER_GID: \"1000\"\n volumes:\n - .\/gitea-data:\/data\n ports:\n - \"3000:3000\"\n - \"222:22\"<\/code><\/pre>\nBin\u00e1rio com systemd, se n\u00e3o quiser container<\/h2>\n
git<\/code> dedicado:<\/p>\nsudo apt install -y git\nsudo wget -O \/usr\/local\/bin\/gitea \\\n https:\/\/dl.gitea.com\/gitea\/28.0.0\/gitea-28.0.0-linux-amd64\nsudo chmod +x \/usr\/local\/bin\/gitea\n\nsudo adduser --system --shell \/bin\/bash --gecos 'Git Version Control' \\\n --group --disabled-password --home \/home\/git git\nsudo mkdir -p \/var\/lib\/gitea\/{custom,data,log} \/etc\/gitea\nsudo chown -R git:git \/var\/lib\/gitea\nsudo chmod -R 750 \/var\/lib\/gitea\nsudo chown root:git \/etc\/gitea\nsudo chmod 770 \/etc\/gitea # o assistente web grava o app.ini aqui<\/code><\/pre>\n# \/etc\/systemd\/system\/gitea.service\n[Unit]\nDescription=Gitea\nAfter=network.target mariadb.service\n\n[Service]\nUser=git\nGroup=git\nWorkingDirectory=\/var\/lib\/gitea\/\nExecStart=\/usr\/local\/bin\/gitea web --config \/etc\/gitea\/app.ini\nEnvironment=USER=git HOME=\/home\/git GITEA_WORK_DIR=\/var\/lib\/gitea\nRestart=always\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>\nsudo systemctl daemon-reload\nsudo systemctl enable --now gitea\n# depois do assistente, trave a configura\u00e7\u00e3o:\nsudo chmod 750 \/etc\/gitea\nsudo chmod 640 \/etc\/gitea\/app.ini<\/code><\/pre>\nsystemctl<\/code>: Dominando o systemd<\/a>. O bin\u00e1rio j\u00e1 traz SQLite; MariaDB\/MySQL e PostgreSQL entram no [database]<\/code> do app.ini<\/code>. Cada bin\u00e1rio em dl.gitea.com\/gitea<\/a> vem com .sha256<\/code>, assinatura GPG (.asc<\/code>) e pacote Sigstore (.sigstore.json<\/code>) \u2014 confira antes de colocar em produ\u00e7\u00e3o.<\/p>\nGitea Actions e o Runner<\/h2>\n
gitea-runner<\/code> (o projeto antes se chamava act_runner<\/code>), o c\u00f3digo est\u00e1 em gitea.com\/gitea\/runner<\/a> e a imagem oficial \u00e9 docker.io\/gitea\/runner<\/code>. A vers\u00e3o atual \u00e9 a 4.1.0<\/strong>, de 01\/10\/2026, que acrescentou um backend para executar os jobs no Kubernetes. O YAML vive em .gitea\/workflows\/<\/code> e usa o mesmo esquema da GitHub Actions.<\/p>\n# acrescente em services: no mesmo docker-compose.yml\n runner:\n image: docker.io\/gitea\/runner:4\n restart: always\n environment:\n GITEA_INSTANCE_URL: http:\/\/SEU_IP:3000\/\n GITEA_RUNNER_REGISTRATION_TOKEN: COLE_O_TOKEN\n GITEA_RUNNER_NAME: linuxpro-1\n networks:\n - gitea\n volumes:\n - .\/runner-data:\/data\n - \/var\/run\/docker.sock:\/var\/run\/docker.sock\n depends_on:\n server:\n condition: service_healthy<\/code><\/pre>\nGITEA_INSTANCE_URL<\/code> deve ser a mesma ROOT_URL<\/code> do Gitea. D\u00e1 para registrar com http:\/\/server:3000<\/code> pela rede do compose, mas o checkout dentro do job usa a ROOT_URL<\/code>, e o container do job n\u00e3o resolve o nome server<\/code>.<\/p>\n\n
gitea\/runner:4<\/code> \u2014 s\u00f3 o runner; usa o Docker do host pelo socket montado. Simples, mas quem monta o docker.sock<\/code> tem o equivalente a root na m\u00e1quina, e os jobs enxergam os outros containers dela.<\/li>\ngitea\/runner:4-dind<\/code> \u2014 traz um dockerd pr\u00f3prio, isolado do host; exige privileged: true<\/code> e n\u00e3o usa o socket.<\/li>\ngitea\/runner:4-dind-rootless<\/code> \u2014 mesmo esquema, com o daemon rodando como UID 1000; menos poder, mais limita\u00e7\u00f5es de rede e cgroups.<\/li>\n<\/ul>\n\/data<\/code> guarda o arquivo de registro .runner<\/code>. Sem ele, cada recria\u00e7\u00e3o do container registra um runner novo e o antigo fica \u00f3rf\u00e3o na UI. Esse volume n\u00e3o guarda o cache de imagens: no dind<\/code>, monte tamb\u00e9m \/var\/lib\/docker<\/code> se n\u00e3o quiser baixar tudo de novo a cada restart.<\/p>\ncache.external_server<\/code> os jobs passam a falar com o cache atrav\u00e9s do runner, jobs em container.network: bridge<\/code> perdem acesso ao cache e aos artefatos, e *<\/code> em valid_volumes<\/code> n\u00e3o atravessa mais \/<\/code> (use **<\/code>). A 4.0 tamb\u00e9m trouxe a action builtin:checkout<\/code>, que n\u00e3o precisa de download nem de Node na imagem do job.<\/p>\n# .gitea\/workflows\/ci.yml\nname: ci\non:\n push:\n branches: [main]\n pull_request:\njobs:\n test:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n - run: echo \"commit ${{ gitea.sha }}\" && uname -a<\/code><\/pre>\nubuntu-latest<\/code> vem por padr\u00e3o e aponta para a imagem docker.gitea.com\/runner-images:ubuntu-latest<\/code>. O contexto aceita gitea.*<\/code> e tamb\u00e9m github.*<\/code>, ent\u00e3o a maior parte das actions p\u00fablicas funciona sem mudan\u00e7a; uses: actions\/checkout@v4<\/code> \u00e9 baixado do GitHub, porque DEFAULT_ACTIONS_URL<\/code> vale github<\/code> por padr\u00e3o \u2014 em rede isolada, espelhe as actions na pr\u00f3pria inst\u00e2ncia. Pipeline em conceito: DevOps: o que \u00e9 CI\/CD?<\/a>.<\/p>\ntea CLI<\/h2>\n
tea<\/code> \u00e9 o cliente oficial (MIT, Go): issues, PR, releases, labels, login em v\u00e1rias inst\u00e2ncias e tea pr checkout<\/code> no reposit\u00f3rio local. A est\u00e1vel \u00e9 a 0.16.0<\/strong>, de 10\/09\/2026, que trouxe tea login status<\/code> e leitura da descri\u00e7\u00e3o de issue ou PR a partir de arquivo ou stdin.<\/p>\nsudo curl -fsSL -o \/usr\/local\/bin\/tea \\\n https:\/\/dl.gitea.com\/tea\/0.16.0\/tea-0.16.0-linux-amd64\nsudo chmod +x \/usr\/local\/bin\/tea\ntea --version<\/code><\/pre>\ntea login add --name casa --url http:\/\/SEU_IP:3000 --token SEU_TOKEN\ntea login list\ntea repos\ntea issues\ntea pulls<\/code><\/pre>\ntea<\/code> descobre o remote sozinho. Exemplos do dia:<\/p>\ntea issues list --state open\ntea pulls checkout 12\ntea pulls approve 12 \"LGTM\"\ntea pulls merge 12\ntea releases create --tag v1.0.0 --title v1.0.0 --note \"primeiro corte\"<\/code><\/pre>\ngit push<\/code> por HTTPS sem senha, tea login add<\/code> aceita --git-credentials<\/code> e se registra como credential helper do Git. Em esta\u00e7\u00e3o com navegador existe o fluxo --oauth<\/code>; em servidor headless e em job de CI, token continua o caminho simples. Bin\u00e1rios: dl.gitea.com\/tea<\/a>. C\u00f3digo: gitea.com\/gitea\/tea<\/a>.<\/p>\nBackup e upgrade<\/h2>\n
gitea dump<\/code> empacota reposit\u00f3rios, configura\u00e7\u00e3o, anexos e um dump SQL do banco num zip. No container ele precisa rodar como git<\/code> e dentro de um diret\u00f3rio grav\u00e1vel:<\/p>\ndocker compose exec -u git -w \/tmp server \\\n gitea dump -c \/data\/gitea\/conf\/app.ini --file \/tmp\/gitea-dump.zip\ndocker compose cp server:\/tmp\/gitea-dump.zip .\/gitea-dump-$(date +%F).zip\ndocker compose exec server rm \/tmp\/gitea-dump.zip<\/code><\/pre>\nmariadb-dump<\/code> \u2014 agendado e testado; o Databasus<\/a> faz isso com restaura\u00e7\u00e3o verificada.<\/p>\n\n
gitea dump<\/code> e o dump nativo do banco.<\/li>\nGITEA__actions__RUN_RETENTION_DAYS: \"0\"<\/code> ao servi\u00e7o server<\/code> antes<\/em> de subir a nova vers\u00e3o.<\/li>\nALLOWED_DOMAINS<\/code>, BLOCKED_DOMAINS<\/code>, ALLOW_LOCALNETWORKS<\/code> ou o preset external<\/code>, reescreva as regras com ALLOWED_HOST_LIST<\/code>, BLOCKED_HOST_LIST<\/code> e EGRESS_MODE<\/code>.<\/li>\n1.27.3<\/code> \u2192 28.0.0<\/code>) e rode docker compose pull && docker compose up -d<\/code>. As migra\u00e7\u00f5es do banco rodam na subida.<\/li>\ndocker compose logs server<\/code>: o Gitea avisa no in\u00edcio quando encontra regra de egress inv\u00e1lida ou lista de hosts sem EGRESS_MODE<\/code> expl\u00edcito.<\/li>\n<\/ol>\nO que ficou<\/h2>\n
docker compose up<\/code>; MariaDB quando o time e o CI entram. Acerte a ROOT_URL<\/code> antes de registrar o runner e metade dos problemas de Actions some. O Git continua o de sempre; a camada social \u2014 PR, Actions, registry \u2014 \u00e9 o que o GitHub cobrou e o Gogs n\u00e3o chegou a amarrar.<\/p>\n