Revisão editorial: .
O NGINX Unit está arquivado e sem manutenção desde outubro de 2025, conforme o aviso do próprio projeto. Por isso, este artigo explica o que muda para quem ainda depende do componente. A existência de uma opção no DirectAdmin não significa que o software continue recebendo manutenção do fabricante.
Se uma aplicação já depende de Unit, o primeiro passo é identificar essa dependência e planejar a continuidade. Antes de desligar o serviço, verifique rotas e processos, pois a interrupção pode tirar o sistema do ar. Para um projeto novo, a recomendação editorial da XFROTA é avaliar uma alternativa mantida e compatível com a aplicação.
O que o NGINX Unit fazia na arquitetura
O NGINX Unit executa aplicações e encaminha requisições conforme suas rotas. Ele pode ficar atrás do servidor web usado pela hospedagem. Isso é diferente de afirmar que todo site hospedado no DirectAdmin utiliza Unit: cada domínio pode ter uma configuração própria.
A documentação do DirectAdmin descreve a criação de uma aplicação e de uma rota no painel. Essa documentação ajuda a entender uma instalação existente. No entanto, ainda é necessário verificar a manutenção do componente.
Como saber se seu site depende dele
- Primeiro, peça ao administrador a relação de aplicações e rotas do Unit associadas ao domínio.
- Em seguida, identifique a linguagem, o ponto de entrada da aplicação e o usuário que executa os processos.
- Depois, confira se o servidor web encaminha o domínio ou algum caminho específico para o Unit.
- Por fim, registre dependências que ficam fora dele: banco, arquivos enviados, tarefas agendadas, filas e serviços externos.
Por exemplo, o site institucional pode usar PHP-FPM, enquanto apenas /api/ é encaminhado para outra aplicação. Nesse cenário, migrar o WordPress não resolve a dependência da API. Portanto, o inventário precisa abranger os caminhos efetivamente utilizados.
Roteiro para uma migração controlada
1. Escolha o destino pela aplicação
Registre requisitos de linguagem, versões, extensões, conexões persistentes e permissões. Em seguida, compare formas de executar a aplicação. Evite escolher um substituto apenas por uma promessa genérica de velocidade.
2. Reproduza o serviço em um ambiente separado
Prepare uma cópia com dados adequados ao teste. Antes dos testes, suspenda nela os disparos de e-mail, cobranças e integrações que poderiam produzir ações reais. Restrinja o acesso à equipe envolvida.
3. Teste os caminhos que geram trabalho
A página inicial abrir não basta. Por isso, teste autenticação, envio de arquivos, rotas de API, tarefas em segundo plano e respostas de erro. Compare o comportamento no ambiente antigo e no novo com os mesmos casos de teste.
4. Defina a virada e o retorno
Combine uma janela, faça uma cópia recente dos dados e registre qual configuração será alterada. Determine quem verifica o resultado e em que situação será necessário voltar. Se houver gravações de dados durante a transição, planeje como evitar perda ou divergência.
O que registrar para considerar o trabalho validado
- Domínio e caminhos migrados.
- Versões e configuração do ambiente de destino.
- Resultado dos testes de login, uploads, rotas e integrações.
- Erros encontrados e respectivas correções.
- Local do backup e procedimento de retorno.
- Responsável e data da validação.
Assim, esse registro permite distinguir uma mudança de configuração de uma migração efetivamente testada. Para preparar as cópias, consulte o guia de backup e restauração no DirectAdmin.
Como a XFROTA pode ajudar
Ao solicitar uma avaliação, informe o domínio, a aplicação e o problema observado, sem enviar senhas. Antes de propor alterações no NGINX Unit, a análise deve identificar o que está em uso. Este artigo não afirma que uma migração já foi executada no seu ambiente nem recomenda interromper um serviço em produção sem planejamento.
