​
Overview

Devin’s in-VPC deployment offering allows hosting Devin’s development environments in your VPC, which enables Devin’s VMs to access proprietary resources behind your corporate firewall. The supported architecture offers an entirely stateless system guarantee, meaning that no data will be stored at rest outside of your environment.

There are multiple ways to establish fine-grained control over Devin’s access within your environment, including but not limited to customer services or resources via SSO or version control system access controls.

Trust Center

For additional information and security documentation, visit our Trust Center.

​
Core Architecture

Devin consists of two primary components:

​
Devin’s DevBox

A customizable development environment where Devin’s actions are executed. Includes shell, editor, and browser capabilities. Deployed inside the customer’s VPC.

​
Devin’s Brain

The core intelligence system that processes snippets of context to determine every Devin action. Hosted in Cognition’s tenant.

Devin Enterprise Architecture

​
Deployment Specifications

​
Infrastructure Requirements

Instance Type Requirements:

  • AWS: i3 bare metal EC2
  • Azure: Lasv3 instances with Security Type standard

Every Devin session requires a new VM. These instance types allow ad-hoc creation of VMs for Devin session start. Visit AWS VPC Setup to see concurrency capacity per instance.

Operating System: Ubuntu 24.04

​
Architecture

Tenant Architecture Diagram

  • The Cognition tenant is hosted on Azure
  • Ports: HTTPS/443 (Only outbound from customer VPC is required)
  • On DevBox startup, a websocket opens and connects to an isolated container in the Devin tenant
  • All subsequent exchanges happen over this connection
  • This architecture supports backend session isolation by default

Granting internet access to Devin’s in-VPC instances is strongly recommended

​
Data Management

​
Cognition Database

  • Stores metadata only
  • Contains hash reference data (session IDs, event IDs, etc.)

​
Customer Databases

Customer data are split into two locations:

  1. Primary customer DB:

    • Connects directly with Devin’s brain
    • Stores encrypted session logs and customer Devin data

  2. Secondary customer DB:

    • Connects to the in-VPC instance
    • Stores VM snapshots, allowing sessions to be started from a snapshot

All customer data is encrypted with a custom KMS key. All database read/write operations are performed through native APIs.

​
Secrets

Isolated Devin Brain containers, authorized to the customer data store, are created for each new session. Secrets are decrypted at the start of a session, loaded as environment variables, then re-encrypted. This process is programmatic.

Prior to being sent to the frontend, secrets are redacted and are shown as [REDACTED SECRET].

​
Security

​
Encryption

  • AES 256 encryption at rest
  • TLS 1.3+ encryption in transit

​
Isolation

  • Isolated Devin Brain container per session
  • AWS WAF for public frontend APIs

​
DevBox Components

The following are loaded onto Devin’s machine:

  1. Core Utilities: git, python, java, docker, and more

  2. Custom Components:

    • VSCode server
    • VNC server for interactive browser control
    • Proprietary utility .py scripts necessary for Devin’s functionality

You may audit the scripts and reduce the default package installation as desired. Request the DevBox setup scripts from your Cognition representative.

​
Limitations

​
Technical Constraints

  • Concurrent session limits based on bare metal instance capacity
  • Capacity can be scaled horizontally by provisioning more base instances
  • These instances may be temporarily spun down during periods of lower usage
  • Customer is responsible for cloud infrastructure costs

​
Deployment Restrictions

  • No support for customer AMIs. One-time manual machine setup is required
  • No support for non-linux OSs

​
DNS Configuration

Devin instance’s DNS configuration requires proper setup to resolve records in private hosted zones. If you encounter DNS resolution issues with private records, follow the steps below.

To enable Devin instances to resolve records in private hosted zones:

  1. Update the DNS configuration to use the VPC DNS resolver (.2 address) instead of public resolvers. In order to get this run the following:
aws ec2 describe-vpcs --vpc-id <VPC_ID> --query 'Vpcs[0].CidrBlock' --output text | awk -F/ '{split($1,a,"."); print a[1]"."a[2]"."a[3]".2"}'
  1. Edit the systemd resolved configuration file: 
    sudo nano /etc/systemd/resolved.conf
  2. Replace the DNS entry with the VPC’s .2 address. 
    [Resolve]
DNS={N.N.N.2}
  3. Restart the systemd-resolved service to apply the changes: 
    sudo systemctl restart systemd-resolved

This configuration ensures that Devin instances can properly resolve both public DNS records and private records in your hosted zones.