> ## 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 offre a Devin accesso privato ai sistemi interni: distribuisci un gateway come proxy di policy, raggiungibile tramite un tunnel outbound-only o AWS PrivateLink.
Devin Connect è attualmente in **early access**. Le funzionalità e la configurazione possono cambiare. Contatta il tuo account team Cognition se sei interessato all'early access.
Devin Connect consente alle sessioni Devin di accedere ai sistemi interni (controllo del codice sorgente, registry di artefatti, API interne) senza dover creare un percorso di rete per ogni singola risorsa. Distribuisci un gateway leggero all'interno della tua rete e Devin lo raggiunge tramite una connessione privata.
**Release attuale del gateway: v0.0.2**
Cosa fa Devin Connect
Devin Connect è composto da due parti, che si configurano in modo indipendente.
**Un proxy di policy all'interno della tua rete.** Il Gateway è un proxy HTTP CONNECT con una allowlist default-deny. Accetta una richiesta di connessione per `host:port`, la verifica rispetto ai tuoi percorsi, risolve il nome con il tuo DNS, contatta la destinazione e inoltra byte opachi. Né il Gateway né l'infrastruttura Devin terminano o ispezionano il TLS tra la VM di Devin e il tuo servizio, e ogni connessione viene registrata nel log di audit.
**Un percorso privato da Devin a quel proxy.** Devin deve raggiungere il proxy senza che nessuna delle due parti esponga alcunché su internet pubblico. Ci sono due modi per farlo, e il proxy si comporta in modo identico in entrambi i casi:
* **Tunnel inverso**: il Gateway apre una connessione in uscita verso un endpoint sul lato Devin tramite TLS e Devin invia le richieste di connessione attraverso quel tunnel. Non viene aperto nulla in ingresso verso la tua rete e non è necessaria alcuna integrazione con il provider cloud.
* **AWS PrivateLink**: metti davanti al Gateway un Network Load Balancer e un VPC Endpoint Service, e Cognition lo utilizza tramite un Interface VPC Endpoint nella VPC del tuo dedicated tenant. Il traffico resta sulla backbone AWS e Devin contatta il Gateway direttamente tramite IP privati.
Scegline una nelle tab [Modalità di connettività](#connectivity-modes) qui sotto; tutto il resto di questa pagina vale per entrambe.
Proprietà valide in entrambi i casi:
* **VPC single-tenant dedicata.** La tua distribuzione di Devin viene eseguita in una VPC dedicata (vedi il [modello Customer Dedicated Deployment](/it/enterprise/deployment/overview#customer-dedicated-deployment-architecture)). Le VM di Devin inviano il traffico destinato alle tue destinazioni instradate verso il Gateway tramite il controllo dell'egress configurato da Cognition.
* **Default-deny, applicato due volte.** I percorsi vengono applicati sul Gateway e sul lato Devin, quindi una modifica alla sola configurazione su un lato non può ampliare l'accesso. Instradare una destinazione non amplia mai le autorizzazioni di una sessione: il [security profile](/it/product-guides/security-profiles) della sessione deve comunque consentirlo.
* **Il TLS della tua applicazione è end-to-end.** Il Gateway inoltra flussi di byte opachi.
* **Il DNS resta all'interno della tua rete.** Le destinazioni dei percorsi vengono risolte dai tuoi resolver (per default il resolver di sistema dell'host del Gateway, oppure i nameserver che configuri).
* **Una sola distribuzione copre tutte le destinazioni instradate.** Aggiungi hostname e intervalli IPv4 nei Settings di Devin invece di predisporre collegamenti dedicati per ogni servizio.
Scegliere una modalità di connettività
| | Tunnel inverso | AWS PrivateLink |
| - | - | - |
| Esposizione in entrata | Nessuna; è il Gateway a iniziare la connessione | Nessuna su internet; l'endpoint service è raggiungibile solo dall'account di Cognition |
| Requisiti cloud | Qualsiasi rete con traffico in uscita verso `:443` | Il Gateway deve essere eseguito in AWS, con un NLB e un VPC Endpoint Service |
| Autenticazione della connessione | Enrollment token emesso da Devin | Principal dell'AWS account sull'endpoint service |
| Percorso del traffico | Internet pubblica (TLS) oppure l'attachment della tua VPN/Transit Gateway | Backbone AWS |
| Cross-region | Non applicabile | Supportato se lo abiliti sull'endpoint service |
In entrambe le modalità, la configurazione si effettua nella web app di Devin, nella pagina "Devin Connect" delle impostazioni enterprise, accessibile agli utenti con il ruolo di amministratore appropriato. Un account può avere più gateway, ciascuno dei quali instrada il proprio gruppo di destinazioni: al massimo un gateway a tunnel inverso e un numero qualsiasi di gateway PrivateLink.
1. Scegli "Add gateway", assegnagli un nome e seleziona una connessione: "Tunnel" per il tunnel inverso oppure "Direct" per AWS PrivateLink. Per "Direct", inserisci anche il nome DNS e la porta dell'interface endpoint (vedi la scheda [AWS PrivateLink](#connectivity-modes)).
2. Nella card del gateway, scegli "Add destination" per ogni destinazione che Devin deve raggiungere tramite quel gateway: un hostname esatto, oppure un indirizzo IPv4 o un CIDR come `10.20.0.0/16`. I caratteri jolly non sono supportati. Una destinazione può appartenere a un solo gateway.
3. Per un gateway a tunnel, scegli "Generate token" per registrarlo. L'enrollment token viene mostrato una sola volta, non viene mai memorizzato da Devin e può essere ruotato o revocato in qualsiasi momento con "Regenerate token". I gateway diretti non hanno un tunnel da autenticare, quindi questo passaggio non è necessario.
4. Per un gateway a tunnel, copia lo snippet di distribuzione per la tua piattaforma (Docker, Kubernetes, AWS ECS, Terraform su ECS o EC2, oppure un host Linux). Lo snippet contiene un file `config.yaml` pronto per l'esecuzione, generato a partire dalle destinazioni del gateway: se le modifichi, copialo di nuovo.
La card di ogni gateway a tunnel indica inoltre se è attualmente connesso e quando è stato rilevato l'ultima volta.
Destinazioni hostname e IPv4
* Gli **hostname** vengono confrontati con il nome a cui si connette la sessione, ricavato dallo SNI TLS o dall'header HTTP `Host`. Per questo instradano solo traffico TLS e HTTP in chiaro. Il Gateway risolve il nome tramite il tuo DNS.
* Gli **indirizzi IPv4 e i CIDR** vengono confrontati con l'IP di destinazione della connessione, quindi instradano qualsiasi protocollo TCP, incluse le connessioni SSH e ai database. Per questi percorsi, Devin non risolve i tuoi nomi interni: le sessioni si connettono tramite indirizzo IP, oppure sei tu a fornire la risoluzione dei nomi nell'ambiente, ad esempio con voci in `/etc/hosts` configurate nel tuo [blueprint](/it/onboard-devin/environment/blueprints).
Nel `config.yaml` del Gateway, consenti le destinazioni IPv4 tramite regole `ipv4`; lo snippet generato le include già.
Modalità di connettività
Il Gateway apre N tunnel TLS in uscita verso il tuo tenant endpoint, `.gateway.devinenterprise.com:443`. Non devi mai aprire una porta in ingresso. Un tunnel registrato trasporta soltanto gli stream che il lato Devin apre verso il tuo Gateway; non costituisce un percorso in ingresso verso Devin.
L'enrollment funziona così:
1. Devin ti rilascia un enrollment token per il gateway del tunnel dalla settings page "Devin Connect".
2. Installi il token sull'host del Gateway nel percorso indicato da `tunnel.auth_token_file`.
3. Il Gateway contatta `.gateway.devinenterprise.com:443`, verifica il certificato server dell'edge di Devin e presenta il token.
4. L'edge convalida il token (confronto a tempo costante con un digest memorizzato; il token in chiaro non viene mai memorizzato sul lato Devin) e registra il tunnel. Le connessioni avviate dal lato Devin verso le destinazioni del gateway passano quindi attraverso di esso.
Il tunnel viene configurato con una sezione `tunnel` e senza indirizzo `listen`, in modo che l'host del Gateway non esponga alcuna porta proxy:
```yaml theme={null}
tunnel:
endpoint: acme.gateway.devinenterprise.com:443
gateway_id: gw-1
# Enrollment token, su una sola riga; viene riletto a ogni tentativo di
# connessione, così può essere ruotato senza riavviare.
auth_token_file: /etc/devin-gateway/tunnel-token
# carrier: websocket # default; usa `direct` per disattivare il framing WebSocket.
# ca_file: corp-ca.pem # solo se un proxy aziendale di ispezione TLS rifirma
# # la connessione verso l'edge.
# egress_proxy: # proxy HTTP CONNECT in uscita del cliente, se necessario.
# addr: proxy.corp.example:3128
```
| Campo | Descrizione |
| - | - |
| `endpoint` | Il tuo tenant endpoint, `.gateway.devinenterprise.com:443`. |
| `gateway_id` | Identificatore di questa istanza del Gateway, usato nei log e nelle metriche. |
| `auth_token_file` | Percorso del file contenente l'enrollment token su una sola riga. |
| `carrier` | `websocket` (default) o `direct`. Entrambi eseguono lo stesso identico protocollo all'interno della medesima connessione TLS; `websocket` aggiunge il framing HTTP Upgrade per i percorsi di egress che non lasciano passare il TLS raw. |
| `ca_file` | Bundle CA in formato PEM per verificare il certificato edge di Devin, necessario solo dietro un corporate TLS-inspection proxy che ri-firma i certificati. |
| `egress_proxy` | Il tuo proxy HTTP CONNECT di egress (`addr`, `auth` facoltativo), se il traffico in uscita deve necessariamente passare per un proxy. |
| `connection_pool` | `size` (1-16 tunnel, ricaricabile a caldo) e `max_streams_per_connection` (2-2048). |
Voci aggiuntive della checklist per questa modalità:
* Consenti l'egress dal Gateway verso `.gateway.devinenterprise.com:443` e verso i tuoi servizi interni in allowlist. Non è necessaria alcuna regola in ingresso.
* Conserva l'enrollment token nel tuo gestore di secret e montalo come file. Non includerlo mai nelle image, nella configurazione sotto controllo versione o nei log; il Gateway non lo registra mai.
* Facoltativamente, fornisci a Cognition i tuoi CIDR ranges di egress per limitare l'endpoint pubblico a livello di IP (difesa in profondità; l'enrollment token resta il punto di controllo dell'autenticazione).
Il Gateway espone il proxy con allowlist su un listener HTTP CONNECT locale e Devin raggiunge quel listener tramite PrivateLink:
1. Distribuisci il Gateway in una subnet privata della tua AWS VPC con un indirizzo `listen`.
2. Posizioni un Network Load Balancer davanti al Gateway, puntandolo alla porta del listener, e crei un VPC Endpoint Service a partire da quell'NLB.
3. Aggiungi l'AWS account di Cognition come allowed principal e invii a Cognition il nome dell'endpoint service.
4. Cognition crea un Interface VPC Endpoint nella VPC del tuo dedicated tenant e ti invia il relativo nome DNS. Questo invia una richiesta di connessione al tuo endpoint service, che approvi (oppure che viene accettata automaticamente, se hai abilitato tale opzione sul servizio).
5. Nella pagina Settings "Devin Connect", aggiungi un gateway con la connessione "Direct", inserisci il nome DNS dell'interface endpoint e la porta del listener, quindi aggiungi le destinazioni che il gateway deve gestire. Inserisci le stesse destinazioni nelle `routes` del Gateway.
Poiché l'endpoint service è utilizzabile soltanto dall'account di Cognition e l'NLB è interno alla tua VPC, non esiste alcun listener pubblico. L'accesso è autorizzato dal principal AWS sull'endpoint service e dall'allowlist default-deny del Gateway stesso.
La configurazione del Gateway imposta `listen` sulla porta a cui punta l'NLB:
```yaml theme={null}
schema_version: 1
admin_listen: 0.0.0.0:9090
# Il listener HTTP CONNECT locale a cui punta l'NLB.
listen: 0.0.0.0:8443
routes:
- name: devin
rules:
- hostname: "git.corp.example"
- hostname: "api.corp.example"
ports: [443]
```
Cosa fornire a Cognition:
* Il nome del VPC Endpoint Service, ad esempio `com.amazonaws.vpce.us-west-2.vpce-svc-0abc123`.
* La porta del listener esposta dall'NLB.
* La conferma che l'AWS account di Cognition sia un allowed principal.
* Se l'endpoint service supporta la regione in cui viene eseguito il tuo tenant Devin, nel caso differisca dalla regione del Gateway.
Voci aggiuntive della checklist per questa modalità:
* Esegui i target dell'NLB in più zone di disponibilità.
* Se i tuoi servizi si trovano in una regione diversa da quella del tuo tenant Devin, abilita il supporto cross-region sull'endpoint service. I passaggi sono gli stessi descritti in [Rete privata per la distribuzione dedicata](/it/enterprise/deployment/dedicated_saas_private_networking#cross-region-privatelink-if-your-services-are-in-a-different-region).
Riferimento della configurazione
Il Gateway si configura con un unico file YAML, sottoposto a convalida rigorosa e con comportamento fail-closed: una configurazione che non supera la convalida viene rifiutata per intero e resta attiva quella precedente. Il file viene controllato (polling) ogni 5 secondi e ricaricato a caldo.
```yaml theme={null}
schema_version: 1
# Listener di amministrazione (/healthz, /readyz, /metrics).
admin_listen: 127.0.0.1:9090
# Listener del piano dati. Solo in modalità PrivateLink (direct): obbligatorio
# in assenza di una sezione `tunnel`, rifiutato se presente.
# listen: 0.0.0.0:8443
# DNS del cliente per risolvere le destinazioni dei percorsi (se omesso, si usa il resolver di sistema).
dns:
nameservers: ["10.0.0.2:53"]
timeout: 5s
# Allowlist con deny predefinito. Le regole accettano hostname e CIDR ipv4/ipv6.
# Se le porte sono omesse, vale qualsiasi porta.
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]
# Tunnel in uscita verso l'edge lato Devin. Da omettere in modalità PrivateLink.
tunnel:
endpoint: acme.gateway.devinenterprise.com:443
gateway_id: gw-1
auth_token_file: /etc/devin-gateway/tunnel-token
```
Percorsi (allowlist)
Tutto ciò che non corrisponde a un percorso viene negato; un elenco di percorsi vuoto nega tutto. I percorsi vengono valutati in ordine e vince la prima corrispondenza.
| Campo | Descrizione |
| - | - |
| `name` | Nome univoco del percorso; compare nei log di audit delle connessioni. |
| `rules` | Regole di corrispondenza della destinazione; il percorso corrisponde se almeno una regola corrisponde. La corrispondenza di `hostname` non distingue tra maiuscole e minuscole. Le regole CIDR `ipv4`/`ipv6` corrispondono solo alle connessioni verso IP letterali. |
| `ports` | Porte di destinazione consentite. Se omesso, indica qualsiasi porta. |
| `upstream_proxy` | Proxy HTTP CONNECT upstream opzionale da concatenare per questo percorso (`addr`, `auth` opzionale). |
Gli hostname vengono confrontati così come richiesti, prima della risoluzione DNS: in questo modo la policy si applica al nome e non all'IP a cui viene eventualmente risolto.
Listeners
| Campo | Descrizione |
| - | - |
| `admin_listen` | Listener di amministrazione per `/healthz`, `/readyz` e `/metrics`. |
| `listen` | Listener HTTP CONNECT del piano dati. Impostalo in modalità PrivateLink; omettilo in modalità tunnel, dove le richieste di connessione arrivano solo attraverso il tunnel autenticato. |
| `dial_timeout` | Timeout per la connessione ai target upstream (default 10s). |
DNS
| Campo | Descrizione |
| - | - |
| `nameservers` | Server DNS (`ip:port`) utilizzati per risolvere le destinazioni dei percorsi. Se omesso, viene usato il resolver di sistema dell'host Gateway: è il caso più comune, poiché il Gateway viene eseguito all'interno della tua rete. |
| `timeout` | Timeout per singola query (default 5s). |
I percorsi basati su hostname vengono rifiutati se il tuo DNS le risolve in indirizzi di loopback, link-local o non specificati: in questo modo un nome inserito in allowlist non può essere indirizzato verso l'host Gateway stesso o verso un endpoint di metadati.
Esecuzione del Gateway
Il Gateway viene distribuito come immagine container che contiene un unico binario statico (l'immagine è costruita `FROM scratch` e viene eseguita come utente non root). Monta la configurazione in `/etc/devin-gateway/config.yaml` e, in modalità tunnel, il file del token nel percorso indicato da `tunnel.auth_token_file`.
```bash theme={null}
gateway serve --config /etc/devin-gateway/config.yaml
gateway validate-config --config config.yaml # convalida rigorosa della configurazione
gateway doctor --config config.yaml # riepilogo diagnostico in JSON
```
Endpoint operativi su `admin_listen`:
* `/healthz` per la liveness del processo.
* `/readyz` per la readiness.
* `/metrics` per le metriche Prometheus.
Checklist di distribuzione per entrambe le modalità:
* Esegui il Gateway in una subnet privata.
* Collega `/healthz` e `/readyz` agli health check del tuo orchestrator.
* Mantieni sincronizzate le destinazioni di ciascun gateway nelle impostazioni di Devin e i percorsi nella relativa configurazione del Gateway; una destinazione consentita su un solo lato non è raggiungibile.
Logging e integrazione SIEM
Il Gateway scrive i log su stdout. Quando stdout non è un terminale (il caso normale in un container), i log vengono emessi come righe JSON, pronte per l'elaborazione automatica. Per convogliarli nel tuo SIEM, usa la pipeline di log standard della tua piattaforma: il log driver del container o l'agent (CloudWatch Logs, Fluent Bit, Vector, agent Datadog e così via) raccoglie stdout e lo inoltra come i log di qualsiasi altro carico di lavoro. Il Gateway non richiede alcuna configurazione specifica per il SIEM.
Gli eventi di audit delle connessioni includono:
* `conn_open` e `conn_close`, con host e porta di destinazione, nome della route corrispondente, indirizzo del client, byte trasferiti in ciascuna direzione e durata.
* `deny`, con destinazione e motivo (ad esempio, nessuna route dell'allowlist corrispondente).
Il token di enrollment non viene mai registrato nei log, così come i contenuti del payload.
Per la connettività privata per singolo servizio senza un Gateway, consulta [Rete privata per la distribuzione dedicata](/it/enterprise/deployment/dedicated_saas_private_networking). Per una panoramica dei modelli di distribuzione, consulta la [Panoramica sulla distribuzione](/it/enterprise/deployment/overview).
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.