Skip to main content

​
Why connect Devin to self-hosted systems?

If your organization uses self-hosted source code management systems (like GitLab) or artifact repositories (like Artifactory), you can still take full advantage of Devin SaaS. By securely exposing these services to Devin’s infrastructure, your team maintains control of your systems while enabling Devin to collaborate effectively with your development workflow.

​
Overview

Your team can create a Network Load Balancer (NLB), whitelist Devin’s static IPs, and publish a DNS record for it. This approach:
  • Limits access to a small, controlled surface area - Only Devin’s known IPs can connect
  • Takes less than a few hours of engineering effort to set up
  • Maintains your existing infrastructure - No need to migrate to cloud-hosted solutions
  • Provides centralized management - Optional single load balancer for multiple services

​
Prerequisites

Before setting up the integration, ensure you have:
  • Self-hosted GitLab (or other SCM system) accessible within your network
  • Self-hosted artifact repository (optional) such as Artifactory or Nexus
  • Network administration access to configure firewalls, load balancers, and DNS
  • Devin’s static IP addresses - Found here
This integration is available for Enterprise plan customers. Contact enterprise@cognition.ai if you need assistance.

​
Setup Options

You have two primary approaches for exposing your self-hosted services to Devin: Maintain your existing self-hosted infrastructure and simply whitelist Devin’s static IPs at the firewall level. For Source Code Management:
  1. Configure your firewall to allow inbound connections from Devin’s IPs (listed here)
  2. Ensure your GitLab (or other SCM) instance is accessible via HTTPS
  3. Provide the URL to Devin during integration setup
For Artifact Repositories:
  1. Add Devin’s IPs to your Artifactory/Nexus allowlist
  2. Ensure the artifact repository is accessible via HTTPS
  3. Configure appropriate credentials for Devin to access artifacts
If using a load balancer with your artifact repository, see the Load Balancer Considerations section below for important details about IP allowlisting.

​
Option 2: Centralized Load Balancer

Place multiple services behind a single Application Load Balancer (ALB) or Network Load Balancer (NLB) for centralized IP filtering. Benefits:
  • Single point of management for all network filtering
  • Support multiple internal services with different domains
  • Simplified security auditing and compliance

​
Load Balancer Considerations

When choosing between Application Load Balancer (ALB) and Network Load Balancer (NLB), consider how each handles IP allowlisting: Application Load Balancer (ALB) - Recommended for most use cases:
  • ALB operates at Layer 7 (HTTP/HTTPS) and provides advanced routing capabilities
  • Traffic goes through NAT, so your backend services see the ALB’s internal IP addresses, not Devin’s source IPs
  • For artifact repositories behind ALB: You must configure IP allowlisting directly on Artifactory/Nexus since the load balancer’s internal IP will be seen by the repository
  • Use AWS WAF for IP filtering at the ALB level (see example below)
Network Load Balancer (NLB) - Suitable for IP whitelisting scenarios:
  • NLB operates at Layer 4 (TCP) and preserves the original source IP addresses
  • Your backend services see Devin’s actual source IPs
  • For artifact repositories behind NLB: IP allowlisting at the load balancer level is sufficient since source IPs are maintained
  • Requires manual security group configuration for each IP address
While ALB is generally preferred for its flexibility and ease of management, NLB works well when you need IP allowlisting at the load balancer level without additional configuration on backend services.

​
AWS Implementation Example

Here are example AWS configurations for both load balancer approaches:

​
Application Load Balancer with WAF (Easier)

# Create an IP set with Devin's static IPs
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/...
Replace the IP addresses with the actual IPs from our IP whitelisting documentation.

​
Network Load Balancer (Manual Security Groups)

# Add ingress rules for each Devin IP to your security group
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 1.2.3.4/32

# Repeat for each IP address
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 5.6.7.8/32

# Continue for all Devin IPs...

​
DNS Configuration

After setting up your load balancer, create a DNS record that Devin can use: 
# Example: Point gitlab.yourcompany.com to your load balancer
# The domain will resolve to the load balancer IP, which filters traffic
# to only allow connections from Devin's whitelisted IPs

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

​
Integration Steps

Once your network infrastructure is configured:
  1. Test connectivity - Verify that your services are accessible from outside your network using the configured domain
  2. Contact Devin support - Reach out to Cognition with:
    • Your self-hosted GitLab URL (e.g., https://gitlab.yourcompany.com)
    • Your artifact repository URL (if applicable)
    • Any specific authentication requirements
  3. Complete integration setup - Work with the Devin team to finalize the connection
  4. Configure repositories - Add your repositories to Devin’s Machine
Test your IP filtering configuration before providing access to Devin by attempting to connect from an IP address that’s not on the allowlist. The connection should be blocked.

​
Best Practices

  • Use HTTPS - Always expose services over HTTPS with valid SSL certificates
  • Create a dedicated service account - Set up a specific account for Devin in your GitLab/SCM system
  • Monitor access logs - Regularly review connection logs from Devin’s IPs
  • Document your setup - Keep internal documentation of your load balancer and DNS configuration
  • Test failover - Ensure your setup can handle load balancer or service failures gracefully
  • Regular security audits - Periodically review which services are exposed and verify IP allowlists

​
Troubleshooting

Devin cannot connect to my self-hosted system:
  • Verify that all Devin IP addresses are whitelisted
  • Check that your SSL certificate is valid and trusted
  • Ensure DNS records are properly configured and propagated
  • Verify your firewall rules allow HTTPS (port 443) traffic
Authentication failures:
  • Confirm the service account credentials are correct
  • Verify the service account has appropriate permissions in your SCM/artifact system
  • Check for any IP-based authentication restrictions beyond the allowlist
Performance issues:
  • Monitor your load balancer metrics for bottlenecks
  • Ensure your self-hosted services have adequate resources
  • Consider geographic proximity between your infrastructure and Devin’s systems

​
Support

For assistance with self-hosted integrations:
  1. Create a Slack Connect channel with our team at app.devin.ai/settings/support
  2. Email enterprise@cognition.ai with your specific setup details
  3. Share relevant configuration files (with sensitive data redacted) when reporting issues