如果您的组织使用自托管的源代码管理系统（如 GitLab）或制品仓库（如 Artifactory），依然可以充分利用 Devin SaaS。通过以安全的方式将这些服务暴露给 Devin 的基础设施，您的团队既能保持对自身系统的控制权，又能让 Devin 高效融入并协同您的开发工作流。
您的团队可以创建一个 Network Load Balancer（NLB），将 Devin 的静态 IP 加入白名单，并为其发布一个 DNS 记录。此方案：
- 将访问限制在一个小且可控的暴露面上 —— 只有 Devin 的已知 IP 可以连接
- 只需数小时内的工程投入 即可完成搭建
- 保留您现有的基础设施 —— 无需迁移到云托管方案
- 提供集中化管理 —— 可选地使用单个负载均衡器来承载多个服务
在设置集成之前，请确保您具备：
- 在您的网络内可访问的 自托管 GitLab（或其他 SCM 系统）
- 自托管制品仓库（可选），例如 Artifactory 或 Nexus
- 用于配置防火墙、负载均衡器和 DNS 的 网络管理访问权限
- Devin 的静态 IP 地址 —— 可在此处找到
您可以通过两种主要方式将自托管服务暴露给 Devin：
保留你现有的自托管基础设施，只需在防火墙层将 Devin 的静态 IP 加入允许列表。
对于源代码管理：
- 将防火墙配置为允许来自 Devin 的 IP（列在此处）的入站连接
- 确保你的 GitLab（或其他 SCM）实例可通过 HTTPS 访问
- 在集成配置时将该 URL 提供给 Devin
对于制品仓库：
- 将 Devin 的 IP 添加到你的 Artifactory/Nexus 允许列表中
- 确保制品仓库可通过 HTTPS 访问
- 为 Devin 配置合适的凭证，以便访问制品
如果在制品仓库前使用负载均衡器，请参阅下方的负载均衡器注意事项部分，了解有关 IP 允许列表的重要细节。
- 为所有网络过滤提供统一管理点
- 支持使用不同域名的多个内部服务
- 简化安全审计和合规工作
在 Application Load Balancer (ALB) 和 Network Load Balancer (NLB) 之间进行选择时，需要考虑它们各自如何处理 IP 允许列表（IP allowlisting）：
Application Load Balancer (ALB) —— 推荐用于大多数场景：
- ALB 工作在第 7 层（HTTP/HTTPS），并提供高级路由能力
- 流量会经过 NAT，因此你的后端服务看到的是 ALB 的内部 IP 地址，而不是 Devin 的源 IP 地址
- 对于位于 ALB 后面的制品仓库： 必须直接在 Artifactory/Nexus 上配置 IP 允许列表，因为仓库看到的是负载均衡器的内部 IP
- 在 ALB 层使用 AWS WAF 进行 IP 过滤（参见下面示例）
Network Load Balancer (NLB) —— 适用于需要 IP 白名单的场景：
- NLB 工作在第 4 层（TCP），并保留原始源 IP 地址
- 你的后端服务可以看到 Devin 的真实源 IP
- 对于位于 NLB 后面的制品仓库： 只在负载均衡器层配置 IP 允许列表即可，因为源 IP 会被保留
- 需要为每个 IP 地址手动配置安全组
虽然 ALB 通常因其灵活性和易于管理而是首选，但当你需要在负载均衡器层进行 IP 允许列表控制、且不希望在后端服务上做额外配置时，NLB 也非常适用。
# 使用 Devin 的静态 IP 创建 IP 集
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
# 创建 WAF Web ACL
aws wafv2 create-web-acl \
--name devin-access-control \
--scope REGIONAL \
--default-action Block={} \
--rules file://waf-rules.json
# 将 WAF 关联到您的 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/...
# 为安全组添加每个 Devin IP 的入站规则
aws ec2 authorize-security-group-ingress \
--group-id sg-xxxxxxxxx \
--protocol tcp \
--port 443 \
--cidr 1.2.3.4/32
# 对每个 IP 地址重复以上操作
aws ec2 authorize-security-group-ingress \
--group-id sg-xxxxxxxxx \
--protocol tcp \
--port 443 \
--cidr 5.6.7.8/32
# 对所有 Devin IP 继续执行此操作...
# 示例：将 gitlab.yourcompany.com 指向您的负载均衡器
# 该域名将解析到负载均衡器 IP，由其过滤流量
# 仅允许来自 Devin 白名单 IP 的连接
# 使用 AWS Route 53：
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch file://dns-change.json
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
}
}
}]
}
- 测试连接性 - 使用已配置的域名验证你的服务是否可以从外部网络访问
- 联系 Devin 支持团队 - 与 Cognition 取得联系，并提供：
- 你的自托管 GitLab URL（例如：
https://gitlab.yourcompany.com）
- 你的制品仓库 URL（如适用）
- 任何特定的身份验证要求
- 完成集成配置 - 与 Devin 团队协作完成连接设置
- 配置代码仓库 - 将你的代码仓库添加到 Devin’s Machine
在为 Devin 开通访问权限之前，通过尝试从一个不在允许列表中的 IP 地址发起连接来测试你的 IP 过滤配置。该连接应当被阻止。
- 使用 HTTPS - 始终通过启用有效 SSL 证书的 HTTPS 对外提供服务
- 创建专用服务账号 - 在 GitLab/SCM 系统中为 Devin 设置专用账号
- 监控访问日志 - 定期审查来自 Devin IP 地址的连接日志
- 记录你的配置 - 在内部文档中记录负载均衡器和 DNS 的配置
- 测试故障切换 - 确保你的配置能够平滑应对负载均衡器或服务故障
- 定期安全审计 - 定期检查对外暴露的服务并验证 IP 允许列表（allowlist）
Devin 无法连接到我的自托管系统：
- 确认所有 Devin IP 地址 都已加入允许列表
- 检查你的 SSL 证书是否有效且受信任
- 确保 DNS 记录配置正确并已完成解析并生效
- 确认防火墙规则允许 HTTPS（443 端口）流量通过
身份验证失败：
- 确认服务账号凭证正确无误
- 确认服务账号在你的 SCM/制品系统中拥有适当的权限
- 检查是否存在超出允许列表之外的基于 IP 的身份验证限制
性能问题：
- 监控负载均衡器的指标以排查潜在瓶颈
- 确保你的自托管服务拥有充足资源
- 考虑你的基础设施与 Devin 的系统之间的地理距离
如需获得有关自托管集成的帮助：
- 通过 app.devin.ai/settings/support 与我们的团队创建一个 Slack Connect 频道
- 发送邮件至 enterprise@cognition.ai，并说明您的具体部署和配置情况
- 在报告问题时，分享相关配置文件（请先删减或遮蔽其中的敏感数据）
