Il cloud che già conoscete.
La sovranità che vi è stata promessa.

Significa che la piattaforma è costruita e in funzione — bare metal, storage, calcolo, rete, Terraform, Kubernetes, servizi dati e la fabbrica di tenant sono tutti in servizio nei nostri data center — ma l'accesso è deliberatamente limitato a un piccolo numero di clienti fondatori mentre scaliamo la capacità. Ottenete accesso diretto agli ingegneri che hanno costruito la piattaforma, influenza su ciò che prioritizziamo dopo e condizioni commerciali preferenziali. Ciò che è limitato è il numero di tenant che integriamo al mese, non l'insieme delle capacità.

Il nostro cloud privato è una piattaforma dedicata, progettata, dimensionata e gestita per una sola organizzazione. IG1 Cloud è un cloud pubblico condiviso e multi-tenant: self-service, guidato da API, fatturato al secondo, con capacità che consumate anziché provisionare. Molti clienti useranno entrambi — una piattaforma privata dedicata per carichi regolamentati o stabili, e IG1 Cloud per capacità elastica, ambienti di sviluppo e nuovi progetti. I due sono collegati sullo stesso tessuto di rete.

La vostra struttura, i moduli, le pipeline e i flussi di lavoro si trasferiscono direttamente; i tipi di risorsa cambiano, come cambierebbero tra due provider qualsiasi. In pratica, le migrazioni somigliano a un cambio di provider più un esercizio di corrispondenza su tipi di istanza, rete e classi di storage — lavoro che i nostri team fanno con voi anziché lasciarvelo come compito. Lo stato remoto può risiedere sul nostro endpoint compatibile S3, così il vostro codice infrastrutturale smette di dipendere proprio dal cloud da cui state cercando di rendervi indipendenti.

Significa che la piattaforma include un server MCP che espone 149 operazioni cloud come strumenti che un agente IA può invocare — elencare istanze, crearle, scalare un cluster, recuperare un kubeconfig, leggere la spesa del mese. La sicurezza non poggia sul buon comportamento dell'agente. Ogni credenziale è emessa a uno di tre livelli — sola lettura, operare o distruttivo — e la piattaforma applica quel livello a ogni richiesta, quindi un agente a cui avete dato una chiave di operazione non può cancellare nulla, comunque venga sollecitato. Non può nemmeno emettersi una chiave più forte: coniare una credenziale richiede di possedere già il livello che si distribuisce. Le sequenze multi-passo sono limitate a un elenco fisso di operazioni permesse, mai codice arbitrario né accesso a shell, e tornano indietro in caso di errore. Ogni chiamata è scritta nel vostro log di audit con i parametri forniti ma mai i loro valori. E poiché il server MCP gira dentro il nostro perimetro e non possiede alcuna identità propria — inoltra la vostra credenziale a ogni chiamata — nessun dettaglio infrastrutturale viene inviato a un servizio terzo.

IG1 Cloud gira su server che abbiamo acquistato, in data center che affittiamo e gestiamo, collegati a reti che amministriamo, con un control plane e un'organizzazione di supporto composti dai nostri ingegneri in Francia. Non c'è una capogruppo estera, nessuna entità extra-UE nella catena di trattamento, e nessuna dipendenza da un hyperscaler per la piattaforma stessa. È ciò che ci permette di dire che il CLOUD Act statunitense non raggiunge né i vostri dati né il vostro control plane — un'affermazione che una regione europea di un cloud statunitense non può fare, ovunque siedano fisicamente i dischi.

Sì, senza riserve. Siamo un operatore agnostico rispetto al cloud da 25 anni e intendiamo restarlo — la nostra pratica di cloud pubblico prosegue esattamente come prima. IG1 Cloud è un'opzione aggiuntiva per i carichi in cui sovranità, economia dell'uscita dei dati o prevedibilità contano di più. Se AWS è la risposta giusta per un determinato carico, continueremo a dirvelo; possedere un cloud non ha cambiato il modo in cui consigliamo.

Una policy pubblicata, e una build che la applica. Nuovi endpoint, campi, comandi e strumenti per agenti possono comparire in qualsiasi release — le vostre chiamate esistenti continuano a funzionare, perché ci si aspetta che i client ignorino ciò che non riconoscono. Qualcosa viene rimosso solo a una versione maggiore, e la forma precedente continua a servire per un'intera release di sovrapposizione dopo l'annuncio della rimozione. La parte che la maggior parte dei fornitori tace è che anche i nostri messaggi di errore sono versionati: il testo di rifiuto su cui i vostri script e agenti si diramano non cambia in silenzio. E poiché la riga di comando, il provider Terraform e gli SDK sono generati dalla stessa descrizione che l'API serve anziché scritti a mano contro di essa, una modifica che li desincronizzerebbe fa fallire la nostra build prima che possa raggiungervi.

L'onboarding crea un progetto reale e dedicato con quote proprie e identità propria — non una sandbox condivisa con un'etichetta sopra. Da lì in poi, il progetto su cui agiscono le vostre richieste è risolto dalla piattaforma dal vostro token, a ogni chiamata. Non esiste deliberatamente alcun parametro o header che un client possa inviare per puntarsi a un progetto diverso, e un identificatore appartenente a un altro cliente risponde «non trovato» anziché «vietato», così la piattaforma non conferma mai che la risorsa di un altro esista. Quella risoluzione avviene dal nostro lato dell'API, il che significa che vale identicamente per i vostri ingegneri, le vostre pipeline e i vostri agenti IA.

Entrambe le cose, dal 25 agosto 2026. La porta pubblica è aperta: un'applicazione pubblicata tramite l'edge è raggiungibile da internet, e un dominio di vostra proprietà riceve un certificato Let's Encrypt pubblicamente attendibile, ordinato automaticamente non appena il nome risolve verso di noi — rivendicate il dominio, lo provate con un record TXT, e solo allora una richiesta viene instradata. C'è un confine deliberato che conviene conoscere prima di un proof of concept: il nome host che la piattaforma genera per voi è un nome interno con un certificato interno, quindi tutto ciò che volete su internet pubblico gira sotto il vostro dominio. E il parco in sé — istanze, sottoreti private, cluster Kubernetes — si raggiunge ancora tramite connettività privata, un tunnel site-to-site dal vostro data center o una VPN client per i singoli ingegneri, che è comunque il modo in cui la maggior parte dei clienti fondatori gestisce la produzione. L'edge pubblica applicazioni; non è una porta verso la vostra rete.

Ecco la risposta onesta e attuale, e deliberatamente non di marketing. I vostri dati sono scritti tre volte su tre macchine distinte e si riparano da soli, e potete fare snapshot dei vostri volumi da qualsiasi superficie — quindi un disco guasto o un server morto non perde nulla. Ciò da cui tre copie non proteggono è una cancellazione, una corruzione o un ransomware, perché quelli si replicano fedelmente. Il servizio di backup fuori cluster — backup dei volumi, replica a oggetti e backup dei database gestiti verso storage esterno al cluster — è la fase in cui siamo, con l'hardware quotato e richiesto. Nel frattempo lo stato della piattaforma stessa è sottoposto a backup due volte al giorno e a un'esercitazione di ripristino settimanale contro il sistema in produzione, e a ogni tenant dell'anteprima viene detto esattamente cosa è protetto prima di mettere qualsiasi cosa sulla piattaforma. Quando arriverà il servizio per i dati dei clienti, cronometreremo un ripristino completo e pubblicheremo il numero misurato anziché uno auspicato.

La consegna target è sotto i quindici minuti dalla chiamata API a un kubeconfig, con rete dei container, cloud controller e una storage class basata su Ceph già installati — un cluster i cui nodi si uniscono ma non diventano mai pronti è il classico fallimento del self-service, ed è quello che abbiamo eliminato per progetto. Il control plane gira come processo gestito sulla nostra piattaforma anziché come macchine virtuali che affittate, il che rende economico un cluster di ingresso; i worker sono istanze ordinarie nel vostro progetto, sulla vostra quota. E la linea di responsabilità è enunciata nel progetto anziché scoperta durante un incidente: voi siete cluster-admin sui vostri worker, noi garantiamo la piattaforma, la rete e la salute della macchina sottostante, e se una vostra modifica rompe un worker ciò che vi dobbiamo è un rideploy rapido e non la riparazione di un nodo che avete modificato.

Per impostazione predefinita, nulla — finché non lo approvate. L'accesso tra tenant era finora ciò che è presso qualsiasi fornitore cloud: permanente, unilaterale e invisibile. L'abbiamo rimosso e ricostruito come un'impostazione che vi appartiene. Scegliete una di tre modalità: ogni richiesta approvata da un proprietario dal vostro lato (l'impostazione predefinita), accesso permanente con un ambito e una scadenza che fissate voi se preferite che gestiamo semplicemente le cose, oppure rifiutato del tutto — una scelta legittima, la cui conseguenza dichiariamo in anticipo: non potremo indagare un incidente dentro la vostra tenancy. Le concessioni sono limitate nel tempo. Il break-glass è deliberatamente costoso: rifiutato del tutto sotto la modalità «negato», molto più breve di una concessione approvata, e richiede una motivazione e un riferimento di ticket prima di annunciarsi a voi mentre è ancora attivo. Ogni passo è pubblicato su una traccia di audit marcata con la vostra tenancy che potete leggere senza ruolo di amministratore. Sotto il GDPR voi siete il titolare e noi un responsabile che agisce su istruzioni documentate; questa è quella frase trasformata in un interruttore nella vostra console. Il lavoro infrastrutturale che nomina un host fisico anziché un tenant — salute dei nodi, stato dell'hypervisor, salute dello storage — resta fuori dall'ambito del consenso, perché il consenso governa i vostri dati, non la nostra sala macchine.

Non ancora, e preferiamo dirlo piuttosto che lasciare che un diagramma lo lasci intendere. IG1 Cloud serve oggi da Equinix PA6 nella regione parigina, dove ogni byte è scritto tre volte su tre macchine distinte, quindi un disco guasto o un server perso è un non-evento. Una seconda zona di disponibilità presso OPCore PAR3 — una sede che IG1 già gestisce per cloud privato e infrastruttura gestita — è la fase di costruzione che trasforma una sede resiliente in una regione resiliente, con collocazione e replica tra zone. Se un carico necessita di resilienza multi-sede prima di allora, ditelo presto: le nostre pratiche di cloud privato e infrastruttura gestita girano già su tutte e tre le nostre sedi parigine, e la risposta onesta per quel carico oggi potrebbe essere una di quelle anziché IG1 Cloud.

Sì a entrambe, ed è la parte che la maggior parte delle alternative sovrane tralascia. Un progetto qui è ciò che un account è su AWS: quote proprie, rete propria, isolamento proprio. Li create voi stessi fino al tetto del vostro livello — verificato contro il vostro conteggio reale prima che esista alcunché, e rifiutato anziché permesso se quel tetto non può essere letto. Poi li disponete in un albero organizzativo e vi allegate policy di sola negazione che ereditano verso il basso: un livello di privilegio massimo che si compone col valore più stretto, negazioni che si accumulano, e un ramo che può stringere ciò che ha ereditato ma mai allargarlo. È la semantica di AWS Organizations senza la fattura AWS. Due dettagli deliberati: cancellare un progetto non è una chiamata API del cliente, perché distrugge tutto ciò che contiene e merita un umano; e qualsiasi credenziale, inclusa una di sola lettura, può chiedere sotto quale livello si trova effettivamente e quale policy lo ha cambiato — un guardrail che i vostri ingegneri non possono ispezionare è un guardrail che aggireranno.

Per come è costruita, che è l'unico argomento che valga a questo stadio. Qui nulla conta come finito perché ha compilato o perché i test sono passati: è finito quando è distribuito e un controllo automatizzato ha riletto la piattaforma in funzione e confermato il comportamento — le dashboard verdi possono mentire, una rilettura dal vivo no. Ci sono centinaia di controlli automatizzati, una corsia offline di circa duemila test fissata perché non possa restringersi in silenzio, e oltre trenta guardie anti-deriva il cui unico compito è affermare che due copie dello stesso fatto continuano a coincidere. Ogni lezione appresa a caro prezzo diventa un postmortem numerato — sintomo, causa radice, correzione, regola — e quelle ricorrenti vengono promosse a guardie automatizzate perché lo stesso errore non possa ripetersi in silenzio. L'intera piattaforma si ricostruisce dal proprio repository, ed è stata ricostruita più volte, che è l'unica vera prova che una piattaforma sia automatizzata anziché assemblata a mano. E la disciplina si vede in ciò che pubblichiamo: tutto in questa pagina è rilevato dal sistema in produzione, e ciò che non è pronto vi è nominato.