> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Devin Connect
> Devin Connect le da a Devin acceso privado a sistemas internos: despliega un gateway como proxy de políticas, al que se accede mediante un túnel solo saliente o AWS PrivateLink.
Devin Connect se encuentra actualmente en **acceso anticipado**. Las funcionalidades y la configuración pueden cambiar. Ponte en contacto con tu equipo de cuentas de Cognition si te interesa el acceso anticipado.
Devin Connect da a las sesiones de Devin acceso a sistemas internos (control de código fuente, registries de artefactos, APIs internas) sin necesidad de crear una ruta de red para cada recurso. Despliegas un gateway ligero dentro de tu propia red y Devin llega a él a través de una conexión privada.
**Versión actual del gateway: v0.0.2**
Qué hace Devin Connect
Devin Connect tiene dos partes, y cada una se configura de forma independiente.
**Un proxy de políticas dentro de tu red.** El Gateway es un proxy HTTP CONNECT con una allowlist de denegación predeterminada. Acepta una solicitud de conexión para `host:port`, la compara con tus routes, resuelve el nombre con tu propio DNS, establece la conexión con el destino y retransmite bytes opacos. Ni el Gateway ni la infraestructura de Devin terminan ni inspeccionan el TLS entre la VM de Devin y tu servicio, y cada conexión queda registrada en el audit log.
**Una ruta privada desde Devin hasta ese proxy.** Devin tiene que llegar al proxy sin que ninguna de las partes exponga nada a la internet pública. Hay dos formas de lograrlo, y el proxy se comporta de forma idéntica en ambas:
* **Túnel inverso**: el Gateway establece una conexión de salida hacia un endpoint del lado de Devin sobre TLS y Devin envía las solicitudes de conexión de vuelta por ese túnel. No se abre nada de entrada hacia tu red ni se necesita ninguna integración con el proveedor de nube.
* **AWS PrivateLink**: colocas el Gateway detrás de un Network Load Balancer y un VPC Endpoint Service, y Cognition lo consume con un Interface VPC Endpoint en la VPC de tu dedicated tenant. El tráfico permanece en la red troncal de AWS y Devin se conecta directamente al Gateway mediante IP privadas.
Elige una en las pestañas de [Modos de conectividad](#connectivity-modes) más abajo; todo lo demás en esta página se aplica a ambas.
Propiedades que se cumplen en ambos casos:
* **VPC single-tenant dedicada.** Tu despliegue de Devin se ejecuta en su propia VPC (consulta el [modelo de Despliegue Dedicado para el Cliente](/es/enterprise/deployment/overview#customer-dedicated-deployment-architecture)). Las VM de Devin envían el tráfico de tus destinos enrutados hacia el Gateway mediante el control de salida configurado por Cognition.
* **Denegación predeterminada, aplicada dos veces.** Las routes se aplican en el Gateway y en el lado de Devin, de modo que un cambio de configuración en un solo lado no puede ampliar el acceso. Enrutar un destino nunca amplía los permisos de una sesión: el [security profile](/es/product-guides/security-profiles) de la sesión igualmente tiene que permitirlo.
* **El TLS de tu aplicación es de extremo a extremo.** El Gateway reenvía flujos de bytes opacos.
* **El DNS permanece dentro de tu red.** Los destinos de las routes se resuelven con tus resolvers (de forma predeterminada, el resolver del sistema del host del Gateway, o los servidores de nombres que configures).
* **Un solo despliegue cubre todos los destinos enrutados.** Basta con agregar nombres de host y rangos IPv4 en los Settings de Devin en lugar de montar una infraestructura específica para cada servicio.
Elegir un modo de conectividad
| | Túnel inverso | AWS PrivateLink |
| - | - | - |
| Exposición entrante | Ninguna; el Gateway inicia la conexión hacia fuera | Ninguna en internet; el endpoint service solo es accesible desde la cuenta de Cognition |
| Requisitos de nube | Cualquier red con salida a `:443` | El Gateway debe ejecutarse en AWS, con un NLB y un VPC Endpoint Service |
| Autenticación de la conexión | Token de inscripción emitido por Devin | Principal de la cuenta de AWS en el endpoint service |
| Ruta del tráfico | Internet pública (TLS) o tu attachment de VPN/Transit Gateway | Red troncal de AWS |
| Entre regiones | No aplica | Compatible si lo habilitas en el endpoint service |
En ambos modos, la configuración se realiza en la web app de Devin, en la página "Devin Connect" de Settings de Enterprise, disponible para los usuarios con el rol de admin correspondiente. Una cuenta puede tener varios gateways, cada uno de los cuales enruta su propio grupo de destinos: como máximo un gateway de túnel inverso y cualquier cantidad de gateways de PrivateLink.
1. Elige "Add gateway", asígnale un nombre y selecciona un tipo de conexión: "Tunnel" para el túnel inverso o "Direct" para AWS PrivateLink. Si eliges "Direct", introduce también el nombre DNS y el puerto del Interface Endpoint (consulta la pestaña [AWS PrivateLink](#connectivity-modes)).
2. En la card del gateway, elige "Add destination" para cada destino al que Devin deba acceder a través de él: un nombre de host exacto, o una dirección IPv4 o un CIDR como `10.20.0.0/16`. No se admiten comodines. Cada destino solo puede pertenecer a un gateway.
3. En los gateways de túnel, elige "Generate token" para registrarlo. El token de inscripción se muestra una sola vez, Devin nunca lo almacena y puedes rotarlo o revocarlo en cualquier momento con "Regenerate token". Los gateways directos no tienen ningún túnel que autenticar, por lo que este paso no se aplica.
4. En los gateways de túnel, copia el fragmento de despliegue correspondiente a tu plataforma (Docker, Kubernetes, AWS ECS, Terraform en ECS o EC2, o un host Linux). El fragmento incluye un `config.yaml` listo para ejecutar, generado a partir de los destinos del gateway, así que vuelve a copiarlo cada vez que los modifiques.
La card de cada gateway de túnel también indica si está conectado en ese momento y cuándo se detectó por última vez.
Destinos de nombre de host e IPv4
* Los **nombres de host** se comparan con el nombre al que se conecta la sesión, que se obtiene del SNI de TLS o del encabezado HTTP `Host`. Por eso, solo routean tráfico TLS y HTTP sin cifrar. El Gateway resuelve el nombre con tu DNS.
* Las **direcciones IPv4 y los CIDR** se comparan con la IP de destino de la conexión, por lo que routean cualquier protocolo TCP, incluidas las conexiones SSH y a bases de datos. Devin no resuelve tus nombres internos para estas routes: las sesiones se conectan por dirección IP, o bien tú proporcionas la resolución de nombres en el entorno; por ejemplo, mediante entradas en `/etc/hosts` configuradas en tu [blueprint](/es/onboard-devin/environment/blueprints).
En el `config.yaml` del propio Gateway, permite los destinos IPv4 con reglas `ipv4`; el fragmento generado ya las incluye.
Modos de conectividad
El Gateway establece N túneles TLS salientes hacia tu tenant endpoint, `.gateway.devinenterprise.com:443`. Nunca abres un puerto entrante. Un túnel registrado solo transporta los flujos que el lado de Devin abre hacia tu Gateway; no constituye una vía de entrada hacia Devin.
El registro funciona así:
1. Devin te emite un enrollment token para el gateway del túnel desde la settings page "Devin Connect".
2. Instalas el token en el host del Gateway, en la ruta a la que apunta `tunnel.auth_token_file`.
3. El Gateway se conecta a `.gateway.devinenterprise.com:443`, verifica el certificado de servidor del borde de Devin y presenta el token.
4. El borde valida el token (comparación en tiempo constante contra un resumen almacenado; el token en bruto nunca se almacena del lado de Devin) y registra el túnel. A partir de ese momento, las conexiones que Devin inicia hacia los destinos del gateway circulan por él.
El túnel se configura con una sección `tunnel` y sin dirección `listen`, de modo que el host del Gateway no expone ningún puerto de proxy:
```yaml theme={null}
tunnel:
endpoint: acme.gateway.devinenterprise.com:443
gateway_id: gw-1
# Enrollment token, en una sola línea; se vuelve a leer en cada intento de
# conexión, por lo que puede rotarse sin reiniciar.
auth_token_file: /etc/devin-gateway/tunnel-token
# carrier: websocket # predeterminado; use `direct` para desactivar el framing WebSocket.
# ca_file: corp-ca.pem # solo si un proxy corporativo de inspección TLS vuelve a firmar
# # la conexión con el edge.
# egress_proxy: # proxy HTTP CONNECT de salida del cliente, si es necesario.
# addr: proxy.corp.example:3128
```
| Campo | Descripción |
| - | - |
| `endpoint` | Tu tenant endpoint, `.gateway.devinenterprise.com:443`. |
| `gateway_id` | Identificador de esta instancia de Gateway, usado en los logs y las metrics. |
| `auth_token_file` | Ruta al archivo de una sola línea con el enrollment token. |
| `carrier` | `websocket` (predeterminado) o `direct`. Ambos ejecutan el mismo protocolo dentro de la misma conexión TLS; `websocket` añade encuadre HTTP Upgrade para rutas de salida que no admiten TLS sin procesar. |
| `ca_file` | Paquete PEM de CA para verificar el certificado del edge de Devin; solo se necesita detrás de un corporate TLS-inspection proxy que vuelve a firmar los certificados. |
| `egress_proxy` | Tu proxy HTTP CONNECT de salida (`addr`, `auth` opcional), si el tráfico saliente debe pasar por uno. |
| `connection_pool` | `size` (1-16 túneles, recargable) y `max_streams_per_connection` (2-2048). |
Elementos adicionales de la lista de verificación para este modo:
* Permite la salida desde el Gateway hacia `.gateway.devinenterprise.com:443` y hacia tus servicios internos incluidos en la allowlist. No se necesitan reglas de entrada.
* Guarda el enrollment token en tu gestor de secrets y móntalo como archivo. Nunca lo incluyas en images, en configuración bajo control de versiones ni en logs; el Gateway nunca lo registra.
* Opcionalmente, proporciona a Cognition tus CIDR ranges de salida para restringir el endpoint público a nivel de IP (defensa en profundidad; el enrollment token sigue siendo la barrera de autenticación).
El Gateway expone el proxy de allowlist en un listener local HTTP CONNECT, y Devin accede a ese listener a través de PrivateLink:
1. Despliegas el Gateway en una subred privada de tu VPC de AWS con una dirección `listen`.
2. Colocas un Network Load Balancer delante de él apuntando al puerto del listener y creas un VPC Endpoint Service a partir de ese NLB.
3. Agregas la AWS account de Cognition como principal permitido y envías a Cognition el nombre del endpoint service.
4. Cognition crea un Interface VPC Endpoint en la VPC de tu tenant dedicado y te envía su nombre DNS. Esto envía una solicitud de conexión a tu endpoint service, que tú apruebas (o se acepta automáticamente, si habilitaste esa opción en el servicio).
5. En la settings page de "Devin Connect", agregas un gateway con la conexión "Direct", introduces el nombre DNS del interface endpoint y el puerto del listener, y agregas los destinos que debe atender. Incluye los mismos destinos en las `routes` del Gateway.
Como el endpoint service solo puede consumirlo la cuenta de Cognition y el NLB es interno a tu VPC, no existe ningún listener público. El acceso se autoriza mediante el principal de AWS en el endpoint service y mediante la propia allowlist de denegación predeterminada del Gateway.
La configuración del Gateway establece `listen` en el puerto al que apunta el NLB:
```yaml theme={null}
schema_version: 1
admin_listen: 0.0.0.0:9090
# El listener HTTP CONNECT local al que apunta el NLB.
listen: 0.0.0.0:8443
routes:
- name: devin
rules:
- hostname: "git.corp.example"
- hostname: "api.corp.example"
ports: [443]
```
Qué debes proporcionar a Cognition:
* El nombre del VPC Endpoint Service, por ejemplo `com.amazonaws.vpce.us-west-2.vpce-svc-0abc123`.
* El puerto de escucha que expone el NLB.
* La confirmación de que la cuenta de AWS de Cognition es un principal permitido.
* Si el endpoint service admite la región en la que se ejecuta tu tenant de Devin, en caso de que sea distinta de la región del Gateway.
Elementos adicionales de la lista de verificación para este modo:
* Ejecuta los destinos del NLB en múltiples zonas de disponibilidad.
* Si tus servicios están en una región distinta a la de tu tenant de Devin, habilita la compatibilidad entre regiones en el endpoint service. Los pasos son los mismos que en [Redes privadas del despliegue dedicado](/es/enterprise/deployment/dedicated_saas_private_networking#cross-region-privatelink-if-your-services-are-in-a-different-region).
Referencia de configuración
El Gateway se configura con un único archivo YAML, validado de forma estricta y con comportamiento fail-closed: una configuración que no supere la validación se rechaza por completo y la configuración anterior permanece activa. El archivo se sondea cada 5 segundos y se recarga en caliente.
```yaml theme={null}
schema_version: 1
# Listener de Admin (/healthz, /readyz, /metrics).
admin_listen: 127.0.0.1:9090
# Listener del plano de datos. Solo en modo PrivateLink (direct): obligatorio si no
# hay una sección `tunnel`, y se rechaza si la hay.
# listen: 0.0.0.0:8443
# DNS del cliente para resolver los destinos de las routes (resolver del sistema si se omite).
dns:
nameservers: ["10.0.0.2:53"]
timeout: 5s
# Allowlist con denegación predeterminada. Las Rules aceptan nombres de host y CIDR ipv4/ipv6.
# Si se omiten los puertos, se permite cualquier puerto.
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]
# Túnel saliente hacia el edge del lado de Devin. Omítelo en modo PrivateLink.
tunnel:
endpoint: acme.gateway.devinenterprise.com:443
gateway_id: gw-1
auth_token_file: /etc/devin-gateway/tunnel-token
```
Routes (allowlist)
Todo lo que no coincida con una ruta se deniega; una lista de rutas vacía deniega todo. Las rutas se evalúan en orden y gana la primera coincidencia.
| Campo | Descripción |
| - | - |
| `name` | Nombre único de la ruta; aparece en los audit logs de conexión. |
| `rules` | Reglas de coincidencia del destino; la ruta coincide si coincide cualquiera de las reglas. La coincidencia de `hostname` no distingue mayúsculas de minúsculas. Las reglas CIDR `ipv4`/`ipv6` solo coinciden con conexiones a IP literal. |
| `ports` | Puertos de destino permitidos. Si se omite, se admite cualquier puerto. |
| `upstream_proxy` | Proxy HTTP CONNECT ascendente opcional al que encadenar esta ruta (`addr`, `auth` opcional). |
Los nombres de host se comparan tal como se solicitan, antes de la resolución DNS, de modo que la policy se aplica al nombre y no a la IP a la que este acabe resolviéndose.
Listeners
| Campo | Descripción |
| - | - |
| `admin_listen` | Listener de Admin para `/healthz`, `/readyz` y `/metrics`. |
| `listen` | Listener HTTP CONNECT del plano de datos. Configúralo en modo PrivateLink; omítelo en modo túnel, donde las solicitudes de conexión llegan únicamente por el túnel autenticado. |
| `dial_timeout` | Timeout para establecer conexión con los destinos upstream (10 s de forma predeterminada). |
DNS
| Campo | Descripción |
| - | - |
| `nameservers` | Servidores de nombres DNS (`ip:port`) que se usan para resolver los destinos de las rutas. Si se omite, se utiliza el resolver del sistema del host del Gateway, que es el caso más habitual, ya que el Gateway se ejecuta dentro de tu red. |
| `timeout` | Tiempo de espera por consulta (5 s de forma predeterminada). |
Las rutas por hostname se rechazan si tu DNS las resuelve a direcciones de loopback, link-local o no especificadas, de modo que un nombre incluido en la allowlist no puede redirigirse hacia el propio host del Gateway ni hacia un endpoint de metadatos.
Ejecutar el gateway
El gateway se distribuye como una imagen de contenedor que contiene un único binary estático (la imagen se compila `FROM scratch` y se ejecuta con un usuario sin privilegios de root). Monta la configuración en `/etc/devin-gateway/config.yaml` y, en modo túnel, el archivo de token en la ruta a la que apunte `tunnel.auth_token_file`.
```bash theme={null}
gateway serve --config /etc/devin-gateway/config.yaml
gateway validate-config --config config.yaml # validación estricta de la config
gateway doctor --config config.yaml # resumen de diagnóstico en JSON
```
Endpoints operativos en `admin_listen`:
* `/healthz` para la actividad del proceso.
* `/readyz` para la disponibilidad.
* `/metrics` para las métricas de Prometheus.
Lista de verificación para el despliegue en ambos modos:
* Ejecuta el Gateway en una subred privada.
* Integra `/healthz` y `/readyz` en los health checks de tu orquestador.
* Mantén sincronizados los destinos de cada gateway en los Settings de Devin y las routes en su config del Gateway; un destino permitido en solo uno de los lados no es accesible.
Registro e integración con SIEM
El Gateway escribe sus registros en stdout. Cuando stdout no es una terminal (lo normal en un contenedor), los registros se emiten como líneas JSON, listas para su procesamiento automatizado. Para llevarlos a tu SIEM, usa el proceso de registro estándar de tu plataforma: el controlador de registros del contenedor o el agente (CloudWatch Logs, Fluent Bit, Vector, el agente de Datadog, etc.) recopila stdout y lo reenvía igual que los registros de cualquier otra carga de trabajo. El Gateway no necesita ninguna configuración específica para SIEM.
Los eventos de auditoría de conexión incluyen:
* `conn_open` y `conn_close`, con host y puerto de destino, nombre de la ruta coincidente, dirección del cliente, bytes transferidos en cada dirección y duración.
* `deny`, con el destino y el motivo (por ejemplo, ninguna ruta de la allowlist coincidente).
El token de inscripción nunca se registra, ni tampoco el contenido del payload.
Para conectividad privada por servicio sin un Gateway, consulta [Redes privadas en despliegue dedicado](/es/enterprise/deployment/dedicated_saas_private_networking). Para una visión general de los modelos de despliegue, consulta la [Visión general de despliegue](/es/enterprise/deployment/overview).
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.