Come fare il self-hosting di OneCLI con Docker

Cosa si ottiene con il self-hosting di OneCLI

Con il self-hosting di OneCLI, ogni persona del team riceve il proprio agent, eseguito in un sandbox dedicato. Le chiavi API sono conservate in un gateway che gli agent non possono leggere. L'installazione è uno stack Docker Compose con PostgreSQL, raggiungibile all'indirizzo http://localhost:10254. È necessario un server adeguato. La configurazione predefinita documentata assegna 2 GiB di memoria a ogni sandbox dell'agent; non è quindi un carico adatto a un VPS da 1 GB.

Lo stack include sette componenti. Capire la funzione di ciascuno semplifica la lettura del resto della guida.

• Dashboard Web (Next.js), porta 10254. Creazione degli agent, chat, modifica della memoria e delle skill, connessioni e secret.
• API server, porta 10256. Il control plane: database, gestione delle conversazioni e code di lavoro.
• Rust gateway, porta 10255. Intercetta le richieste in uscita degli agent e inserisce le credenziali.
• Runner. Il README lo descrive come il componente che "avvia, sospende e rimuove i sandbox degli agent. Solo in uscita e senza mai accedere al database."
• Sandbox Supervisor. Il README lo descrive come il componente che viene eseguito "all'interno di ogni sandbox e comunica tramite un'interfaccia harness indipendente dal vendor, così da poter sostituire il runtime dell'agent."
• Channel adapter. Un daemon che connette un'app Slack, consentendo a un agent di rispondere nei canali e nei DM con il proprio nome.
• PostgreSQL. Il file compose fornito esegue postgres:18-alpine con un volume pgdata.

Il nome fa pensare a una CLI, ma il prodotto è un server

OneCLI è una piattaforma server. Il nome richiama uno strumento da riga di comando da installare su un laptop, ma questa descrizione non corrisponde al componente illustrato in questa guida. Esiste anche un client da riga di comando separato, nel repository onecli/onecli-cli, che instrada il traffico di un agente di coding locale attraverso un gateway. Quello che viene distribuito qui è un'applicazione web multiutente: un sistema di account in cui il primo account diventa proprietario dell'istanza, un database per conversazioni e secret e un runner che avvia i container.

Il modello per singolo utente è alla base dell'intero progetto. Il README lo descrive così: "Crei un agente per ogni persona, assegni a ciascun agente gli accessi necessari e l'agente opera in una sandbox, instradato attraverso un gateway che inserisce le credenziali e applica la tua policy." Ogni agente dispone di un filesystem e di una shell propri, di una pagina di conversazione dedicata, della memoria conservata dalla piattaforma e delle skill che puoi scrivere una sola volta. Le credenziali vengono gestite in modo opposto rispetto alla configurazione abituale. Invece di copiare una chiave API nell'ambiente di ogni persona, memorizzi la chiave una sola volta e la assegni agli agenti autorizzati a utilizzarla.

Requisiti del server prima di iniziare

• Docker, con il plugin Compose versione 2.19 o successiva. Il file Compose usa un servizio di migrazione eseguito una sola volta, da cui l'API dipende. Questa forma di dipendenza richiede la versione 2.19.
• Memoria, che rappresenta il vero vincolo. Leggere la sezione sul dimensionamento qui sotto prima di scegliere un piano.
• Porte loopback libere 10254, 10255, 10256 e 5432.

Non è necessario installare PostgreSQL manualmente: il file Compose lo esegue come servizio. Non sono necessari nemmeno Node.js o Rust. Servono soltanto per il percorso di compilazione dal codice sorgente, in cui mise blocca la toolchain.

Quante sandbox degli agenti possono essere eseguite sul VPS?

La documentazione del runner fornisce valori concreti, non stime approssimative. Ogni sandbox riceve 2048 MB di memoria (RUNNER_SANDBOX_MEMORY_MB), una CPU (RUNNER_SANDBOX_CPUS) e 512 processi (RUNNER_SANDBOX_PIDS). Il limite di concorrenza è 4 (RUNNER_MAX_SANDBOXES) e la documentazione raccomanda circa 10 GiB di memoria libera oltre allo stack di base per gestire tale limite.

[
  {
    "plan": "2 GB box",
    "ram_gb": 2,
    "sandbox_slots": 0
  },
  {
    "plan": "4 GB box",
    "ram_gb": 4,
    "sandbox_slots": 1
  },
  {
    "plan": "8 GB box",
    "ram_gb": 8,
    "sandbox_slots": 3
  },
  {
    "plan": "16 GB box",
    "ram_gb": 16,
    "sandbox_slots": 7
  },
  {
    "plan": "32 GB box",
    "ram_gb": 32,
    "sandbox_slots": 15
  }
]

Questi conteggi sono il risultato di un calcolo aritmetico, non di un benchmark: memoria totale, meno circa 2 GB per PostgreSQL e i quattro servizi a esecuzione prolungata, divisa per il limite di 2 GiB per sandbox. Su questa base, 2 GB box supporta 0 sandbox, quindi il piano più economico non può eseguire alcun agente ospitato. Un 16 GB box lascia spazio per 7, un valore nettamente superiore al limite predefinito di 4 e ai circa 10 GiB di memoria libera richiesti dalla documentazione del runner. Il 32 GB box consente di arrivare a 15.

Due fattori modificano questo calcolo. Una sandbox con un processo in background in esecuzione non viene mai messa in pausa, quindi mantiene il proprio slot in modo permanente. Per questo motivo, dimensiona RUNNER_MAX_SANDBOXES in base al carico sostenuto e non al minuto di maggiore attività. Inoltre, la memoria si esaurisce prima della CPU. Ogni sandbox ha un limite di una CPU, quindi quattro agenti sotto carico richiedono quattro core, mentre quattro agenti inattivi ma attivi continuano a occupare 8 GiB.

Installare OneCLI con Docker Compose

La documentazione upstream per l'hosting autonomo fornisce questa sequenza esatta. Scrive tre secret in docker/.env accanto al file Compose, quindi avvia lo stack.

git clone https://github.com/onecli/onecli.git && cd onecli/docker
cat > .env <<EOF
SECRET_ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64)
GATEWAY_INTERNAL_SECRET=$(head -c 32 /dev/urandom | base64)
BETTER_AUTH_SECRET=$(head -c 32 /dev/urandom | base64)
COMPOSE_PROFILES=runner
EOF
chmod 600 .env
docker compose up -d --wait

Leggere questo blocco prima di eseguirlo. Il marcatore heredoc non è racchiuso tra virgolette, quindi la shell esegue ogni head -c 32 /dev/urandom | base64 e scrive il risultato invece del testo letterale. SECRET_ENCRYPTION_KEY è la chiave AES-256-GCM per ogni secret nel database. GATEWAY_INTERNAL_SECRET autentica il gateway verso l'API. BETTER_AUTH_SECRET firma i cookie di sessione. COMPOSE_PROFILES=runner è la riga più importante, perché il servizio runner si trova dietro un profilo Compose: se la si omette, lo stack risulta attivo ma non viene mai avviato alcun ambiente sandbox per l'agente.

--wait mantiene la shell in attesa finché ogni servizio non segnala uno stato healthy, quindi un'uscita diversa da zero è il primo segnale di un problema. Controllare quindi quali servizi sono stati effettivamente avviati.

docker compose ps
docker compose logs migrations

Fissare la versione. ONECLI_VERSION imposta il tag per tutti i servizi contemporaneamente e l'immagine dell'agent sandbox lo segue, a meno che RUNNER_AGENT_IMAGE non punti altrove. Al 19 agosto 2026, la release corrente è v2.0.1, pubblicata il 18 agosto 2026. Aggiungerla allo stesso file e riavviare lo stack.

echo 'ONECLI_VERSION=v2.0.1' >> .env
docker compose up -d --wait

È disponibile anche un installer, curl -fsSL https://onecli.sh/install | sh, che scrive la configurazione in ~/.onecli/.env ed esegue le stesse operazioni. Il percorso Compose consente di leggere ogni file prima dell'avvio ed è quello da usare su un server che ospita già altri stack Compose. La compilazione dal codice sorgente è una terza opzione, documentata come pnpm install e poi pnpm run setup nel repository clonato. Questo percorso richiede mise, Rust per il gateway e comunque Docker; è destinato a chi intende modificare il codice.

Accesso alla dashboard dal laptop

Tutte le porte pubblicate nel file compose distribuito sono associate a ${ONECLI_BIND_HOST:-127.0.0.1}. Su un VPS, questo significa che la dashboard è in esecuzione, ma nessun sistema esterno può raggiungerla. Questa impostazione predefinita è corretta. Mantienila e usa un tunnel:

ssh -N -L 10254:127.0.0.1:10254 you@your-server

Ora apri http://localhost:10254 sul laptop. Il traffico passa attraverso la connessione SSH, quindi la dashboard non viene esposta su Internet senza cifratura e non è necessaria alcuna porta aggiuntiva nel firewall.

Impostando ONECLI_BIND_HOST=0.0.0.0, la dashboard viene pubblicata tramite HTTP non cifrato e PostgreSQL viene pubblicato insieme a essa. Se più persone devono usare la dashboard, configura un reverse proxy con TLS (transport layer security) davanti alla porta 10254 e lascia invariato l'host di bind. Esegui questa configurazione prima che l'istanza abbia un proprietario. La documentazione upstream spiega chiaramente il motivo: "Until you do, the instance has no owner, and on a reachable host whoever gets there first becomes one." Se il proxy espone già le altre applicazioni self-hosted, l'autenticazione inoltrata tramite un livello self-hosted di single sign-on colloca la dashboard dietro il login già utilizzato dal team. In questo modo, rimuovere una persona da un unico punto chiude anche questo accesso.

Crea il primo account, quindi assegna una chiave del modello

Apri la dashboard e crea subito l'account. Questo account è il proprietario dell'istanza e, dopo la sua creazione, per accedere è necessario un invito.

Salva quindi una chiave del modello prima di creare un agent. Un agent ospitato richiede una chiave del modello assegnata e l'ordine delle operazioni è importante: salva la chiave nella dashboard, assegnala all'agent e solo dopo avvia una conversazione. Se salti l'assegnazione, la sandbox non viene mai avviata. Il risultato è un agent che resta inattivo.

Assegna solo le autorizzazioni necessarie. Ogni agent riceve esclusivamente quelle assegnate e il gateway le applica a ogni richiesta. Un agent che legge un repository non può quindi accedere alla chiave del tuo provider di pagamento. Lo stesso elenco di assegnazioni consente di controllare la spesa. Un agent personale che può chiamare qualsiasi modello di tua proprietà genera una fattura personale. Prima di assegnarne dieci, conviene quindi leggere come limitare quanto un agent può spendere per le chiamate ai modelli.

Come il gateway impedisce agli agenti di gestire le chiavi

Il gateway è un proxy HTTPS scritto in Rust, in ascolto sulla porta 10255. Il client HTTP di un agente viene configurato per usarlo e l'agente trasporta una credenziale segnaposto invece di quella reale. Il gateway verifica la richiesta in uscita rispetto alle autorizzazioni assegnate all'agente, decritta il secret reale, lo inserisce nella richiesta e la inoltra. I secret sono archiviati in PostgreSQL e cifrati con AES-256-GCM (advanced encryption standard, 256-bit, Galois/counter mode); vengono decrittati solo al momento della richiesta. Ogni chiamata viene registrata con l'identità dell'agente e la relativa destinazione. Questo crea una traccia di audit che non è possibile ottenere quando le chiavi sono presenti nei profili shell di dieci persone.

Due aspetti determinano la modalità di distribuzione.

• L'intercettazione HTTPS è un attacco man-in-the-middle. Il gateway genera una certificate authority locale, l'agente si fida di essa e il gateway termina la connessione TLS dell'agente, quindi ne apre una nuova verso il servizio upstream. Per questo, se il client HTTP di un agente non considera attendibile la certificate authority del gateway, l'agente restituisce un errore di verifica del certificato, non un errore di autenticazione.
• L'agente si identifica con un header Proxy-Authorization. Su un singolo host, dove agenti e gateway condividono una rete Docker interna, questo header non attraversa reti che non controlli. Se configuri un agente esterno all'host per usare il gateway, la porta del proxy deve avere TLS dedicato, perché quell'header è un bearer token.

Il compromesso è chiaro: per progettazione, il gateway legge in chiaro ogni richiesta inviata dagli agenti. È il processo più sensibile della macchina. Tratta il suo host di conseguenza e limita il numero di persone che possono accedervi, usando utenti Linux con privilegi minimi.

Perché il runner non richiede porte in ingresso

Il runner usa esclusivamente connessioni in uscita. La relativa documentazione specifica che «non espone porte raggiungibili dall'esterno, quindi funzionano sia un laptop sia un homelab o una VPC dietro NAT, senza ingress, tunnel o gestione della terminazione TLS». NAT significa traduzione degli indirizzi di rete ed è la funzione svolta dal router di casa. Il runner avvia la connessione verso il piano di controllo e preleva da lì le attività; non c'è quindi nulla da inoltrare e nessuna porta da aprire.

Questo design è utile nella rete della sandbox. Il file compose definisce una seconda rete contrassegnata da internal: true, che in Docker significa che non esiste alcuna route verso l'esterno dell'host. Le sandbox si collegano a questa rete. Il gateway ha interfacce su entrambe le reti, quindi è l'unica via di uscita. La documentazione del runner lo afferma chiaramente: «una rete internal con il gateway collegato a entrambe le reti è ciò che rende l'egress consentito solo tramite il gateway un confine effettivo, non una semplice indicazione». Un agent che decidesse di inviare il codice sorgente a un indirizzo scelto autonomamente non avrebbe alcuna route per farlo.

Verificalo sul tuo host invece di fidarti del paragrafo precedente.

docker network ls
docker network inspect onecli-sandboxes | grep -i internal

Dovresti vedere "Internal": true. Se visualizzi false, il controllo dell'egress è disattivato e il gateway torna a essere soltanto un'indicazione. Usa il nome della rete della sandbox stampato da docker network ls, perché onecli-sandboxes è solo il valore predefinito.

Quanto è robusta la sandbox di OneCLI?

Leggete questa sezione con attenzione, perché il termine "sandboxed" ha un peso importante nella descrizione del progetto, mentre il meccanismo è documentato in un solo punto.

Il README afferma che ogni agente riceve "la propria sandbox isolata, con un filesystem e una shell", e indica il Sandbox Supervisor come il componente che "viene eseguito all'interno di ogni sandbox e comunica tramite un'interfaccia harness indipendente dal vendor, in modo che il runtime dell'agente possa essere sostituito". Nessuna delle due frasi specifica in cosa consista l'isolamento. La documentazione del runner lo indica: il backend predefinito è Docker (RUNNER_BACKEND=docker), e una sandbox è un container Docker con un limite di memoria, un limite di CPU e un limite al numero di processi, collegato alla rete interna. Il codice prevede un punto di estensione per altri backend, mentre la documentazione cita Kubernetes e le microVM come moduli che qualcuno dovrebbe implementare. Oggi, sul vostro sistema, una sandbox è un container.

È altrettanto importante ciò che la documentazione non dice. Non esiste un threat model. Non viene indicato se il demone Docker debba essere eseguito in modalità rootless, né si parla di rimappatura degli user namespace o di profili seccomp o AppArmor oltre a quelli predefiniti di Docker. Non viene inoltre dichiarato alcun confine a livello di kernel, come gVisor o una microVM. Adottate quindi l'interpretazione più restrittiva. I limiti sono limiti alle risorse. La rete interna è un vero controllo sull'egress. L'isolamento tra un agente e l'host è quello offerto da un container Docker standard, e un container condivide il kernel dell'host.

C'è un secondo aspetto da considerare. Il servizio runner monta /var/run/docker.sock, perché è così che crea le sandbox. L'accesso al socket Docker equivale all'accesso root sull'host, poiché chiunque possa chiamare quell'API può avviare un container con il filesystem dell'host montato al suo interno. Tutti i runner basati su Docker funzionano in questo modo. Di conseguenza, il processo runner è sensibile quanto il gateway.

Considerate il confine non verificato finché il progetto upstream non lo documenta esplicitamente. In pratica, questo significa adottare tre abitudini.

1. Eseguite OneCLI su un sistema che non svolga altre funzioni. Nessun servizio di produzione non correlato, nessun database condiviso e nessun dato di altri team.
2. Presumete che un agente che ottenga l'esecuzione di codice arbitrario all'interno della propria sandbox possa raggiungere l'host, e rendete gestibile questo scenario conservando i backup fuori dal sistema.
3. Leggete apps/runner/src o chiedete conferma al progetto upstream prima di dire a un collega che l'agente è confinato.

Per vedere come viene descritto un confine documentato e quali domande conviene rivolgere al progetto upstream, confrontate questo testo con come si presenta il confine di una vera sandbox per agenti. La differenza consiste nel fatto che qualcuno abbia documentato il meccanismo e ciò che non impedisce.

La separazione delle licenze e perché verificarla prima di procedere

Il core di OneCLI è distribuito con licenza Apache-2.0 e il self-hosting in produzione è consentito. Le directory denominate ee/ sono soggette a una licenza OneCLI Enterprise separata: sono gratuite per sviluppo, test e valutazione, mentre per l'uso in produzione è necessario un abbonamento. Le note di rilascio della versione v2.0.1 del 18 agosto 2026 indicano il ripristino di un file di licenza Apache-2.0 rilevabile da GitHub, quindi il badge nella pagina del repository è cambiato di recente. Verifica il tag che distribuisci effettivamente, invece di basarti su un riepilogo scritto in un'altra data.

cd onecli && find . -type d -name ee -not -path '*/node_modules/*'

Tutto ciò che si trova in quei percorsi appartiene alla parte commerciale. Se una funzionalità da cui prevedi di dipendere si trova in quelle directory, verifica prima il costo, prima di costruirvi un processo operativo.

Aggiornamenti, migrazioni e l’unico file che non puoi perdere

Gli aggiornamenti consistono nell’aumentare la versione e riavviare il servizio. Un servizio di migrazione eseguito una sola volta viene avviato prima dell’API a ogni up. Se una migrazione non riesce, lo stack non viene avviato invece di servire richieste usando uno schema migrato solo parzialmente. È il comportamento corretto, perché un aggiornamento non riuscito appare come un’interruzione del servizio anziché come una corruzione silenziosa. docker compose logs migrations spiega il motivo.

cd onecli/docker
docker compose pull
docker compose up -d --wait
docker compose logs migrations

Se hai eseguito l’installazione tramite lo script di installazione, esegui nuovamente quello script invece di scaricare i file manualmente. In questo modo il file Compose resta allineato alle immagini a cui fa riferimento.

Esegui il backup di due elementi. PostgreSQL contiene agenti, conversazioni, memoria e secret crittografati. Il file docker/.env contiene SECRET_ENCRYPTION_KEY. Senza quella chiave, i secret crittografati non sono leggibili. Un dump del database da solo non consente quindi di ripristinare nulla di utilizzabile.

cd onecli/docker
docker compose exec -T postgres pg_dump -U onecli onecli | gzip > ~/onecli-db.sql.gz
install -m 600 .env ~/onecli-env.backup

Conserva entrambe le copie fuori dal server. La procedura è la stessa richiesta da qualsiasi stack Compose stateful. Se già esegui il backup e l’aggiornamento di uno stack Docker Compose secondo una pianificazione, aggiungi questi due percorsi e non devi più occupartene.

Quando non funziona

• Lo stack non raggiunge mai lo stato healthy e docker compose up -d --wait termina con un codice diverso da zero. Leggi prima docker compose logs migrations, perché l’API attende deliberatamente che quel servizio sia disponibile.
• Un agent resta inattivo e non compare alcun sandbox. Verifica che COMPOSE_PROFILES=runner sia incluso in docker/.env e che docker compose ps elenchi un runner. Controlla quindi che all’agent sia stata assegnata una model key valida, perché i sandbox non vengono avviati senza.
• Non ci sono più slot disponibili. RUNNER_MAX_SANDBOXES è impostato per impostazione predefinita su 4 e un sandbox con un processo in background in esecuzione mantiene lo slot occupato in modo permanente. docker ps mostra i processi realmente attivi.
• I container scompaiono oppure l’host diventa molto lento. La memoria è esaurita. dmesg -T | grep -i oom registra le terminazioni eseguite dal kernel per out-of-memory e un singolo sandbox può utilizzare autonomamente 2048 MB.
• Le chiamate HTTPS di un agent terminano con errori di verifica del certificato, non con errori di autenticazione. Il relativo client HTTP non considera attendibile la certificate authority del gateway.
• Dopo l’eliminazione di un agent restano container o volumi obsoleti. Il runner esegue la riconciliazione ogni 60 secondi e distrugge gli orfani più vecchi di RUNNER_ORPHAN_GRACE_SECONDS, che per impostazione predefinita è 3600. Attendi quindi un’ora prima di considerarlo una perdita.

È la soluzione giusta per te?

La verifica di adeguatezza è breve. OneCLI è adatto quando più persone hanno bisogno di un agent e vuoi gestire le credenziali in un unico punto: un solo archivio da ruotare, un unico audit log da consultare e un'unica dashboard in cui la revoca dell'accesso di una persona abbia effetto reale. Questo è un problema operativo concreto, e copiare una API key su sei laptop è una soluzione ancora peggiore.

Per una sola persona, invece, è un'infrastruttura eccessiva senza alcun vantaggio. Dovresti eseguire PostgreSQL, un control plane, un gateway e un runner per fornire un singolo agent; inoltre, il problema delle credenziali risolto dal gateway è quasi inesistente quando l'unico titolare della key sei tu. In alternativa, esegui un singolo harness su un server più piccolo: un singolo harness per agent su un VPS svolge lo stesso compito usando una frazione della memoria. Se non hai ancora scelto una direzione, la panoramica confronto tra agent AI self-hosted è il primo passo più economico.

FAQ

Quali sono i requisiti minimi del server per eseguire OneCLI in self-hosting?

Docker con il plugin Compose versione 2.19 o successiva e memoria sufficiente. PostgreSQL è incluso nel file Compose, quindi non è necessario installarlo separatamente. La memoria determina il dimensionamento: per impostazione predefinita, il runner assegna 2048 MB a ogni sandbox dell'agent; la documentazione richiede circa 10 GiB liberi oltre allo stack di base per il limite predefinito di quattro sandbox e circa 2 GB sono destinati a PostgreSQL e ai quattro servizi a esecuzione continua. Un server con 4 GB esegue un agent alla volta. Un server con 16 GB gestisce senza problemi il limite predefinito. Un VPS con 1 GB o 2 GB non può avviare alcun agent ospitato.

OneCLI richiede PostgreSQL o può usare SQLite?

Richiede PostgreSQL. DATABASE_URL è documentato come stringa di connessione PostgreSQL, il file Compose fornito esegue postgres:18-alpine con un volume pgdata e un servizio separato per le migrazioni applica lo schema prima dell'avvio dell'API. Non è documentata alcuna opzione SQLite. Se PostgreSQL è già in esecuzione altrove, puntare DATABASE_URL a quell'istanza e mantenere il servizio per le migrazioni, perché una migrazione non riuscita arresta lo stack invece di consentire l'esecuzione con uno schema applicato solo parzialmente.

La sandbox dell'agent OneCLI costituisce un vero confine di sicurezza?

Il meccanismo documentato è un container Docker con limiti di memoria, CPU e processi, collegato a una rete contrassegnata come internal: true, senza alcuna route in uscita se non attraverso il gateway. Il controllo del traffico in uscita è effettivo e può essere verificato con docker network inspect. L'isolamento dal sistema host è quello offerto dai container; il progetto upstream non pubblica alcun modello delle minacce, né dichiara l'uso di rootless o degli user namespace, né offre un confine del kernel come gVisor o una microVM. Il runner monta inoltre /var/run/docker.sock, che equivale ad avere accesso root sull'host. Considerare non dimostrato il confine tra agent e host finché upstream non fornisce una dichiarazione esplicita, eseguire OneCLI su un server dedicato e conservare i backup fuori da quel server.

È necessario aprire porte in ingresso per OneCLI?

No. Il runner genera solo connessioni in uscita e non espone porte raggiungibili dall'esterno, quindi funziona dietro NAT senza tunnel. Per impostazione predefinita, il file Compose associa dashboard, gateway, API e PostgreSQL a 127.0.0.1. Accedere alla dashboard tramite un tunnel SSH oppure anteporre un reverse proxy con TLS alla porta 10254 se devono utilizzarla più persone. Il gateway sulla porta 10255 è destinato agli agent e, su un singolo server, tali agent lo raggiungono tramite la rete Docker interna.

OneCLI è gratuito per l'uso all'interno di un'azienda?

Il core è distribuito con licenza Apache-2.0 e l'uso self-hosted in produzione è consentito senza una licenza commerciale. Le directory denominate ee/ sono coperte dalla OneCLI Enterprise License, gratuita per sviluppo, test e valutazione, ma che richiede un abbonamento in produzione. La suddivisione cambia tra le release e le note della v2.0.1 del 18 agosto 2026 menzionano il ripristino di un file di licenza Apache-2.0 rilevabile da GitHub; prima di basare un workflow su una singola funzionalità, controllare quindi LICENSE e le directory ee/ nel tag esatto da distribuire.