Git Deploy

A aba Git Deploy no Portal conecta seu servidor a um repositório Git no GitHub, GitLab, Gitea ou Forgejo. Os arquivos dele são copiados para o seu servidor automaticamente — a cada push, quando você publica uma release, quando envia uma tag, ou com o clique de um botão. Se quiser, o seu servidor é parado com segurança antes do deploy e iniciado de novo depois.

Resumindo: envie o seu código e, alguns segundos depois, ele está rodando no seu servidor. Sem mais upload via SFTP, sem descompactar arquivos ZIP no gerenciador de arquivos, sem reinícios esquecidos.

O que você vai aprender

• Como conectar um repositório, com o app GitHub Daki Git Deploy ou com um token de acesso
• Quando um deploy é executado e como disparar um você mesmo
• Como manter mundos, bancos de dados e arquivos .env seguros com caminhos protegidos
• Como funcionam os reinícios, o histórico de deploys, os rollbacks e o status no seu repositório
• Como dar à sua equipe as permissões certas

Para quem é

• Desenvolvedores de bots do Discord e de apps Node.js, Python ou Java cujo código já está no GitHub ou no GitLab.
• Redes de Minecraft e equipes de servidores de jogos que mantêm plugins, configurações ou datapacks em um repositório e querem que as mudanças sejam publicadas de forma rastreável.
• Equipes: várias pessoas trabalham no repositório, o servidor está sempre atualizado, e as permissões dos subusuários definem exatamente quem pode fazer deploy.
• Projetos baseados em releases: só versões publicadas (por exemplo, um .jar pronto de uma release) chegam ao servidor, não cada trabalho em andamento.

Antes de começar

• Um servidor no Portal que mostre a aba Git Deploy. Ela fica na navegação do servidor, em Essentials, logo após Files por padrão.
• Um repositório no GitHub (github.com), GitLab (gitlab.com ou sua própria instância, incluindo subgrupos como grupo/subgrupo/projeto), Gitea ou Forgejo (por exemplo, Codeberg ou sua própria instância). Repositórios públicos e privados funcionam.

Início rápido com GitHub (recomendado)

O caminho mais rápido: conecte-se pelo Daki Git Deploy, o app oficial do GitHub da Daki Hosting. Você entra no GitHub e escolhe os seus repositórios — sem token e sem webhook.

1. 1

   Abra a aba Git Deploy

   No Portal, abra o seu servidor e vá para a aba Git Deploy. Em Git service, escolha GitHub.

2. 2

   Conecte com o GitHub

   Na caixa GitHub access, clique em Connect with GitHub. Entre no GitHub e autorize o app.

   Na primeira vez, o GitHub leva você direto para escolher quais repositórios o app pode acessar (All repositories ou apenas alguns selecionados) — uma etapa só, em vez de duas. Depois, você volta ao Portal, e a caixa GitHub access mostra Connected via Daki Git Deploy as com o seu nome no GitHub. A caixa Webhook confirma que não há nada para configurar: os pushes e as releases chegam pelo app sozinhos.

3. 3

   Escolha o seu repositório e o branch

   Clique em Choose from my repositories e selecione o seu repositório, ou cole a URL web ou de clone, ou informe o caminho. Clique em Load branches e escolha o branch que será publicado. Deixe o campo vazio para usar o branch padrão do repositório.

4. 4

   Escolha quando e como fazer o deploy

   Em When to deploy, escolha um modo (por exemplo, Every push). Depois, defina a pasta de destino, os seus caminhos protegidos e o comportamento de reinício.

5. 5

   Salve

   Clique em Save settings na barra na parte inferior. Pronto: o cabeçalho da aba mostra Automatic deploys on, e o seu próximo push será publicado automaticamente. Para fazer o deploy agora mesmo, clique em Deploy now no canto superior direito.

• Permitir outro repositório: Choose repositories on GitHub abre de novo a seleção de repositórios no GitHub, onde você escolhe a quais repositórios o Daki Git Deploy pode acessar.
• Remover a conexão: clique em Disconnect. Depois disso, o servidor não faz mais deploy a partir de repositórios privados.

Início rápido com um token de acesso

Para GitLab, Gitea e Forgejo — e para o GitHub, se você preferir — você salva um token de acesso pessoal. Repositórios públicos funcionam sem nenhum token.

1. 1

   Escolha o serviço Git

   Abra o seu servidor → Git Deploy e escolha o Git service. Para a sua própria instância de GitLab, Gitea ou Forgejo, informe a URL do servidor (por exemplo, https://codeberg.org ou https://git.example.com). Para o gitlab.com, deixe o campo vazio.

2. 2

   Informe o repositório

   Informe o repositório como um caminho (dono/nome) ou simplesmente cole a URL web ou de clone dele. Para um repositório público, só isso basta — sem token, a caixa de acesso mostra No token – public repositories only.

3. 3

   Salve um token para repositórios privados

   No GitHub, primeiro clique em Use an own access token instead na caixa GitHub access. Depois, crie um token no seu provedor Git — o link Create a token on … no Portal leva você direto à página certa — e salve-o em Personal access token. O Portal verifica o token imediatamente. Veja Permissões do token para as permissões que ele precisa.

4. 4

   Escolha as suas configurações e salve

   Escolha quando fazer o deploy, a pasta de destino, os caminhos protegidos e o comportamento de reinício, depois clique em Save settings.

5. 5

   Adicione o webhook

   A caixa Webhook mostra o Payload URL e o Secret, cada um com um botão de copiar. Adicione-os ao seu repositório conforme descrito em Configure o webhook. Abaixo da caixa, Last delivery mostra se o webhook está chegando.

6. 6

   Ative os deploys automáticos

   Ative Automatic deploys active.

Permissões do token

Se apenas a permissão de escrita para o status estiver faltando, o seu servidor ainda recebe o deploy — o log do deploy mostra uma observação.

Configure o webhook

Quando um deploy é executado

Em When to deploy, escolha um dos quatro modos:

Gatilhos

• Webhook: o seu provedor Git informa as mudanças imediatamente, e o deploy começa em segundos. Com o app do GitHub, isso acontece automaticamente, sem um webhook seu.
• Verificações de atualização (polling): opcionais, para casos em que o seu provedor Git não consegue acessar o Portal. Intervalos de 5 minutos a 1 dia.
• Deploy now: a qualquer momento, com o clique de um botão. No modo de releases, você pode escolher uma release específica.
• Pular um push: coloque [skip deploy] na mensagem do commit e esse push não é publicado. [deploy skip] e [no deploy] também funcionam.

Aguarde as verificações de CI

Com Wait for CI checks ativado (somente no modo Every push), um commit só é publicado quando o CI dele está verde — GitHub Actions, GitLab CI e Gitea/Forgejo Actions são suportados. Se o CI falhar, o deploy é ignorado.

Todas as configurações explicadas

As mudanças só têm efeito depois que você clica em Save settings. Enquanto houver algo não salvo, uma barra na parte inferior mostra Discard e Save settings, e Deploy now fica bloqueado.

Remove files that were deleted from the repository remove apenas arquivos que um deploy anterior gravou — nunca caminhos protegidos e nunca arquivos criados por você. Pastas vazias permanecem no lugar.

Caminhos protegidos

Arquivos e pastas em Protected paths nunca são sobrescritos nem excluídos por um deploy. Se ainda não existirem, são criados uma única vez. Perfeito para mundos de jogos, bancos de dados e senhas.

Escreva uma regra por linha, relativa à pasta de destino. Linhas vazias e linhas que começam com # são ignoradas. * nunca corresponde através de um /.

Exemplos típicos:

world/
world_nether/
world_the_end/
plugins/*/config.yml
whitelist.json
ops.json
banned-*.json

.env
*.db
*.sqlite
node_modules/
data/

.env
*.db
venv/

Comportamento de reinício

If the server does not stop: alguns programas, especialmente apps Node.js, ignoram o sinal de parada. Nesse caso, o servidor é encerrado à força depois do tempo que você escolher (imediatamente, de 5 segundos até 5 minutos; Kill after 10 seconds por padrão), para que o deploy não fique travado. Encerrar na hora é o mais rápido, mas não dá tempo ao servidor para salvar nada.

O que acontece durante um deploy

1. Um gatilho (push, release, tag, verificação de atualização ou botão) cria um deploy.
2. Se Wait for CI checks estiver ativado, ele espera pelas verificações de CI verdes (Waiting).
3. O Portal baixa o arquivo compactado do seu provedor Git. As suas credenciais nunca saem do Portal e nunca chegam ao seu servidor.
4. O arquivo é preparado: apenas a pasta escolhida, com os caminhos protegidos filtrados, e conteúdo inseguro, como links simbólicos, é descartado.
5. Conforme as suas configurações, o servidor é parado (e encerrado à força depois do tempo escolhido, se necessário).
6. Os arquivos são gravados na pasta de destino; opcionalmente, arquivos excluídos no repositório são removidos.
7. Conforme as suas configurações, o servidor é iniciado de novo.
8. O resultado e o log completo aparecem no histórico — e, se ativado, como status no commit.

Um deploy normalmente leva de 10 a 40 segundos, além do tempo que o seu servidor precisa para parar.

Histórico, logs e rollback

A lista Deployments no final da aba mostra cada deploy com o seu status, branch e commit (por exemplo main @ 75cd0a1), número, gatilho, a pessoa que o iniciou, o horário e a mensagem do commit. O cabeçalho da aba mostra quando o servidor foi publicado pela última vez.

• Log: cada deploy tem um log ao vivo, que é atualizado enquanto o deploy roda. Hide log fecha o log de novo.
• Rollback com um clique: clique em Deploy again em um deploy anterior para publicar aquele estado mais uma vez.
• Cancelar: deploys em Waiting ou Scheduled podem ser cancelados.

Vários servidores podem fazer deploy ao mesmo tempo, mas cada servidor roda apenas um deploy por vez. Um novo gatilho substitui um deploy mais antigo que ainda está esperando.

Status no seu repositório

Com Show deploys in the repository ativado, o seu commit mostra um status Daki Hosting / nome do seu servidor: amarelo enquanto o deploy roda, depois um check verde ou um X vermelho, com um link para a aba Git Deploy.

• No GitHub, um deploy também aparece em Deployments, com o nome do seu servidor como ambiente.
• Com o app do GitHub, o status é escrito pelo Daki Git Deploy e mostra o logo dele; não há mais nada para configurar. Com um token, mostra a foto da conta do token, e o token precisa de permissões de escrita (veja Permissões do token).
• Você pode desligar isso por servidor. Somente o status e o link são públicos — sem logs e sem detalhes de erros.

Equipes e permissões de subusuários

Subusuários recebem o próprio grupo de permissões Git Deploy:

Subusuários não têm acesso ao Git Deploy por padrão — você decide quem recebe qual permissão. O dono do servidor sempre pode fazer tudo.

Segurança

• Tokens e segredos são armazenados criptografados e nunca são enviados ao seu navegador.
• Com o app do GitHub, não há nenhum token seu de longa duração para os deploys: cada deploy usa uma chave de curta duração (1 hora) que chega apenas ao repositório do seu servidor.
• O seu próprio acesso ao GitHub decide quais repositórios você pode conectar. Ninguém consegue trazer repositórios de outra pessoa para o próprio servidor.
• Os webhooks são assinados com um segredo próprio para cada servidor. Entregas com segredo errado ou para outro repositório são rejeitadas.
• Somente a pessoa que salvou o token pode alterar o repositório, então subusuários não conseguem usar o token do dono para carregar outros repositórios privados.
• Se você mudar o Git service ou a URL do servidor, o token salvo é excluído automaticamente ao salvar.
• Caminhos protegidos nunca são sobrescritos, e Remove files that were deleted from the repository só exclui o que o Git Deploy gravou.
• O status público no seu repositório não contém logs nem detalhes de erros.

Limitações conhecidas

• Um repositório e um acesso por servidor.
• Cada servidor roda apenas um deploy por vez.
• O status no seu repositório só aparece quando o deploy de fato começa, não enquanto ele espera pelo CI.
• Arquivos de release só são extraídos se forem arquivos .zip; um .tar.gz é enviado como arquivo.
• Pastas vazias permanecem no lugar depois de Remove files that were deleted from the repository.
• Links simbólicos no repositório não são publicados.
• O GitLab não tem pré-releases; uma release com data futura conta como pré-release.
• GitLab: arquivos de release enviados ao projeto (/uploads/…) não podem ser baixados com um token de projetos privados; links para o registro de pacotes funcionam.
• Connect with GitHub só está disponível para o GitHub; GitLab, Gitea e Forgejo usam um token.

Perguntas frequentes e solução de problemas

Próximos passos

• Subusuários — Dê acesso à sua equipe e decida quem pode fazer deploy.
• Variáveis de ambiente — Mantenha tokens e senhas fora do seu repositório.
• Configurações de inicialização — Defina o comando de inicialização com o qual o seu código publicado roda.
• Backups — Salve backups automáticos do seu servidor no Google Drive.