Saltar al contenido principal

​
¿Por qué conectar Devin a sistemas autoalojados?

Si tu organización usa sistemas de gestión de código fuente autoalojados (como GitLab) o repositorios de artefactos (como Artifactory), aún puedes sacar el máximo partido de Devin SaaS. Al exponer de forma segura estos servicios a la infraestructura de Devin, tu equipo mantiene el control de sus sistemas mientras permite que Devin colabore eficazmente con tu flujo de trabajo de desarrollo.

​
Descripción general

Tu equipo puede crear un Network Load Balancer (NLB), incluir en la lista de permitidos las IP estáticas de Devin y publicar un registro DNS para el NLB. Este enfoque:
  • Limita el acceso a una superficie de exposición pequeña y controlada: solo las IP conocidas de Devin pueden conectarse
  • Se puede configurar en pocas horas de trabajo de ingeniería
  • Mantiene tu infraestructura existente: no es necesario migrar a soluciones alojadas en la nube
  • Proporciona administración centralizada: un único balanceador de carga opcional para múltiples servicios

​
Requisitos previos

Antes de configurar la integración, asegúrate de contar con:
  • GitLab autohospedado (u otro sistema de control de código fuente, SCM) accesible dentro de tu red
  • Repositorio de artefactos autohospedado (opcional), como Artifactory o Nexus
  • Acceso de administración de la red para configurar firewalls, balanceadores de carga y DNS
  • Direcciones IP estáticas de Devin – se encuentran aquí
Esta integración está disponible para clientes del plan Enterprise. Ponte en contacto con [email protected] si necesitas ayuda.

​
Opciones de configuración

Tiene dos enfoques principales para exponer sus servicios autohospedados a Devin: Mantén tu infraestructura autoalojada existente y simplemente incluye las IP estáticas de Devin en la lista de permitidas a nivel de firewall. Para la gestión de código fuente:
  1. Configura tu firewall para permitir conexiones entrantes desde las IP de Devin (enumeradas aquí)
  2. Asegúrate de que tu instancia de GitLab (u otro SCM) esté accesible mediante HTTPS
  3. Proporciona la URL a Devin durante la configuración de la integración
Para repositorios de artefactos:
  1. Agrega las IP de Devin a la lista de permitidas de tu Artifactory/Nexus
  2. Asegúrate de que el repositorio de artefactos esté accesible mediante HTTPS
  3. Configura las credenciales apropiadas para que Devin pueda acceder a los artefactos
Si utilizas un balanceador de carga con tu repositorio de artefactos, consulta la sección Consideraciones sobre el balanceador de carga a continuación para obtener detalles importantes sobre la lista de IP permitidas.

​
Opción 2: Balanceador de carga centralizado

Coloca varios servicios detrás de un único Application Load Balancer (ALB) o Network Load Balancer (NLB) para un filtrado centralizado de direcciones IP. Beneficios:
  • Punto único de gestión para todo el filtrado de red
  • Admite múltiples servicios internos con distintos dominios
  • Auditorías de seguridad y cumplimiento más sencillas

​
Consideraciones sobre el balanceador de carga

Al elegir entre Application Load Balancer (ALB) y Network Load Balancer (NLB), debes tener en cuenta cómo cada uno gestiona el allowlisting de IP: Application Load Balancer (ALB): recomendado para la mayoría de los casos de uso
  • ALB opera en la capa 7 (HTTP/HTTPS) y proporciona capacidades avanzadas de enrutamiento
  • El tráfico pasa por NAT, por lo que tus servicios backend ven las direcciones IP internas del ALB, no las IP de origen de Devin
  • Para repositorios de artefactos detrás de un ALB: debes configurar el allowlisting de IP directamente en Artifactory/Nexus, ya que el repositorio verá la IP interna del balanceador de carga
  • Usa AWS WAF para el filtrado de IP a nivel de ALB (consulta el ejemplo a continuación)
Network Load Balancer (NLB): adecuado para escenarios de allowlisting de IP
  • NLB opera en la capa 4 (TCP) y conserva las direcciones IP de origen originales
  • Tus servicios backend ven las IP de origen reales de Devin
  • Para repositorios de artefactos detrás de un NLB: el allowlisting de IP a nivel del balanceador de carga es suficiente, ya que se mantienen las IP de origen
  • Requiere configurar manualmente los grupos de seguridad para cada dirección IP
Aunque ALB suele ser preferido por su flexibilidad y facilidad de gestión, NLB funciona bien cuando necesitas allowlisting de IP a nivel del balanceador de carga sin configuración adicional en los servicios backend.

​
Ejemplo de implementación en AWS

A continuación se muestran ejemplos de configuración de AWS para ambos enfoques de balanceador de carga:

​
Application Load Balancer con WAF (más fácil)

# Crear un conjunto de IP con las IP estáticas de 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

# Crear una ACL web de WAF
aws wafv2 create-web-acl \
  --name devin-access-control \
  --scope REGIONAL \
  --default-action Block={} \
  --rules file://waf-rules.json

# Asociar el WAF con tu 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/...
Reemplaza las direcciones IP por las direcciones IP reales que aparecen en nuestra documentación sobre la lista de IP permitidas.

​
Network Load Balancer (grupos de seguridad manuales)

# Agregue reglas de entrada para cada IP de Devin a su grupo de seguridad
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 1.2.3.4/32

# Repita para cada dirección IP
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 5.6.7.8/32

# Continúe para todas las IPs de Devin...

​
Configuración de DNS

Después de configurar su balanceador de carga, cree un registro DNS que Devin pueda utilizar: 
# Ejemplo: Apunte gitlab.suempresa.com a su balanceador de carga
# El dominio se resolverá a la IP del balanceador de carga, que filtra el tráfico
# para permitir solo conexiones desde las IPs en lista blanca de Devin

# Usando AWS Route 53:
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch file://dns-change.json
Ejemplo de dns-change.json: 
{
  "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
      }
    }
  }]
}

​
Pasos de integración

Una vez que tu infraestructura de red esté configurada:
  1. Probar la conectividad - Verifica que tus servicios sean accesibles desde fuera de tu red usando el dominio configurado.
  2. Contactar al soporte de Devin - Comunícate con Cognition y proporciona:
    • La URL de tu GitLab autogestionado (por ejemplo, https://gitlab.yourcompany.com)
    • La URL de tu repositorio de artefactos (si aplica)
    • Cualquier requisito específico de autenticación
  3. Completar la configuración de la integración - Colabora con el equipo de Devin para finalizar la conexión.
  4. Configurar repositorios - Agrega tus repositorios a Devin’s Machine.
Prueba tu configuración de filtrado de IP antes de darle acceso a Devin intentando conectarte desde una dirección IP que no esté en la lista de direcciones permitidas. La conexión debería bloquearse.

​
Mejores prácticas

  • Usar HTTPS - Exponga siempre los servicios mediante HTTPS con certificados SSL válidos
  • Crear una cuenta de servicio dedicada - Configure una cuenta específica para Devin en su sistema GitLab/SCM
  • Supervisar los registros de acceso - Revise periódicamente los registros de conexión desde las direcciones IP de Devin
  • Documentar su configuración - Mantenga documentación interna de su balanceador de carga y de la configuración de DNS
  • Probar la conmutación por error (failover) - Asegúrese de que su configuración pueda manejar correctamente fallos del balanceador de carga o del servicio
  • Auditorías de seguridad periódicas - Revise periódicamente qué servicios están expuestos y verifique las listas de IP permitidas

​
Solución de problemas

Devin no puede conectarse a mi sistema autoalojado:
  • Verifica que todas las direcciones IP de Devin estén incluidas en la lista de direcciones permitidas (allowlist)
  • Comprueba que tu certificado SSL sea válido y de confianza
  • Asegúrate de que los registros DNS estén configurados y propagados correctamente
  • Verifica que las reglas de tu firewall permitan tráfico HTTPS (puerto 443)
Errores de autenticación:
  • Confirma que las credenciales de la cuenta de servicio sean correctas
  • Verifica que la cuenta de servicio tenga los permisos apropiados en tu sistema de SCM/artefactos
  • Revisa si existen restricciones de autenticación basadas en IP más allá de la lista de direcciones permitidas (allowlist)
Problemas de rendimiento:
  • Supervisa las métricas de tu balanceador de carga para detectar cuellos de botella
  • Asegúrate de que tus servicios autoalojados tengan recursos suficientes
  • Considera la proximidad geográfica entre tu infraestructura y los sistemas de Devin

​
Soporte

Para obtener ayuda con integraciones autohospedadas:
  1. Crea un canal de Slack Connect con nuestro equipo en app.devin.ai/settings/support
  2. Envía un correo a [email protected] con los detalles específicos de tu configuración
  3. Comparte los archivos de configuración relevantes (con los datos sensibles omitidos) al reportar problemas