Vai al contenuto principale
Outposts ti consente di eseguire sessioni Devin all’interno dell’infrastruttura che gestisci — le tue VM, i tuoi container, i tuoi cluster Kubernetes o persino un Mac Mini sulla tua scrivania. Il loop dell’agente Devin (inferenza e pianificazione) continua a essere eseguito nel cloud di Devin, mentre l’esecuzione dei comandi, le modifiche ai file e l’accesso ai repository avvengono interamente su macchine che gestisci tu. Usa Outposts quando hai bisogno di:
  • Eseguire sessioni all’interno della tua rete, accanto a servizi interni, registries e secrets
  • Profili hardware personalizzati (ad es. GPU, macchine con molta memoria, immagini del sistema operativo specifiche)
  • Un’infrastruttura esistente di dev box, VM o Kubernetes per ospitare i carichi di lavoro di Devin
  • Controlli Enterprise sull’accesso alla rete, sugli output di build e sul monitoraggio
Il loop dell'agente Devin e la coda dell'outpost vengono eseguiti in Devin Cloud; le tue macchine — un box GPU nel tuo laboratorio, una VM nella tua VPC o un Mac mini sulla tua scrivania — gestiscono le sessioni tramite una connessione solo in uscita

​
Come funziona

Un outpost è una coda nominativa di sessioni Devin da eseguire sulle tue macchine. Una volta registrato un outpost (ad es. gpu-h200 o dev-boxes), compare come opzione della macchina in Devin Cloud insieme a Ubuntu, Windows, ecc. — le sessioni cloud avviate su un outpost restano in coda finché una delle tue macchine non le prende in carico. Ogni macchina che gestisce sessioni da un outpost è un worker. Per trasformare una macchina in un worker, installa Devin CLI ed esegui:
Il worker apre una connessione in uscita al cloud di Devin e monitora la coda dell’outpost. Quando una sessione è in attesa, il worker la rivendica ed esegue localmente le relative tool call: ogni comando, modifica di file e operazione sul repository viene eseguito sulla tua macchina. Quando la sessione termina, il worker torna a monitorare la coda in attesa della sessione successiva. Per scalare è sufficiente eseguire il worker su più macchine: N worker gestiscono N sessioni simultanee e tutte le ulteriori sessioni restano in coda finché un worker non diventa disponibile. Ai worker serve solo accesso HTTPS in uscita. Non sono necessarie porte in entrata, IP pubblici o tunnel VPN.

​
Orchestrazione

Le macchine worker persistenti sono la configurazione più semplice, ma con l’API di Outposts puoi anche scrivere un orchestratore: un software che monitora la coda dell’outpost e, per ogni sessione in attesa, avvia una nuova VM o un nuovo container, avvia al suo interno il worker e smantella la macchina al termine della sessione. Consulta Orchestrazione per scoprire come fare, distribuisci devin-outpost-k8s — il nostro operatore open source che esegue questo ciclo su qualsiasi cluster Kubernetes — oppure eseguilo su una piattaforma partner che lo implementa già per te (vedi Integrazioni).

​
Dipendenze della macchina

Le sessioni vengono eseguite direttamente sulle tue macchine, quindi il worker dipende dagli strumenti che vi installi.

​
Per iniziare

Avvio rapido

Crea un outpost e gestisci le sessioni da una singola macchina con devin worker start — nessun orchestratore necessario.

Orchestrazione

Passa a una flotta: effettua il polling della coda, rivendica le sessioni, esegui il provisioning delle macchine e avvia automaticamente i worker.

Riferimento

La panoramica completa: comandi e flag della CLI, endpoint dell’API della flotta, distribuzione del file binario e contratto di spawn.

​
Integrazioni

Le piattaforme partner implementano per te il ciclo di orchestrazione: le sessioni vengono eseguite sulla loro infrastruttura, senza dover eseguire alcun worker né creare alcun orchestrator. Ogni partner documenta la propria configurazione:

​
Limitazioni

  • Devin Outposts attualmente funziona solo con hosting multi-tenant; al momento non è disponibile con le distribuzioni Dedicated Tenant.
  • Outposts sposta sul cliente una parte significativa delle responsabilità infrastrutturali e operative. I team devono proteggere e gestire su larga scala le proprie VM di sviluppo remoto, inclusi provisioning, isolamento, controlli di accesso, gestione della capacità, monitoraggio e ripristino. Per i clienti attenti alla sicurezza, consigliamo Dedicated Tenant (Dedicated SaaS), che fornisce un ambiente isolato dedicato al cliente, con sicurezza e orchestrazione gestite da Cognition.