Mitos

Computer isolati e forkabili per i tuoi agenti AI.
Fork di sandbox microVM in millisecondi su Kubernetes: esegui il fork di una VM in esecuzione in tentativi paralleli e ripristinala dalla memoria in decine di millisecondi.

Avvio rapido . Documentazione . Funzionalità . Confronto . Contribuisci . Community

SDK Mitos: crea una sandbox microVM, esegui codice e fai il fork in tentativi paralleli isolati

Cos'è Mitos

Mitos dà a ogni agente AI il proprio computer isolato: una microVM Firecracker isolata a livello hardware che esegue codice non fidato in sicurezza e che può essere forkata mentre è in esecuzione. Un fork live copy-on-write ramifica una VM calda in N fratelli indipendenti in decine di millisecondi, così un agente può esplorare molti tentativi in parallelo a partire da uno stato condiviso e pronto, e paghi solo per le pagine che ogni fratello modifica.

Eseguilo oggi sul tuo cluster Kubernetes, dove codice, dati e credenziali dei tuoi agenti non lasciano mai la tua infrastruttura, o sulla API ospitata senza nodi da gestire. Per quanto ne sappiamo, è l'unico runtime open source, auto-ospitabile, nativo per Kubernetes e in grado di fare il fork live di una VM in esecuzione, tutto in uno.

Avvio rapido

1. Installa e autenticati```bash

pip install mitos-run export MITOS_API_KEY=sk-... # a key from https://mitos.run; no Kubernetes required

L'SDK utilizza per impostazione predefinita l'endpoint ospitato. Lo stesso codice viene eseguito sul tuo cluster o su un sandbox-server autonomo impostando `MITOS_BASE_URL`. La chiave viene risolta dall'argomento o da `MITOS_API_KEY` e non viene mai registrata.

### 2. Crea una sandbox ed esegui il codice```python
import mitos

sb = mitos.create("python")                  # Ready microVM sandbox (~27 ms warm-claim)
print(sb.exec("echo hello").stdout)          # hello

# Files and a stateful code interpreter hang off the same flat handle.
sb.files.write("/workspace/plan.txt", "draft")
print(sb.run_code("import math; math.sqrt(144)").text)   # 12.0

Riferimento completo: mitos.run/docs/quickstart.

3. Fork in tentativi paralleli```python

N-way copy-on-write fork of the live VM: each sibling lands warm and independent.

a, b = sb.fork(2) a.exec("echo conservative > /workspace/plan.txt") b.exec("echo aggressive > /workspace/plan.txt")

sb.terminate()

Il client asincrono riflette la stessa superficie: `await mitos.aio.create("python")` restituisce un `AsyncDirectSandbox` con le stesse funzioni `exec` / `run_code` / `files` / `create_pty` / `fork` / `terminate`.

Le versioni bloccanti di `exec` e `run_code` funzionano sull'husk predefinito. Lo streaming di `exec` (`sb.exec(..., on_stdout=...)`), i processi in background (`sb.exec_background(...)`), e il PTY interattivo (`sb.create_pty()`) attualmente utilizzano il percorso engine e sono in fase di integrazione nell'husk predefinito; `run_code` restituisce un `KernelUnavailable` a chiusura forzata fino a quando il kernel non sarà disponibile nell'immagine base dell'husk.

### Eseguilo a modo tuo

Stesso motore, stessa API, più punti di accesso. La profondità è a un clic di distanza nella [documentazione](https://mitos.run/docs).

**Ogni linguaggio, due modalità.** Ogni SDK parla la stessa API REST del sandbox-server in **modalità diretta** (standalone o hosted), e ciascuno ha anche **modalità cluster** (un `AgentRun` che guida le CRD `mitos.run/v1` attraverso l'API Kubernetes). La denominazione del pool predefinito è identica byte per byte in tutti e sei.

| Linguaggio | Installazione | Diretto | Cluster | Documentazione SDK |
|---|---|---|---|---|
| Python | `pip install mitos-run` | sync + async | `AgentRun` | [sdk/python](https://github.com/mitos-run/mitos/blob/HEAD/sdk/python) |
| TypeScript | `npm i @mitos/sdk` | sì | `AgentRun` | [sdk/typescript](https://github.com/mitos-run/mitos/blob/HEAD/sdk/typescript/README.md) |
| Go | `go get github.com/mitos-run/mitos/sdk/go` | tipizzato, compatibile con `errors.Is` | `AgentRun` | [sdk/go](https://github.com/mitos-run/mitos/blob/HEAD/sdk/go/README.md) |
| Ruby | gem (solo stdlib) | sì | `AgentRun` | [sdk/ruby](https://github.com/mitos-run/mitos/blob/HEAD/sdk/ruby/README.md) |
| Rust | crate (bloccante) | sì | `AgentRun` | [sdk/rust](https://github.com/mitos-run/mitos/blob/HEAD/sdk/rust/README.md) |
| Java | JDK 17 (solo stdlib) | sì | `AgentRun` | [sdk/java](https://github.com/mitos-run/mitos/blob/HEAD/sdk/java/README.md) |

L'SDK Go è ospitato nel proprio modulo annidato (`github.com/mitos-run/mitos/sdk/go`), quindi importarlo non inserisce mai il controller nel tuo build.

**Self-hosting? Stesso codice.** Il chart Helm distribuisce lo stesso gateway utilizzato dal servizio hosted, quindi la guida rapida sopra funziona invariata contro il tuo cluster: punta `MITOS_BASE_URL` al tuo gateway e lascia tutto il resto invariato. Hosted e self-hosted sono un'unica esperienza; solo l'URL e chi lo gestisce differiscono.

**Controllo nativo Kubernetes, quando lo desideri.** Per i team di piattaforma che gestiscono pool in modo dichiarativo (GitOps, automazione basata su RBAC, operator), il percorso a due livelli dell'`AgentRun` salta il gateway e guida le CRD `mitos.run/v1` direttamente attraverso l'API Kubernetes:```python
from mitos import AgentRun

c = AgentRun()                                   # kubeconfig or in-cluster; autodetected
sb = c.sandbox("python", ready=True)             # claims a warm sandbox, waits Ready
print(sb.exec("python -c 'print(40 + 2)'").stdout)   # 42

fork_a, fork_b = sb.fork(2)                       # fork against shared warmed state
sb.terminate()

c.sandbox("python") crea pigramente un pool predefinito se non ne hai uno; passa pool="my-pool" per usarne uno esistente. Gli errori sollevano AgentRunError(code, cause, remediation). AsyncAgentRun rispecchia i percorsi critici e aggiunge create_pty() su WebSocket.

CLI e MCP.

La CLI mitos funziona con il gateway ospitato (nessun cluster necessario) o con il tuo cluster Kubernetes:```bash go install mitos.run/mitos/cmd/mitos@latest # requires a Go toolchain

Hosted mode: set MITOS_API_KEY, no kubeconfig required.

export MITOS_API_KEY=sk-... mitos sandbox create --pool python # create from the python template mitos sandbox exec "python3 -c 'print(42)'" mitos fork --count 2 # fork into 2 independent siblings mitos sandbox ls mitos sandbox terminate

Cluster mode (kubeconfig): target your own Kubernetes nodes.

mitos sandbox create --pool dev-default mitos run echo hello --pool dev-default

`mitos dev up` avvia un piano di controllo locale con un solo comando su un motore mock per lo sviluppo in modalità cluster. Un server MCP (`mitos-mcp`) espone sandbox come strumenti MCP per qualsiasi agente che parli MCP, e un [Agent Skill](https://github.com/mitos-run/mitos/blob/HEAD/skills/mitos/SKILL.md) insegna il flusso di lavoro agli agenti consapevoli delle skill. La matrice completa di installazione (script, Homebrew, deb/rpm, scoop/winget, checksum) si trova su [mitos.run/docs/install](https://mitos.run/docs/install).

**Integrati con l'agente che già utilizzi.** Ogni adattatore è un sottile shim sulle stesse operazioni native (`exec`, `run_code`, `files`, `fork`), senza dipendenze rigide dal pacchetto del framework: Claude Code e opencode (server MCP + skill agente), OpenAI Agents SDK, Claude Agent SDK, LangChain / deepagents, Vercel AI SDK / Pydantic AI / AutoGen / LlamaIndex (MCP standard), e shim di migrazione "cambia un import" per team che lasciano il cloud [E2B](https://mitos.run/docs/migrating-from-e2b) o [Daytona](https://mitos.run/docs/migrating-from-daytona). L'[hub delle integrazioni](https://github.com/mitos-run/mitos/blob/HEAD/docs/integrations/README.md) indicizza ogni percorso.

**Installa l'operatore.**```bash
kubectl apply -k deploy/

Il base kustomize autonomo installa i CRD, il controller (modalità husk), il DaemonSet forkd, il plugin per dispositivo /dev/kvm e il bootstrap PKI, e si applica su un nodo KVM reale senza patch manuali. Il chart Helm è pubblicato sul registro OCI su GHCR: helm install mitos oci://ghcr.io/mitos-run/charts/mitos --version 1.42.1; vedere deploy/charts/mitos. Quindi dichiarare un pool caldo, e creare una fork da esso con una Sandbox il cui source.fromSandbox punta a una sessione live (modelli):```yaml apiVersion: mitos.run/v1 kind: SandboxPool metadata: name: python-agent-pool spec: template: image: python:3.12-slim init: ["pip install numpy pandas requests"] resources: { cpu: "1", memory: "512Mi" } volumes: - { name: workspace, size: 5Gi, forkPolicy: Snapshot } warm: { min: 10 }

**Dove viene eseguito.** L'unico requisito del nodo è `/dev/kvm` più l'etichetta `mitos.run/kvm=true`, quindi mitos si installa su qualsiasi cluster Kubernetes con nodi KVM bare-metal o a virtualizzazione annidata:

| piattaforma | nodo KVM | guida |
|---|---|---|
| Bare metal (Talos, Hetzner) | nativo `/dev/kvm` | [docs/platforms/talos-hetzner.md](https://github.com/mitos-run/mitos/blob/HEAD/docs/platforms/talos-hetzner.md) (riferimento di prima classe) |
| AWS / EKS | gruppi di nodi `*.metal` o a virtualizzazione annidata | chart generico oggi; guida per cloud è issue [#919](https://github.com/mitos-run/mitos/issues/919) |
| GKE | pool di nodi a virtualizzazione annidata | chart generico oggi; guida per cloud è [#919](https://github.com/mitos-run/mitos/issues/919) |
| Azure / AKS | dimensioni VM con capacità di virtualizzazione annidata | chart generico oggi; guida per cloud è [#919](https://github.com/mitos-run/mitos/issues/919) |

Il chart e le CRD sono identici su tutte; solo il pool di nodi che fornisce `/dev/kvm` differisce.

## Perché Mitos

I harness per agenti necessitano di ambienti veloci e isolati in cui gli agenti possano leggere e scrivere file, installare pacchetti ed eseguire codice non fidato. Ogni opzione esistente impone un compromesso: velocità senza proprietà, isolamento senza fork, nativo Kubernetes senza avvii a caldo, o durabilità bloccata nel cloud di qualcun altro.

- **Fork live di una VM in esecuzione.** Fork copy-on-write a N vie di una microVM live: le figlie condividono le pagine di memoria del genitore finché non scrivono, quindi ogni fork atterra in un ambiente caldo e pronto. Diramare un agente in molti tentativi paralleli.
- **Attivazione warm-claim ~27 ms.** Le microVM Firecracker vengono ripristinate da uno snapshot della memoria in una classe di decine di millisecondi: P50 ~27 ms sul nodo di riferimento bare-metal, riproducibile da [`bench/husk-activate-latency.sh`](https://github.com/mitos-run/mitos/blob/HEAD/bench/husk-activate-latency.sh).
- **Open source, auto-ospitabile, nativo Kubernetes.** Per quanto ne sappiamo, l'unico runtime che fa tutte e tre le cose. Gestisci l'intero ciclo di vita tramite CRD dichiarative (`mitos.run`).

Due modi per eseguirlo:

- **Self-hostato (oggi):** qualsiasi cluster Kubernetes con nodi KVM. I tuoi dati non lasciano mai la tua infrastruttura. Bare metal (Talos + Hetzner) è la piattaforma di riferimento di prima classe.
- **Hosted (in corso):** lo stesso motore e API gestiti da noi, per team che vogliono millisecondi senza gestire nodi.

> Esistono due percorsi del motore. Il **percorso nativo pod husk è il predefinito**: ogni VM viene eseguita nel proprio pod non privilegiato, e il pod husk sorgente fa uno snapshot della sua VM in esecuzione così N pod figli la ripristinano tramite CoW. Il **percorso raw-forkd** esegue i fork nel motore in-process di forkd. Tutto ciò che è qui viene eseguito sul predefinito husk se non diversamente specificato con `engine path`.

I sandbox non sono pod. I meccanismi Kubernetes con ambito pod (NetworkPolicy, ResourceQuota, PSA) governano il pod husk, non il carico di lavoro all'interno della microVM; il sandbox è la VM, non il pod husk, e dove forniamo un equivalente è documentato come nostro. I percorsi completi dei dati claim ed exec e il diagramma dei componenti sono su [mitos.run/docs/architecture](https://mitos.run/docs/architecture).

## Benchmark

Ogni numero qui è riproducibile da [`bench/`](https://github.com/mitos-run/mitos/blob/HEAD/bench/) su hardware KVM reale; niente è pubblicato che un lettore non possa rigenerare (la regola del progetto di nessuna affermazione non verificata). Ogni riga indica cosa misura e il comando esatto che lo riproduce. I dati completi per esecuzione e il contesto hardware si trovano in [`bench/results/`](https://github.com/mitos-run/mitos/blob/HEAD/bench/results/).

### Tempo per l'interattività hosted, rispetto al set di pari ComputeSDK

Il tempo per l'interattività (TTI) è l'unico dato che è confrontabile con il [benchmark ComputeSDK pubblico](https://github.com/computesdk/benchmarks) con cui viene misurato ogni fornitore di sandbox hosted: il cronometro parte a `create()` e si ferma quando un comando è effettivamente stato ESECUTO all'interno del sandbox ed è tornato.

| provider | TTI P50 | misura |
|---|---|---|
| northflank | 95.9 ms | Pubblicato da ComputeSDK |
| **mitos** | **96.8 ms** | nostro harness, `api.mitos.run` |
| daytona | 136.2 ms | Pubblicato da ComputeSDK |
| e2b | 365.6 ms | Pubblicato da ComputeSDK |

Riproduci il nostro numero e la tabella dei pari (i numeri dei pari sono letti dal commit immutabile pubblicato da ComputeSDK, non rieseguiti da noi):```sh
MITOS_API_KEY=... python3 bench/tti-latency.py 100        # our TTI, N=100
python3 bench/peer-tti.py --date 2026-07-09 \
  --ref 3eddee1a972bd49aea56fd6c16d238ca0a45dece            # the peer table

Leggetelo con le avvertenze che il record completo indica e non nasconde: questo è il nostro harness a fianco dei loro numeri pubblicati, non una posizione misurata nella loro classifica; è l'esecuzione sequenziale (un burst concorrente prosciugherebbe il warm pool a singolo nodo di oggi, issue #586); e rivendicare un vero posto in classifica richiede la distribuzione dell'adattatore computesdk/computesdk (issue #891). Entro questi limiti, mitos hosted si colloca sotto Daytona e alla pari con Northflank, 100/100 iterazioni riuscite.

Forking all'interno del tuo cluster (un agente che genera sotto-agenti)

Quando un agente viene eseguito nel tuo cluster e si ramifica in tentativi paralleli, il costo che conta è il fork-to-first-exec: il tempo reale da un fork di una VM live al ritorno di un comando nel figlio. Misurato con lo stesso motore in-process che forkd utilizza:

metriche	numero	misure
fork -> prima esecuzione	P50 ~104 ms (nodo di riferimento), ~67 ms su reflink + NVMe	un fork live a un figlio pronto che serve exec
fork(n) fan-out	~56 ms P50 per figlio a n=4 e n=16	una base calda fan-out in N fratelli indipendenti
densità di memoria CoW	8 fork costano ~35 MiB residenti, non ~209 MiB	pagine uniche pagate, pagine condivise contate una volta
go build -o /tmp/bench ./cmd/bench/
/tmp/bench --mode fork-exec --template --data-dir --iterations 100 # fork -> first exec
/tmp/bench --mode fork-fanout --template --data-dir --fanout-n 1,4,16 # 1-to-N fan-out

Metodo completo e hardware in [bench/README.md](https://github.com/mitos-run/mitos/blob/HEAD/bench/README.md); risultati in [2026-06-19-bare-metal-fork-exec.md](https://github.com/mitos-run/mitos/blob/HEAD/bench/results/2026-06-19-bare-metal-fork-exec.md) e [2026-06-21-kvm-perf-correctness.md](https://github.com/mitos-run/mitos/blob/HEAD/bench/results/2026-06-21-kvm-perf-correctness.md).

### Attivazione warm-claim (il motore, non il round trip)

L'attivazione warm-sandbox del motore stesso (caricamento snapshot + handshake di correttezza fork + guest-ready) è P50 ~27 ms sul nodo di riferimento bare metal, riproducibile da [`bench/husk-activate-latency.sh`](https://github.com/mitos-run/mitos/blob/HEAD/bench/husk-activate-latency.sh). Questo è un numero diverso e più piccolo rispetto al TTI hostato end-to-end sopra; citare la cifra del motore contro il numero di un'API create di un concorrente sarebbe un errore di categoria, quindi li teniamo separati.

## Caratteristiche

Il percorso pod-nativo husk è quello predefinito. Alcune capacità vengono eseguite oggi solo sul `percorso engine` raw-forkd e sono contrassegnate, con un collegamento all'issue di tracciamento.

### Velocità

| Capacità | Cosa ottieni | Documentazione |
|---|---|---|
| Attivazione warm-claim | P50 ~27 ms sul nodo di riferimento bare metal (caricamento snapshot + handshake di correttezza fork + guest-ready); ripristino snapshot ~6-16 ms; ~3 MiB di memoria marginale per fork tramite condivisione pagine CoW | [BENCHMARKS.md](https://github.com/mitos-run/mitos/blob/HEAD/BENCHMARKS.md) |
| Pool pre-snapshot | Immagini OCI appiattite in rootfs ext4 e riscaldate con i tuoi passaggi `init` prima dello snapshot, così non c'è avvio a freddo al momento della richiesta | [docs/templates.md](https://github.com/mitos-run/mitos/blob/HEAD/docs/templates.md) |
| Condivisione memoria CoW | Paghi per le pagine uniche tra i fork, non per le copie | [mitos.run/docs/metering](https://mitos.run/docs/metering) |
| Distribuzione content-addressed | I fork scaricano solo i chunk sha256 mancanti da un detentore tramite mTLS; le ricostruzioni inviano delta sotto un contratto di compatibilità delle versioni | [docs/snapshot-distribution.md](https://github.com/mitos-run/mitos/blob/HEAD/docs/snapshot-distribution.md) |

### Isolamento

| Capacità | Cosa ottieni | Documentazione |
|---|---|---|
| Isolamento hardware per sessione | Un kernel dedicato per sandbox (KVM/Firecracker); sull'impostazione predefinita husk ogni VM viene eseguita in un pod non privilegiato e limitato da PSA, che è il confine per VM | [mitos.run/docs/threat-model](https://mitos.run/docs/threat-model) |
| Nessuna eredità silenziosa di segreti | I fork live di sandbox che contengono segreti vengono rifiutati a meno che non sia esplicitamente acconsentito; le credenziali vengono iniettate al momento della richiesta tramite vsock, mai incorporate negli snapshot | [mitos.run/docs/threat-model](https://mitos.run/docs/threat-model) |
| Egress deny di default | Un filtro nftables deny di default nel pod nella propria netns (indipendente da CNI), con un blocco incondizionato del cloud-metadata (169.254.169.254) e una lista consentita per modello per IP:porta e per nome tramite un proxy DNS nel pod. Verificato end to end su un cluster KVM reale; il guest non può influenzare l'applicazione | [mitos.run/docs/networking](https://mitos.run/docs/networking) |
| Crittografia a riposo | Contenitori LUKS2 per ambito con crypto-shredding e wrapping KMS envelope (dietro `--enable-encryption`, fail-closed); chiavi basate su HSM e ambito per workspace sono follow-up | [docs/encryption.md](https://github.com/mitos-run/mitos/blob/HEAD/docs/encryption.md) |

### Agent DX

| Capacità | Cosa ottieni | Documentazione |
|---|---|---|
| Exec bloccante | stdout e codice di uscita corretti tramite l'API sandbox | [mitos.run/docs/cli](https://mitos.run/docs/cli) |
| Exec in streaming e PTY | stdout/stderr incrementale, processi in background e un terminale WebSocket interattivo token-gated (`percorso engine`) | [mitos.run/docs/cli](https://mitos.run/docs/cli) |
| Interprete di codice | `run_code` con un kernel stateful e ricchi risultati multi-MIME, in ogni SDK e nel server MCP; `KernelUnavailable` fail-closed fino a quando il kernel non sarà distribuito nell'immagine di base husk | [mitos.run/docs/mcp](https://mitos.run/docs/mcp) |
| Errori leggibili da LLM | Ogni errore porta `{code, cause, remediation}`, analizzato dagli SDK in un `AgentRunError` strutturato | [docs/api/errors.md](https://github.com/mitos-run/mitos/blob/HEAD/docs/api/errors.md) |

### Nativo di Kubernetes

| Capacità | Cosa ottieni | Documentazione |
|---|---|---|
| CRD dichiarativi | `SandboxPool`, `Sandbox` (sorgente poolRef/fromSandbox/fromRevision), `Workspace`/`WorkspaceRevision` in `mitos.run/v1` con topologia di volume e comportamento fork | [docs/templates.md](https://github.com/mitos-run/mitos/blob/HEAD/docs/templates.md) |
| Esecuzione pod-nativa | Ogni VM per sandbox viene eseguita in un pod non privilegiato (`/dev/kvm` da un device plugin, non `privileged`), quindi le richieste CPU/memoria sono la verità dello scheduler e PSA governa il pod | [mitos.run/docs/threat-model](https://mitos.run/docs/threat-model) |
| Scheduling consapevole della capacità | Bin-packing CoW su holder caldi, un budget di overcommit CoW-aware, un limite `MaxSandboxes` host-DoS con prenotazione atomica di slot e backpressure `NoCapacity` tipizzata invece di OOM su un nodo | [docs/scheduling.md](https://github.com/mitos-run/mitos/blob/HEAD/docs/scheduling.md) |
| Autoscaling guidato dalla domanda | `SandboxPool.spec.autoscale` scala il numero di husk-pod dormienti a `clamp(inUse + targetSpare, minWarm, maxWarm)` con un cooldown anti-thrash; un pool fisso è semplicemente `minWarm == replicas` | [docs/scheduling.md](https://github.com/mitos-run/mitos/blob/HEAD/docs/scheduling.md) |
| Semantica di failure e GC | TTL delle richieste, sweep di VM orfane, riconciliazione al riavvio del controller, smaltimento crash del forkd tramite journal su disco, gestione della perdita del nodo e backpressure da saturazione, tutto collaudato in CI | [docs/failure-gc.md](https://github.com/mitos-run/mitos/blob/HEAD/docs/failure-gc.md) |

### Stato durevole

| Capacità | Cosa ottieni | Documentazione |
|---|---|---|
| Workspace forkabili durevoli | CRD `Workspace`/`WorkspaceRevision`: stato agente durevole, versionato, forkabile, indipendente da qualsiasi sandbox. `/workspace` si idrata all'avvio e una revisione committed si disidrata alla terminazione tramite il content-addressed store. Creazione -> commit -> fork verificata su un cluster KVM reale | [mitos.run/docs/workspaces](https://mitos.run/docs/workspaces) |
| Output e diff | `spec.lifetime.onTerminate.outputs` restringe la disidratazione ai sottoalberi elencati; `{diff: true}` registra un diff di content-hash rispetto alla head padre | [mitos.run/docs/workspaces](https://mitos.run/docs/workspaces) |
| Rendez-vous Git | Un output `{git}` invia rami per tentativo a un remote di rendez-vous (il motore invia; un umano o CI fa il merge). Best-effort su husk oggi | [mitos.run/docs/workspaces](https://mitos.run/docs/workspaces) |
| URL ambiente di sviluppo | `mitos workspace serve <ws> --pool P` richiede in warm una sandbox forkata legata al workspace e restituisce un URL `https://<label>.<expose-domain>/` pronto; ogni sessione forkata ottiene il proprio URL | [docs/recipes/dev-environment.md](https://github.com/mitos-run/mitos/blob/HEAD/docs/recipes/dev-environment.md) |

### Operabile

| Capacità | Cosa ottieni | Documentazione |
|---|---|---|
| Metriche e tracing | Metriche Prometheus del nodo e del controller, una traccia OpenTelemetry per richiesta (`--otlp-endpoint`) e un log di audit strutturato attivabile (`--audit-log`) che registra comando/percorso e conteggi di byte, mai contenuto o segreti | [mitos.run/docs/observability](https://mitos.run/docs/observability) |
| Metering CoW-aware | Il set di pagine del modello condiviso viene contato una volta, non una per fork, quindi fatturazione e scheduling riflettono l'onesto footprint fisico | [mitos.run/docs/metering](https://mitos.run/docs/metering) |
| Strumentazione per operatori | Plugin `kubectl mitos` (`ls` / `ps`) e report operativo `GET /v1/metering` | [mitos.run/docs/observability](https://mitos.run/docs/observability) |
| Bare metal di prima classe | Talos + Hetzner è la piattaforma di riferimento | [docs/platforms/talos-hetzner.md](https://github.com/mitos-run/mitos/blob/HEAD/docs/platforms/talos-hetzner.md) |
| Primo avvio per singolo utente | Quickstart k3s con un gate di login per un utente (solo QA, non produzione) | [docs/platforms/k3s-quickstart.md](https://github.com/mitos-run/mitos/blob/HEAD/docs/platforms/k3s-quickstart.md) |

## Confronto

Una tabella di numeri testa a testa appartiene qui solo quando il nostro harness può rigenerarla contro i concorrenti reali sullo stesso hardware, con script in questo repository. Questo harness è [#15](https://github.com/mitos-run/mitos/issues/15). I dati sottostanti sono **numeri pubblicati da altri vendor, per operazioni diverse, su hardware diverso, con metodologia diversa**: non sono misurati da noi e non costituiscono un'affermazione testa a testa.

| Runtime | Dato pubblicato (loro, non nostro) | Operazione descritta |
|---|---|---|
| Mitos (nostro, misurato) | ~27 ms P50 | attivazione warm-claim sul nodo di riferimento bare metal |
| E2B | ~150 ms | creazione sandbox |
| Daytona | sub-90 ms | creazione da snapshot |
| Modal | sub-secondo | creazione sandbox |
| CodeSandbox SDK | ~863 ms / ~495 ms | fork live / memory-resume |
| Fly Machines | < 1 s | avvio macchina |

Ciò che è comparabile e reale oggi è la mappa pareto qualitativa: la combinazione di open source, auto-ospitabile, nativo k8s e fork snapshot live è l'asse su cui Mitos è solo.

| | Mitos | E2B | Modal | Daytona | Morph | Cloudflare | Box | Agent Sandbox | Kata/KubeVirt | raw Firecracker |
|---|---|---|---|---|---|---|---|---|---|---|
| Isolamento hardware per sessione | KVM microVM | microVM | gVisor | container/VM | microVM | V8 isolate | VM | opzione Kata | KVM | KVM |
| Fork snapshot dello stato in esecuzione | sì, primitiva core | snapshot/resume | memory snapshots | no | sì (Infinibranch) | no | fork disco | no | no | fai-da-te |
| Richieste in millisecondi con pool caldo | sì (design center) | pool caldi | pool caldi | workspaces | sì | istanze isolate istantanee | non pubblicato | 1-3s freddo | secondi | fai-da-te |
| Workspace forkabili durevoli | CRD Workspace | no | volumi | workspaces | sì, proprietario | sì (disco) | no | PVC | PVC | no |
| API nativa di Kubernetes | CRD | API SaaS | API SaaS | SaaS/OSS | API SaaS | API SaaS | CLI nativa agente | CRD | CRD | no |
| Auto-ospitabile | sì, qualsiasi cluster KVM | OSS parziale | no | core OSS | no | no | no | sì | sì | sì |
| Opzione hostata | pianificata (stesso motore) | sì | sì | sì | sì | sì | sì (solo) | no | no | no |
| I tuoi dati rimangono sulla tua infrastruttura | sì (self-hosted) | no | no | parziale | no | no | no | sì | sì | sì |
| Open source | Apache 2.0 | parziale | no | parziale | no | no | no | Apache 2.0 | Apache 2.0 | Apache 2.0 |

I runtime SaaS (E2B, Modal, Daytona, Cloudflare) sono veloci, ma il codice, i dati e le credenziali dei tuoi agenti vengono eseguiti sull'infrastruttura di qualcun altro senza un percorso self-host a capacità equivalente. Morph ha costruito il modello di stato giusto (branch/restore) come cloud proprietario; la nostra primitiva Workspace punta alla stessa semantica, open source, alla velocità di fork(2). Agent Sandbox (k8s-sigs) sta vincendo lo standard API Kubernetes senza un motore di fork snapshot, motivo per cui forniamo una facciata di conformità (`cmd/facade`) per essere il suo backend più veloce anziché combatterlo ([docs/facade-conformance.md](https://github.com/mitos-run/mitos/blob/HEAD/docs/facade-conformance.md)). Kata, KubeVirt e raw Firecracker ti danno la primitiva di isolamento e lasciano i livelli di pool, fork, distribuzione e API agente come tuo problema.

Se un'alternativa ci supera su un asse a cui tieni e non abbiamo una linea di roadmap che lo chiuda, questo è un bug nella nostra strategia: apri un issue.

## Architettura

Mitos avvia microVM Firecracker, le fork tramite snapshot copy-on-write ed espone l'intero ciclo di vita tramite CRD dichiarativi (`SandboxPool`, `Sandbox`, `Workspace`) nel gruppo API `mitos.run/v1`. Una sandbox è una microVM, non un pod: ottiene isolamento hardware tramite KVM e i meccanismi a livello di pod (NetworkPolicy, ResourceQuota, PSA) non la governano.

I componenti:

- **controller** (Deployment): riconcilia i CRD, seleziona un nodo e guida `forkd`. Tiene traccia dei nodi fork disponibili attraverso un registro alimentato da heartbeat di capacità per nodo.
- **forkd** (DaemonSet): il demone per nodo che possiede le VM. Serve gRPC sulla porta `:9090` per il controller (fork, prepare-pool, heartbeat) e un'API HTTP sandbox sulla porta `:9091` per il traffico exec e file. Necessita di `/dev/kvm`, quindi viene eseguito solo su nodi con capacità KVM.
- **agente guest**: PID 1 all'interno di ogni microVM. Parla un protocollo vsock per exec, file, ambiente e notifiche fork.
- **sandbox-server**: lo stesso motore fork dietro una semplice API REST, senza necessità di Kubernetes, per loop locali e uso su singolo host.
- **SDK** (`sdk/python`, `sdk/typescript`, `sdk/go` e altri): client per il servizio hostato, un cluster o `sandbox-server`.

Due percorsi caldi portano il sistema:

- **Percorso claim**: il controller sceglie un nodo caldo dal registro e chiama `forkd` `Fork` tramite gRPC; la sandbox risultante segnala Ready attraverso l'API HTTP di `forkd` su quel nodo.
- **Percorso exec**: l'SDK o la CLI parlano con `forkd` sulla porta `:9091`, che funge da ponte tramite vsock verso l'agente guest all'interno della VM.

Fork è la primitiva core: una VM sorgente viene snapshotata una volta e N figli ripristinano da quello snapshot tramite copy-on-write, quindi ogni sibling arriva caldo e indipendente mentre le pagine del modello condivise vengono memorizzate e misurate una volta. Poiché Firecracker necessita di virtualizzazione hardware, il bare metal (Talos su Hetzner è la piattaforma di riferimento) è un target di prima classe; il piano di controllo cloud rimane su nodi ordinari mentre l'esecuzione atterra su macchine con capacità KVM.

## Stato del progetto

Sviluppo iniziale, pre-1.0 (ultima release `v0.3.0`). Non eseguire codice non fidato in produzione ancora: non c'è stata alcuna revisione di sicurezza esterna e alcuni controlli di isolamento rimangono aperti (vedi il [modello di minaccia](https://mitos.run/docs/threat-model) per lo stato esatto per confine). Il piano di controllo è reale end to end, collaudato in CI contro motori mock e VM Firecracker reali, e testato su un cluster KVM Talos a nodo singolo.

**Verificato su un cluster KVM reale (impostazione predefinita husk):** attivazione warm-claim, exec bloccante, `run_code` in fail-closed con `KernelUnavailable`, auto-riparazione / re-pend, riscaldamento pool più autoscaling guidato dalla domanda, fork sandbox live (il pod husk sorgente esegue lo snapshot della sua VM e N pod figli lo ripristinano tramite CoW, ciascuno un figlio Ready indipendente), workspace forkabili durevoli (create -> commit -> fork) e isolamento egress del pod (default-deny, blocco cloud-metadata, lista consentita per modello).

**Code non ancora sull'impostazione predefinita husk:** exec in streaming e PTY interattivo; hook di snapshot della memoria VM live per head di workspace ripristinabili; selezione store live S3/crittografia; push workspace husk `{git}`; e multi-nodo N>1 (progettato, verificato su nodo singolo).

[ROADMAP.md](https://github.com/mitos-run/mitos/blob/HEAD/ROADMAP.md) è la fonte unica per ciò che è fatto, in corso e bloccato. La regola operativa: questo repository non descrive mai un sistema che non esiste.

## Sviluppo locale (nessun KVM richiesto)

`mitos dev up` avvia un cluster kind locale su un piano di controllo mock e la CLI `mitos` guida l'intero percorso claim; il motore mock riconcilia i claim a Ready e esercita il dispatch del piano di controllo, ma un `exec` reale in una VM necessita di un nodo con `/dev/kvm`. Per il loop REST senza cluster, esegui `go run ./cmd/sandbox-server --mock --addr :8080` e punta l'SDK Python su di esso. Il walkthrough completo con kind è su [mitos.run/docs/cli](https://mitos.run/docs/cli).

## Documentazione

La documentazione completa si trova su **[mitos.run/docs](https://mitos.run/docs)**: quickstart, architettura, riferimento SDK e CLI, ciclo di vita della sandbox, workspace, rete e modello di minaccia, tutto renderizzato da questo repository.

La lunga coda completa (template, formato e distribuzione snapshot, crittografia e segreti, scheduling e densità, failure e GC, correttezza del motore fork, ricette e specifica API target v2) si trova in [`docs/`](https://github.com/mitos-run/mitos/blob/HEAD/docs/) in questo repository. La metodologia dei benchmark è in [BENCHMARKS.md](https://github.com/mitos-run/mitos/blob/HEAD/BENCHMARKS.md).

## Contribuire

I contributi sono benvenuti. Vedi [CONTRIBUTING.md](https://github.com/mitos-run/mitos/blob/HEAD/CONTRIBUTING.md) e [CLAUDE.md](https://github.com/mitos-run/mitos/blob/HEAD/CLAUDE.md) per le convenzioni, e la [pagina delle issue](https://github.com/mitos-run/mitos/issues) per il lavoro tracciato rispetto a [ROADMAP.md](https://github.com/mitos-run/mitos/blob/HEAD/ROADMAP.md).

## Sicurezza

Il modello di minaccia con lo stato per confine si trova su [mitos.run/docs/threat-model](https://mitos.run/docs/threat-model); non è stata ancora effettuata alcuna revisione di sicurezza esterna e il documento dice esattamente cosa è aperto. Per segnalare una vulnerabilità, vedi [SECURITY.md](https://github.com/mitos-run/mitos/blob/HEAD/SECURITY.md).

## Licenza

[Apache 2.0](https://github.com/mitos-run/mitos/blob/HEAD/LICENSE).

mitos v1.43.0

Categorie