Como Hospedar o Gitea em um VPS

Você pode auto-hospedar o Gitea em um VPS da VoyraCloud selecionando a imagem do aplicativo pré-instalado, criando o primeiro administrador através do SSH e, em seguida, usando a interface web, Git HTTPS ou Git SSH para seus repositórios. A imagem remove a etapa de instalação manual, enquanto a política de contas, domínios, HTTPS, acesso ao repositório, atualizações, backups e resposta a incidentes permanecem sob seu controle.

TL;DR

A imagem do aplicativo VoyraCloud Gitea fornece uma instância pré-instalada do Gitea Community Edition em Cloud VPS e Residential IP VPS.
A página de instalação está bloqueada antes da entrega. Crie o primeiro administrador através do comando SSH mostrado nos detalhes do seu recurso, não através de um assistente de instalação exposto publicamente.
A porta 3000 está vinculada à interface de loopback do VPS. Use o comando SSH Tunnel nos detalhes do recurso para o primeiro login na web; não está exposta como HTTP público.
Adicione um domínio, proxy reverso e HTTPS confiável antes de publicar a interface web ou usar Git HTTPS. O Git SSH do Gitea usa a porta pública separada 2222 após você adicionar uma chave pública à sua conta.
A inscrição de novos usuários está desativada por padrão. O administrador decide se deve criar usuários manualmente ou alterar a política de registro.
Repositórios, contas, problemas, pull requests, pacotes, anexos, configuração e segredos persistem após uma reinicialização normal do VPS, mas a persistência da reinicialização não é um backup fora do servidor.
A VoyraCloud não atualiza, faz backup, monitora ou administra automaticamente a instância do Gitea após a entrega.

O que é o Gitea?

Gitea é um serviço de desenvolvimento de software de código aberto para hospedar repositórios Git e colaborar em código-fonte. Ele fornece uma interface web em torno de fluxos de trabalho Git padrão, juntamente com contas de usuário, organizações, permissões de repositório, pull requests, problemas, projetos, wikis, lançamentos, pacotes, webhooks e acesso à API.

A documentação oficial do Gitea descreve a instalação e administração para equipes que desejam operar seu próprio serviço. A auto-hospedagem é útil quando você deseja que o serviço de repositório, local de armazenamento, política de contas, acesso à rede, tempo de atualização e processo de backup estejam sob sua própria administração.

Um VPS Gitea é uma opção prática para:

Um desenvolvedor que deseja repositórios privados em um servidor pessoal.
Uma pequena equipe que precisa de hospedagem Git, revisão de código, problemas e permissões de organização.
Uma agência que mantém repositórios separados para projetos de clientes.
Uma equipe de infraestrutura que conecta repositórios a sistemas de implantação através de chaves SSH, tokens de acesso, webhooks ou APIs.
Um laboratório ou ambiente interno que precisa de uma alternativa leve a uma plataforma de desenvolvimento de software maior.

A auto-hospedagem não torna as operações de repositório isentas de manutenção. Alguém ainda é responsável pela segurança do sistema operacional, atualizações do Gitea, política de autenticação, HTTPS, backups, crescimento de armazenamento, prevenção de abusos e testes de recuperação.

Como você começa com a imagem do Gitea da VoyraCloud?

O caminho de implantação mais rápido é criar um VPS da VoyraCloud suportado com a imagem do Gitea e executar o comando de configuração do administrador privado a partir dos detalhes do recurso. Você não precisa instalar Docker, Gitea ou o banco de dados inicial manualmente.

Abra a página da VoyraCloud para o Gitea a partir do link acima e continue para o fluxo de compra do VPS.
Selecione uma configuração de Cloud VPS ou Residential IP VPS elegível. O Cloud VPS é a opção de uso geral para hospedagem Git; o Residential IP VPS permanece disponível quando sua carga de trabalho mais ampla precisa especificamente das características de rede desse produto.
Escolha qualquer região atualmente oferecida pelo produto VPS selecionado e confirme que o Gitea está selecionado na seção Imagens.
Crie o VPS e aguarde até que o recurso e o aplicativo estejam prontos.
Abra os detalhes do recurso e localize a seção Aplicativo.
Copie o comando de Configuração do Admin. Ele segue este padrão:

ssh -t -p <ssh-port> <ssh-user>@<server-ip> 'sudo /usr/local/sbin/voyra-gitea-create-admin'

7. Execute o comando a partir do seu terminal e insira o nome de usuário e o e-mail do administrador. O CLI oficial do Gitea gera uma senha aleatória de 24 caracteres e a exibe apenas na sessão SSH atual.

8. Copie o comando SSH Tunnel da seção Aplicativo e mantenha essa sessão de terminal aberta. Ele segue este padrão:

ssh -N -L 3000:127.0.0.1:3000 -p <ssh-port> <ssh-user>@<server-ip>

9. Abra a URL de acesso local no seu navegador:

http://127.0.0.1:3000

10. Faça login com a conta de administrador e a senha de uso único, depois defina uma nova senha quando o Gitea solicitar a alteração.

11. Crie um repositório de teste privado, adicione uma chave pública SSH e verifique um clone e push SSH.

12. Conecte seu domínio, configure HTTPS confiável, atualize as configurações da URL pública do Gitea e confirme que os links de clone gerados usam o endereço pretendido.

13. Reinicie o VPS uma vez e verifique se o Gitea retorna automaticamente com o administrador, repositório de teste, histórico de commits, chaves e configurações intactas.

14. Crie um backup fora do servidor e realize um teste de restauração antes de confiar na instância para código-fonte importante.

O comando de configuração é intencionalmente separado da página web. O assistente de instalação público já está bloqueado, então um visitante da internet não pode reivindicar uma nova instância criando o primeiro administrador antes do proprietário. O comando também para se um administrador já existir.

Use o nome de usuário SSH e a porta mostrados para o recurso do seu VPS. Não assuma que todos os servidores usam root ou a porta 22. A conexão SSH do VPS usada para administração também é diferente do endpoint SSH Git do Gitea na porta 2222.

O que a imagem do aplicativo inclui?

A imagem do aplicativo Gitea inclui um ponto de partida persistente de servidor único, não um serviço de hospedagem de código-fonte gerenciado. O limite de entrega determina o que você deve configurar antes do uso regular da equipe.

Entregue pela imagem do aplicativo	Gerenciado pelo usuário ou não incluído
Lançamento estável do Gitea Community Edition aprovado para a imagem	Atualizações automáticas do Gitea
Ambiente VPS baseado em Ubuntu	Administração do sistema operacional gerenciada
Gitea em execução no contêiner oficial com um banco de dados SQLite local	Serviço PostgreSQL ou MySQL externo
Página de instalação bloqueada	Assistente de instalação web público
Comando SSH privado para criar o primeiro administrador	Administrador pré-criado ou senha fixa
Registro desativado por padrão	Provisionamento automático de membros da equipe
Backend web na porta de loopback `3000`	Exposição HTTP pública, registro de domínio, proxy reverso e HTTPS automático
SSH Git na porta `2222`	Chaves SSH de usuário pré-instaladas
Repositórios persistentes, banco de dados, configuração e dados do aplicativo	Backups automáticos fora do servidor
Recuperação do serviço após uma reinicialização normal do VPS	Alta disponibilidade ou failover automático
Recursos de colaboração padrão do Gitea	Runners gerenciados, capacidade CI, SMTP, OAuth, LDAP ou armazenamento externo

A imagem não inclui repositórios de exemplo, organizações, usuários, runners, pacotes, credenciais de terceiros, entrega de e-mail, um domínio ou um certificado confiável pelo navegador. Ela também não expõe segredos do aplicativo nos detalhes do recurso.

Como funciona a configuração segura do primeiro administrador?

O primeiro administrador é criado através de uma sessão SSH autenticada do VPS, enquanto a página de instalação pública do Gitea permanece bloqueada. Isso previne a corrida comum em que um instalador web não inicializado é acessível pela internet e um visitante não intencional completa a configuração primeiro.

A imagem do aplicativo prepara o banco de dados e a configuração antes da entrega. Ela habilita o bloqueio de instalação do Gitea e desativa o registro público de usuários. O comando de Configuração do Admin então executa o comando administrativo oficial do Gitea dentro do ambiente do aplicativo.

O processo de configuração deve ter estas propriedades:

Ele solicita o nome de usuário e o e-mail de forma interativa.
Ele informa ao CLI oficial do Gitea para gerar uma senha aleatória de 24 caracteres em vez de colocar sua senha escolhida em um argumento de linha de comando.
Ele mostra a senha de uso único apenas no terminal SSH atual e não a grava no histórico do shell, em um arquivo ou em um log.
Ele exige uma alteração de senha no primeiro login na web.
Ele se recusa a criar outro administrador após o primeiro administrador existir.
Ele não gera um token de acesso pessoal ou chave SSH para você.
Ele não imprime os segredos internos do Gitea.

Após fazer login, revise Administração do Site e a política de registro de usuários. O registro está desativado por padrão para que usuários desconhecidos da internet não possam criar contas. Você pode criar usuários aprovados a partir da interface de administração ou alterar a política se o registro aberto for um requisito intencional e você tiver um plano de controle de abusos.

Não envie a senha de uso único ou final do administrador por chat, ticket ou transcrição de shell compartilhada. Feche a sessão SSH inicial após alterar a senha. Adicione um segundo administrador apenas quando a propriedade operacional exigir, e use uma conta normal separada para trabalho rotineiro com Git quando prático.

Como o Git HTTPS e o Git SSH diferem?

O Git HTTPS usa o endpoint web do Gitea por trás do seu domínio HTTPS confiável, enquanto o Git SSH usa um serviço SSH dedicado do Gitea e uma chave pública em nível de conta. Ambos suportam operações normais de clone, fetch, pull e push, mas sua configuração de autenticação e transporte difere.

Método	Padrão de endereço inicial	Autenticação	Melhor uso após a configuração
Interface web inicial	`http://127.0.0.1:3000` através do SSH Tunnel	Nome de usuário e senha do Gitea	Primeiro login, alteração de senha e configuração privada
Interface web regular	`https://git.exemplo.com`	Nome de usuário e senha do Gitea	Navegação e administração de repositórios após a configuração do domínio
Git HTTPS	`https://git.exemplo.com/<owner>/<repo>.git`	Prefira um token de acesso pessoal para clientes Git	Transporte Git baseado na web após a configuração do domínio e HTTPS confiável
Git SSH	`ssh://git@<server-ip>:2222/<owner>/<repo>.git`	Chave pública SSH adicionada à conta do Gitea	Conveniente para clientes Git de desenvolvedor e automação usando chaves gerenciadas
SSH do sistema VPS	Host e porta específicos do recurso	Chave SSH do VPS ou credencial do servidor atual	Administração do servidor e configuração do primeiro administrador, não acesso ao repositório

Para o Git SSH:

Crie ou escolha uma chave SSH em sua estação de trabalho.
Faça login no Gitea e adicione a chave pública nas configurações da conta.
Copie o endereço de clone SSH da página do repositório.
Verifique a impressão digital do host na primeira conexão em vez de aceitar uma chave inesperada sem verificá-la.
Mantenha a chave privada no cliente e proteja-a com permissões de arquivo apropriadas e, quando adequado, uma frase secreta.

O Gitea SSH Git não deve pedir a senha web do Gitea. A porta 2222 pertence ao serviço de repositório; não fornece um shell de servidor.

Para o Git HTTPS, crie um token de acesso pessoal com apenas as permissões necessárias para aquele cliente ou integração. Evite colocar um token diretamente em um comando que permanecerá no histórico do shell. Use seu helper de credenciais Git ou um armazenamento secreto apropriado para seu sistema operacional.

Por que você deve adicionar um domínio e HTTPS?

Um domínio e HTTPS confiável pelo navegador protegem credenciais web e tráfego Git HTTPS e dão à instância uma identidade pública estável. A imagem mantém a porta 3000 na interface de loopback do VPS, então o serviço web não é acessível publicamente até que você configure deliberadamente um proxy reverso.

O guia oficial de proxy reverso do Gitea explica como o Gitea opera atrás de proxies comuns. Uma configuração de produção normalmente inclui:

Um registro DNS como git.exemplo.com apontando para o VPS.
Um proxy reverso ouvindo nas portas 80 e 443.
Um certificado TLS confiável pelo navegador para o domínio.
Um redirecionamento de HTTP para HTTPS.
Headers de host, endereço do cliente e protocolo encaminhados que correspondem à configuração do proxy.
As configurações públicas de ROOT_URL e domínio do Gitea atualizadas para a URL final HTTPS.
SSH_DOMAIN e a porta SSH exibida atualizadas para que as instruções de clone do repositório permaneçam precisas.

Após alterar o endereço, verifique todos os seguintes:

A página de login carrega sem um aviso de certificado.
Links gerados pelo Gitea usam o domínio HTTPS em vez do antigo endereço IP.
Clone e push Git HTTP funcionam através de HTTPS.
Links de clone SSH mostram o domínio e a porta corretos.
Webhooks e URLs de callback OAuth, se configurados posteriormente, usam o endereço público pretendido.
Grandes pushes não falham devido a limites de corpo ou tempo limite do proxy reverso.

A imagem do aplicativo não registra o domínio ou emite o certificado para você. Essas etapas são gerenciadas pelo usuário porque o nome do host final e a conta DNS pertencem ao proprietário do site.

Como você deve organizar usuários e acesso ao repositório?

Use contas individuais, equipes de organização, permissões de repositório, chaves SSH e tokens com escopo em vez de compartilhar uma única identidade de administrador. O Gitea pode hospedar repositórios privados e públicos, mas o administrador deve decidir quem pode descobrir, ler, escrever, revisar e administrar cada recurso.

Uma linha de base prática para pequenas equipes é:

Mantenha o registro público desativado, a menos que haja uma razão deliberada para abri-lo.
Dê a cada pessoa uma conta individual.
Reserve o acesso de administrador para proprietários de servidor e serviço.
Crie organizações para repositórios relacionados e equipes para grupos de permissão.
Conceda a menor permissão de repositório necessária para cada função.
Use proteção de branch e regras de revisão para branches importantes.
Use chaves de implantação ou tokens de acesso pessoal com escopo para automação em vez de uma senha de administrador.
Remova contas, chaves e tokens prontamente quando o acesso não for mais necessário.
Ative a autenticação de dois fatores para usuários privilegiados quando se adequar ao seu modelo de acesso.
Revise periodicamente a propriedade de organização, repositório, webhook, OAuth e token.

Se você conectar SMTP, OAuth, LDAP ou OpenID Connect mais tarde, trate isso como uma mudança de produção separada. Teste o vinculo de contas, recuperação, desligamento, acesso de administrador e comportamento de falha antes de confiar na integração. A imagem base não inclui esses serviços ou suas credenciais.

O que um backup do Gitea deve proteger?

Um backup completo do Gitea deve proteger o banco de dados, repositórios Git, configuração, segredos do aplicativo e quaisquer anexos, objetos LFS, pacotes, lançamentos, avatares ou outros dados armazenados que sua instância usa. Copiar apenas os repositórios Git não é suficiente para reconstruir usuários, permissões, problemas, pull requests, tokens, webhooks e configurações de serviço.

A documentação oficial de backup e restauração do Gitea descreve o fluxo de trabalho gitea dump e alerta que o serviço contém várias camadas de dados que podem mudar juntas. Um backup consistente requer coordenação; um banco de dados de aplicativo que diz que uma operação de repositório foi concluída enquanto a cópia do repositório capturou um estado anterior pode produzir um ponto de recuperação incompleto.

Seu plano de backup deve definir:

Camada	Exemplos	Por que isso importa
Banco de dados	Usuários, permissões, problemas, pull requests, configurações, tokens	Recria o estado e as relações do aplicativo
Repositórios Git	Commits, branches, tags, objetos Git	Preserva o histórico de origem
Configuração e segredos	URL pública, configurações de serviço, `SECRET_KEY`, tokens internos	Mantém dados criptografados legíveis e comportamento consistente
Dados do aplicativo	Anexos, avatares, LFS, pacotes, ativos de lançamento, índices	Preserva conteúdo fora dos objetos Git normais
Procedimento de recuperação	Versões, propriedade, regeneração de hooks, etapas de verificação	Transforma arquivos armazenados em um serviço restaurado utilizável

Armazene cópias de recuperação fora do VPS. Criptografe-as quando contiverem código-fonte privado, credenciais, tokens, dados pessoais ou configuração interna. Mantenha mais de um ponto de recuperação, monitore a conclusão do backup e teste uma restauração em um ambiente separado.

Uma reinicialização normal do VPS prova a persistência, não a recuperabilidade. Ela não protege contra exclusão acidental, corrupção de repositório, uma atualização com falha, comprometimento de credenciais, perda de sistema de arquivos, exclusão do VPS ou um atacante excluindo tanto os dados ao vivo quanto os arquivos de backup locais.

Para a linha de base mais ampla de manutenção de servidor em torno de SSH, patching, monitoramento e propriedade de recuperação, veja Gerenciamento de VPS: Guia Prático.

Como você deve atualizar o Gitea?

Atualize o Gitea como uma mudança controlada de aplicativo: leia as notas de lançamento, crie um backup restaurável, preserve o tipo de implantação e verifique repositórios e autenticação depois. A imagem usa um lançamento estável fixo em vez de uma tag flutuante, então uma reinicialização não muda silenciosamente a versão do aplicativo.

Antes de uma atualização:

Leia as notas de lançamento e atualização do Gitea para as versões de origem e destino.
Confirme o caminho de atualização suportado em vez de pular entre versões sem revisão.
Crie e verifique um backup fora do servidor.
Registre a imagem do contêiner atual, configuração, URL pública, configurações SSH e propriedade de armazenamento.
Planeje uma janela de manutenção porque migrações de banco de dados ou consistência de backup podem exigir tempo de inatividade.

Após uma atualização:

Confirme que o contêiner atinge um estado saudável.
Faça login com uma conta normal e uma conta de administrador.
Clone, puxe e envie através de HTTP(S) e SSH.
Abra um problema e um pull request em um repositório de teste.
Verifique webhooks, pacotes, LFS, e-mail e integrações de autenticação que sua instância realmente usa.
Verifique se as URLs de clone geradas ainda usam o domínio e a porta corretos.
Confirme que usuários, repositórios, configuração e segredos sobreviveram à mudança.

Não altere casualmente entre os layouts de contêiner com root e sem root do Gitea; a documentação oficial do Docker observa que seu armazenamento e comportamento SSH diferem. Preserve o modelo de implantação selecionado pela imagem do aplicativo, a menos que você tenha um plano de migração e reversão.

Quanta capacidade de VPS o Gitea precisa?

A capacidade do Gitea depende da concorrência de usuários, contagem e tamanho de repositórios, padrões de operação do Git, pacotes, LFS, indexação, automação e requisitos de retenção de dados. Escolha um plano elegível no fluxo de compra, monitore a carga de trabalho real e mude para uma configuração maior quando pressão sustentada de CPU, memória, disco ou I/O aparecer.

O projeto oficial do Gitea descreve uma instalação para pequenas equipes como relativamente leve, mas essa afirmação não define a capacidade de cada carga de trabalho de repositório. Grandes monorepositórios, clones frequentes, grandes ativos binários, armazenamento de pacotes, indexação de pesquisa e trabalhos automatizados podem mudar substancialmente o perfil de recursos.

Carga de trabalho	Consideração de capacidade
Alguns pequenos repositórios de origem	Apropriado para uma carga de validação de entrada
Pequena equipe de desenvolvimento	Meça operações web e Git concorrentes
Histórico de repositório grande	Planeje espaço em disco, tempo de backup e tráfego de clone
Registro de pacotes ou Git LFS	Planeje armazenamento e transferência separadamente dos objetos Git normais
Vários webhooks ou integrações	Monitore filas, falhas e disponibilidade a jusante
Ações do Gitea	A capacidade do runner é separada e não incluída pela imagem base
Banco de dados externo ou armazenamento de objetos	Requer uma arquitetura projetada e operada separadamente

Observe a pressão da memória, saturação da CPU, capacidade do sistema de arquivos, uso de inode, comportamento de bloqueio do SQLite, reinicializações de contêiner, latência de requisição, operações Git com falha, duração do backup e duração da restauração. O portão de compra mínimo é um ponto de partida validado, não uma promessa de repositórios ou usuários ilimitados.

Erros comuns a evitar

A maioria das falhas iniciais do Gitea vem de tratar um serviço de repositório pré-instalado como uma plataforma totalmente gerenciada. Evite esses erros:

Deixar um assistente de instalação exposto. Use o fluxo de configuração do administrador SSH e mantenha o bloqueio de instalação habilitado.
Abrir registro público sem um plano de abuso. Mantenha o registro desativado, a menos que a inscrição aberta seja intencional.
Expor a porta 3000 como HTTP público. Mantenha-a no loopback e adicione um domínio com HTTPS confiável antes do uso rotineiro da web e do Git HTTPS.
Confundir a porta 2222 com acesso ao shell do VPS. É o endpoint SSH Git do Gitea e não fornece um shell de servidor.
Compartilhar uma única conta de administrador. Use contas individuais e o menor privilégio.
Colocar tokens no histórico do shell ou em arquivos de repositório. Use um armazenamento de credenciais ou segredos apropriado.
Fazer backup apenas dos repositórios Git. Proteja também o banco de dados, configuração, segredos, anexos, LFS, pacotes e procedimento de recuperação.
Manter o único backup no mesmo VPS. Armazene cópias de recuperação criptografadas fora do servidor.
Usar uma tag de contêiner flutuante. Fixe o lançamento estável testado e atualize deliberadamente.
Assumir que a capacidade mínima cobre CI ou grandes binários. Runners, pacotes, LFS, monorepositórios e alta concorrência requerem dimensionamento separado.
Alterar a URL pública sem atualizar o Gitea. Verifique ROOT_URL, domínio, domínio SSH, links de clone, callbacks e webhooks.
Atualizar sem um teste de restauração. Um backup que nunca foi restaurado é um plano de recuperação não verificado.

FAQ

Posso auto-hospedar o Gitea sem instalá-lo manualmente?

Sim. A imagem do aplicativo Gitea da VoyraCloud fornece uma instância pré-instalada do Community Edition em um Cloud VPS ou Residential IP VPS elegível. Você ainda cria o primeiro administrador, configura o acesso ao repositório, conecta um domínio e HTTPS, gerencia usuários e possui atualizações e backups.

Por que o primeiro administrador é criado através do SSH?

O SSH mantém a etapa de criação do administrador atrás do acesso ao VPS e impede que um visitante da internet reivindique um assistente de instalação exposto. A página de instalação pública está bloqueada antes da entrega, e o comando de configuração se recusa a criar outro administrador após um já existir.

Posso expor a porta `3000` diretamente para a internet?

Não. O aplicativo vincula a porta 3000 à interface de loopback do VPS e o primeiro login usa um SSH Tunnel. Conecte um domínio, configure um proxy reverso e HTTPS confiável, e atualize as configurações da URL pública do Gitea antes de publicar o serviço web.

Qual é a diferença entre SSH do VPS e Gitea SSH Git?

O SSH do VPS administra o servidor Linux, enquanto o Gitea SSH Git transfere dados do repositório usando chaves anexadas às contas do Gitea. O VPS usa o host e a porta SSH mostrados para o recurso; o Gitea SSH Git usa o usuário git e a porta 2222.

Devo usar uma senha ou token para Git HTTPS?

Use um token de acesso pessoal com apenas as permissões necessárias para o cliente ou integração. Armazene-o em um helper de credenciais apropriado em vez de incorporá-lo em um repositório, script ou entrada de histórico de shell.

O registro de usuários públicos está habilitado?

Não. A imagem do aplicativo desativa o auto-registro por padrão. O administrador pode criar usuários aprovados ou alterar deliberadamente a política de registro após avaliar abusos, verificação de e-mail e requisitos de controle de acesso.

A imagem inclui runners do Gitea Actions?

Não. A imagem base não provisiona ou opera runners do Actions. A capacidade de execução do runner, isolamento, segredos, acesso à rede e manutenção requerem um design separado.

O que devo fazer backup?

Proteja o banco de dados, repositórios Git, configuração, segredos do aplicativo, anexos, objetos LFS, pacotes, lançamentos e quaisquer outros dados de aplicativo armazenados. Mantenha cópias fora do VPS e teste uma restauração completa.

A VoyraCloud atualiza automaticamente o Gitea?

Não. Novos recursos do VPS recebem o lançamento estável aprovado para a imagem, enquanto cada proprietário controla atualizações posteriores. Leia as notas de atualização oficiais, crie um backup restaurável e teste fluxos de trabalho Git e de autenticação após cada alteração.

O Residential IP VPS é necessário para o Gitea?

Não. O Cloud VPS é a escolha normal de uso geral para um serviço de código-fonte. O Residential IP VPS também é tecnicamente suportado quando uma carga de trabalho mais ampla precisa especificamente de suas características de rede, mas a identidade residencial não melhora a hospedagem Git normal por si só.

Conclusão

A auto-hospedagem do Gitea em um VPS dá aos desenvolvedores e pequenas equipes controle sobre repositórios, contas, dados de colaboração, acesso à rede, atualizações e recuperação. A imagem do aplicativo VoyraCloud encurta a implantação inicial ao fornecer um ambiente Gitea fixo e estável com uma página de instalação bloqueada, configuração privada do primeiro administrador, acesso Git HTTPS e SSH, e dados locais persistentes.

Esse ponto de partida ainda precisa de um proprietário. Adicione HTTPS confiável, use contas individuais e credenciais com escopo, mantenha o registro alinhado com sua política de acesso, monitore a capacidade, fixe atualizações e mantenha backups fora do servidor testados antes de tratar o serviço como infraestrutura crítica.

Para a camada de domínio e proxy reverso em frente ao serviço, veja o guia para Nginx Proxy Manager em um VPS.

Use a imagem do aplicativo VoyraCloud para Gitea para começar a partir de um ambiente VPS pré-instalado enquanto mantém seu serviço de código-fonte sob seu controle.