Devin Connect

​

What Devin Connect does

• Reverse tunnel: the Gateway dials outbound to a Devin-side endpoint over TLS and Devin sends connection requests back down that tunnel. Nothing is opened inbound to your network, and no cloud-provider integration is needed.
• AWS PrivateLink: you front the Gateway with a Network Load Balancer and a VPC Endpoint Service, and Cognition consumes it with an Interface VPC Endpoint in your dedicated tenant VPC. Traffic stays on the AWS backbone and Devin dials the Gateway directly over private IPs.

• Dedicated single-tenant VPC. Your Devin deployment runs in its own VPC (see the Customer Dedicated Deployment model). Devin VMs send traffic for your routed destinations toward the Gateway via Cognition-configured egress control.
• Default-deny, enforced twice. Routes are enforced on the Gateway and on the Devin side, so a config-only change on one side cannot widen access. Routing a destination never widens a session’s permissions: the session’s security profile still has to allow it.
• Your application TLS is end-to-end. The Gateway forwards opaque byte streams.
• DNS stays inside your network. Route targets are resolved by your resolvers (the Gateway host’s system resolver by default, or nameservers you configure).
• One deployment covers every routed destination. You add hostnames and IPv4 ranges in Devin settings rather than building per-service plumbing.

​

Choosing a connectivity mode

​

Configure Devin Connect

1. Choose “Add gateway”, give it a name, and pick a connection: “Tunnel” for the reverse tunnel, or “Direct” for AWS PrivateLink. For “Direct”, also enter the interface endpoint’s DNS name and port (see the AWS PrivateLink tab).
2. On the gateway’s card, choose “Add destination” for each destination Devin should reach through it: an exact hostname, or an IPv4 address or CIDR such as 10.20.0.0/16. Wildcards are not supported. A destination can belong to only one gateway.
3. For a tunnel gateway, choose “Generate token” to enroll it. The enrollment token is shown once, is never stored by Devin, and can be rotated or revoked at any time with “Regenerate token”. Direct gateways have no tunnel to authenticate, so this step does not apply.
4. For a tunnel gateway, copy the deployment snippet for your platform (Docker, Kubernetes, AWS ECS, Terraform on ECS or EC2, or a Linux host). The snippet contains a ready-to-run config.yaml built from the gateway’s destinations, so re-copy it after changing them.

​

Hostname and IPv4 destinations

• Hostnames are matched on the name the session connects to, read from the TLS SNI or the HTTP Host header. They therefore route TLS and plain HTTP traffic only. The Gateway resolves the name with your DNS.
• IPv4 addresses and CIDRs are matched on the destination IP of the connection, so they route any TCP protocol, including SSH and database connections. Devin does not resolve your internal names for these routes: sessions connect by IP address, or you provide name resolution in the environment, for example /etc/hosts entries set up in your blueprint.

​

Connectivity modes

• Reverse tunnel
• AWS PrivateLink

The Gateway dials out N TLS tunnels to your tenant endpoint, <customer>.gateway.devinenterprise.com:443. You never open an inbound port. A registered tunnel only carries streams that the Devin side opens toward your Gateway; it is not an inbound path into Devin.Enrollment works like this:

1. Devin issues you an enrollment token for the tunnel gateway from the “Devin Connect” settings page.
2. You install the token on the Gateway host at the path tunnel.auth_token_file points to.
3. The Gateway dials <customer>.gateway.devinenterprise.com:443, verifies the Devin edge’s server certificate, and presents the token.
4. The edge validates the token (constant-time comparison against a stored digest; the raw token is never stored on the Devin side) and registers the tunnel. Devin-side dials for the gateway’s destinations then flow through it.

The tunnel is configured with a tunnel stanza and no listen address, so the Gateway host exposes no proxy port at all:

tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  # Enrollment token, one line; re-read on every connection attempt so it
  # can be rotated without a restart.
  auth_token_file: /etc/devin-gateway/tunnel-token
  # carrier: websocket   # default; use `direct` to disable WebSocket framing.
  # ca_file: corp-ca.pem # only if a corporate TLS-inspection proxy re-signs
  #                      # the edge connection.
  # egress_proxy:        # customer egress HTTP CONNECT proxy, if required.
  #   addr: proxy.corp.example:3128

Field	Description
endpoint	Your tenant endpoint, <customer>.gateway.devinenterprise.com:443.
gateway_id	Identifier for this Gateway instance, used in logs and metrics.
auth_token_file	Path to the one-line enrollment token file.
carrier	websocket (default) or direct. Both run the identical protocol inside the same TLS connection; websocket adds HTTP Upgrade framing for egress paths that do not pass raw TLS.
ca_file	PEM CA bundle to verify the Devin edge certificate, only needed behind a corporate TLS-inspection proxy that re-signs certificates.
egress_proxy	Your egress HTTP CONNECT proxy (addr, optional auth), if outbound traffic must go through one.
connection_pool	size (1-16 tunnels, reloadable) and max_streams_per_connection (2-2048).

Additional checklist items for this mode:

• Allow egress from the Gateway to <customer>.gateway.devinenterprise.com:443 and to your allowlisted internal services. No inbound rules are needed.
• Store the enrollment token in your secret manager and mount it as a file. Never bake it into images, config under version control, or logs; the Gateway never logs it.
• Optionally provide Cognition your egress CIDR ranges to restrict the public endpoint at the IP level (defense in depth; the enrollment token remains the authentication gate).

The Gateway serves the allowlist proxy on a local HTTP CONNECT listener, and Devin reaches that listener over PrivateLink:

1. You deploy the Gateway in a private subnet in your AWS VPC with a listen address.
2. You put a Network Load Balancer in front of it targeting the listener port, and create a VPC Endpoint Service from that NLB.
3. You add Cognition’s AWS account as an allowed principal and send Cognition the endpoint service name.
4. Cognition creates an Interface VPC Endpoint in your dedicated tenant VPC and sends you its DNS name. That sends a connection request to your endpoint service, which you approve (or have auto-accepted, if you enabled that on the service).
5. On the “Devin Connect” settings page, you add a gateway with the “Direct” connection, enter the interface endpoint’s DNS name and the listener port, and add the destinations it should serve. Put the same destinations in the Gateway’s routes.

Because the endpoint service is only consumable by Cognition’s account and the NLB is internal to your VPC, there is no public listener. Access is authorized by the AWS principal on the endpoint service and by the Gateway’s own default-deny allowlist.The Gateway configuration sets listen to the port the NLB targets:

schema_version: 1
admin_listen: 0.0.0.0:9090

# The local HTTP CONNECT listener the NLB targets.
listen: 0.0.0.0:8443

routes:
  - name: devin
    rules:
      - hostname: "git.corp.example"
      - hostname: "api.corp.example"
    ports: [443]

What to provide Cognition:

• The VPC Endpoint Service name, for example com.amazonaws.vpce.us-west-2.vpce-svc-0abc123.
• The listener port the NLB exposes.
• Confirmation that Cognition’s AWS account is an allowed principal.
• Whether the endpoint service supports the region your Devin tenant runs in, if it differs from the Gateway’s region.

Additional checklist items for this mode:

• Run the NLB targets in multiple Availability Zones.
• If your services are in another region than your Devin tenant, enable cross-region support on the endpoint service. The steps are the same as in Dedicated Deployment Private Networking.

​

Configuration reference

schema_version: 1

# Admin listener (/healthz, /readyz, /metrics).
admin_listen: 127.0.0.1:9090

# Data-plane listener. PrivateLink (direct) mode only: required without a
# `tunnel` stanza, rejected with one.
# listen: 0.0.0.0:8443

# Customer DNS for resolving route targets (system resolver if omitted).
dns:
  nameservers: ["10.0.0.2:53"]
  timeout: 5s

# Default-deny allowlist. Rules accept hostnames and ipv4/ipv6 CIDRs.
# Omitted ports means any port.
routes:
  - name: scm
    rules:
      - hostname: "git.corp.example"
      - hostname: "artifacts.corp.example"
    ports: [443]
  - name: internal-api
    rules:
      - hostname: "api.corp.example"
    ports: [443]
  - name: build-hosts
    rules:
      - ipv4: "10.20.0.0/16"
    ports: [22]

# Outbound tunnel to the Devin-side edge. Omit in PrivateLink mode.
tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  auth_token_file: /etc/devin-gateway/tunnel-token

​

Routes (allowlist)

​

Listeners

​

DNS

​

Running the Gateway

gateway serve --config /etc/devin-gateway/config.yaml
gateway validate-config --config config.yaml   # strict config validation
gateway doctor --config config.yaml            # JSON diagnostic summary

• /healthz for process liveness.
• /readyz for readiness.
• /metrics for Prometheus metrics.

• Run the Gateway in a private subnet.
• Wire /healthz and /readyz into your orchestrator’s health checks.
• Keep each gateway’s destinations in Devin settings and the routes in its Gateway config in sync; a destination allowed on only one side is not reachable.

​

Logging and SIEM integration

• conn_open and conn_close, with destination host and port, matched route name, client address, bytes transferred in each direction, and duration.
• deny, with the destination and reason (for example, no matching allowlist route).