> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.
# SCM e artefatos auto-hospedados
> Conecte o Devin aos seus sistemas de gerenciamento de código-fonte e repositórios de artefatos auto-hospedados
## Por que conectar o Devin a sistemas auto-hospedados?
Se a sua organização usa sistemas de gerenciamento de código-fonte auto-hospedados (como o GitLab) ou repositórios de artefatos (como o Artifactory), você ainda pode tirar total proveito do Devin. Ao expor esses serviços com segurança à infraestrutura do Devin, sua equipe mantém o controle dos seus sistemas enquanto permite que o Devin colabore de forma eficaz com o seu fluxo de desenvolvimento.
## Visão geral
Sua equipe pode criar um Network Load Balancer (NLB), colocar os IPs estáticos do Devin em uma allowlist e publicar um registro DNS para ele. Essa abordagem:
* **Limita o acesso a uma superfície pequena e controlada** – Apenas os IPs conhecidos do Devin podem se conectar
* **Exige menos de algumas horas** de esforço de engenharia para configurar
* **Mantém sua infraestrutura atual** – Não é necessário migrar para soluções em nuvem
* **Fornece gerenciamento centralizado** – Balanceador de carga único opcional para vários serviços
## Pré-requisitos
Antes de configurar a integração, certifique-se de que você tenha:
* **GitLab auto-hospedado** (ou outro sistema de SCM) acessível na sua rede
* **Repositório de artefatos auto-hospedado** (opcional), como Artifactory ou Nexus
* **Acesso de administração de rede** para configurar firewalls, balanceadores de carga e DNS
* **Endereços IP estáticos do Devin** – disponíveis [aqui](/pt-BR/admin/common-issues#ip-whitelisting)
Essa integração está disponível para clientes do plano Enterprise. Entre em contato com [enterprise@cognition.ai](mailto:enterprise@cognition.ai) se precisar de assistência.
## Opções de configuração
Você tem duas abordagens principais para tornar seus serviços self-hosted acessíveis ao Devin:
### Opção 1: Lista de permissões de IP direta (Recomendado)
Mantenha sua infraestrutura auto-hospedada existente e simplesmente inclua os IPs estáticos do Devin na lista de permissões no nível do firewall.
**Para Gerenciamento de Código-Fonte (SCM):**
1. Configure seu firewall para permitir conexões de entrada a partir dos IPs do Devin (listados [aqui](/pt-BR/admin/common-issues#ip-whitelisting))
2. Certifique-se de que sua instância do GitLab (ou outro SCM) esteja acessível via HTTPS
3. Forneça a URL ao Devin durante a configuração da integração
**Para Repositórios de Artefatos:**
1. Adicione os IPs do Devin à allowlist do seu Artifactory/Nexus
2. Certifique-se de que o repositório de artefatos esteja acessível via HTTPS
3. Configure as credenciais apropriadas para o Devin acessar os artefatos
Se estiver usando um load balancer com seu repositório de artefatos, consulte a seção [Load Balancer Considerations](#load-balancer-considerations) abaixo para detalhes importantes sobre a lista de permissões de IPs.
### Opção 2: Load Balancer centralizado
Coloque vários serviços atrás de um único Application Load Balancer (ALB) ou Network Load Balancer (NLB) para filtragem centralizada de IPs.
**Benefícios:**
* Único ponto de gerenciamento para toda a filtragem de rede
* Suporte a vários serviços internos com domínios diferentes
* Auditorias de segurança e conformidade simplificadas
## Considerações sobre o Load Balancer
Ao escolher entre Application Load Balancer (ALB) e Network Load Balancer (NLB), considere como cada um lida com allowlisting de IP:
**Application Load Balancer (ALB) - Recomendado para a maioria dos casos de uso:**
* O ALB opera na camada 7 (HTTP/HTTPS) e oferece recursos avançados de roteamento
* O tráfego passa por NAT, então seus serviços de backend veem os endereços IP internos do ALB, e não os IPs de origem do Devin
* **Para repositórios de artefatos por trás de um ALB:** você deve configurar o allowlisting de IP diretamente no Artifactory/Nexus, já que o IP interno do load balancer será visto pelo repositório
* Use o AWS WAF para filtragem de IP no nível do ALB (veja o exemplo abaixo)
**Network Load Balancer (NLB) - Adequado para cenários de allowlisting de IP:**
* O NLB opera na camada 4 (TCP) e preserva os endereços IP de origem
* Seus serviços de backend veem os IPs de origem reais do Devin
* **Para repositórios de artefatos por trás de um NLB:** o allowlisting de IP no nível do load balancer é suficiente, já que os IPs de origem são mantidos
* Requer configuração manual de grupos de segurança (security groups) para cada endereço IP
Embora o ALB geralmente seja preferido por sua flexibilidade e facilidade de gerenciamento, o NLB funciona bem quando você precisa de allowlisting de IP no nível do load balancer, sem configuração adicional nos serviços de backend.
## Exemplo de implementação na AWS
Aqui estão exemplos de configurações da AWS para as duas abordagens de balanceador de carga:
### Application Load Balancer com WAF (Mais fácil)
```bash theme={null}
# Criar um conjunto de IPs com os IPs estáticos do Devin
aws wafv2 create-ip-set \
--name devin-allowed-ips \
--scope REGIONAL \
--ip-address-version IPV4 \
--addresses 1.2.3.4/32 5.6.7.8/32 9.10.11.12/32 13.14.15.16/32
# Create a WAF web ACL
aws wafv2 create-web-acl \
--name devin-access-control \
--scope REGIONAL \
--default-action Block={} \
--rules file://waf-rules.json
# Associate the WAF with your ALB
aws wafv2 associate-web-acl \
--web-acl-arn arn:aws:wafv2:region:account:regional/webacl/... \
--resource-arn arn:aws:elasticloadbalancing:region:account:loadbalancer/app/...
```
Substitua os endereços IP pelos IPs corretos da nossa [documentação de IPs permitidos](/pt-BR/admin/common-issues#ip-whitelisting).
### Balanceador de Carga de Rede (grupos de segurança manuais)
```bash theme={null}
# Adicione regras de entrada para cada IP do Devin no seu grupo de segurança
aws ec2 authorize-security-group-ingress \
--group-id sg-xxxxxxxxx \
--protocol tcp \
--port 443 \
--cidr 1.2.3.4/32
# Repita para cada endereço IP
aws ec2 authorize-security-group-ingress \
--group-id sg-xxxxxxxxx \
--protocol tcp \
--port 443 \
--cidr 5.6.7.8/32
# Continue para todos os IPs do Devin...
```
### Configuração de DNS
Depois de configurar o balanceador de carga, crie um registro de DNS que o Devin possa usar:
```bash theme={null}
# Exemplo: Aponte gitlab.suaempresa.com para o seu balanceador de carga
# O domínio será resolvido para o IP do balanceador de carga, que filtra o tráfego
# para permitir apenas conexões dos IPs na lista de permissões do Devin
# Usando o AWS Route 53:
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch file://dns-change.json
```
Exemplo de arquivo `dns-change.json`:
```json theme={null}
{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "gitlab.yourcompany.com",
"Type": "A",
"AliasTarget": {
"HostedZoneId": "Z215JYRZR1TBD5",
"DNSName": "your-alb-name-123456.us-west-2.elb.amazonaws.com",
"EvaluateTargetHealth": false
}
}
}]
}
```
## Etapas de integração
Após a configuração da infraestrutura de rede:
1. **Teste a conectividade** - Verifique se seus serviços estão acessíveis de fora da sua rede usando o domínio configurado
2. **Entre em contato com o suporte da Devin** - Fale com a Cognition e informe:
* A URL do seu GitLab auto-hospedado (por exemplo, `https://gitlab.yourcompany.com`)
* A URL do seu repositório de artefatos (se aplicável)
* Quaisquer requisitos específicos de autenticação
3. **Conclua a configuração da integração** - Trabalhe com a equipe da Devin para finalizar a conexão
4. **Configure os repositórios** - Adicione seus repositórios à [Devin's Machine](https://app.devin.ai/machine)
Teste sua configuração de filtragem de IP antes de fornecer acesso à Devin, tentando se conectar a partir de um endereço IP que não esteja na lista de permissões (allowlist). A conexão deve ser bloqueada.
## Melhores práticas
* **Use HTTPS** - Sempre exponha os serviços via HTTPS com certificados SSL válidos
* **Crie uma conta de serviço dedicada** - Configure uma conta específica para o Devin no seu sistema GitLab/SCM
* **Monitore os logs de acesso** - Revise regularmente os logs de conexão a partir dos IPs do Devin
* **Documente sua configuração** - Mantenha documentação interna do seu balanceador de carga e da configuração de DNS
* **Teste o failover** - Garanta que sua configuração consiga lidar de forma adequada com falhas do balanceador de carga ou do serviço
* **Realize auditorias de segurança regulares** - Revise periodicamente quais serviços estão expostos e verifique as listas de permissões de IP
## Solução de problemas
**Devin não consegue se conectar ao meu sistema autogerenciado (self-hosted):**
* Verifique se todos os [endereços IP do Devin](/pt-BR/admin/common-issues#ip-whitelisting) estão na lista de permissões (allowlist)
* Confira se o seu certificado SSL é válido e confiável
* Certifique-se de que os registros de DNS estejam configurados corretamente e já tenham se propagado
* Verifique se as regras de firewall permitem tráfego HTTPS (porta 443)
**Falhas de autenticação:**
* Confirme se as credenciais da conta de serviço (service account) estão corretas
* Verifique se a conta de serviço tem as permissões apropriadas no seu sistema de SCM/artefatos
* Verifique se há restrições de autenticação baseadas em IP além da allowlist
**Problemas de desempenho:**
* Monitore as métricas do seu balanceador de carga para identificar gargalos
* Certifique-se de que seus serviços autogerenciados (self-hosted) tenham recursos suficientes
* Considere a proximidade geográfica entre a sua infraestrutura e os sistemas do Devin
## Suporte
Para obter ajuda com integrações em ambiente self-hosted:
1. Crie um canal Slack Connect com nossa equipe em [app.devin.ai/settings/support](https://app.devin.ai/settings/support)
2. Envie um e-mail para [enterprise@cognition.ai](mailto:enterprise@cognition.ai) com os detalhes específicos da sua configuração
3. Compartilhe arquivos de configuração relevantes (com dados confidenciais ocultos) ao relatar problemas