El cloud que ya conoces.
La soberanía que te prometieron.

Significa que la plataforma está construida y funcionando — bare metal, almacenamiento, cómputo, red, Terraform, Kubernetes, servicios de datos y la fábrica de tenants están todos en servicio en nuestros propios centros de datos — pero el acceso se limita deliberadamente a un pequeño número de clientes fundadores mientras escalamos capacidad. Obtienes acceso directo a los ingenieros que construyeron la plataforma, influencia sobre lo que priorizamos a continuación y condiciones comerciales preferentes. Lo limitado es el número de tenants que incorporamos al mes, no el conjunto de capacidades.

Nuestro cloud privado es una plataforma dedicada, diseñada, dimensionada y operada para una sola organización. IG1 Cloud es un cloud público compartido y multitenant: autoservicio, dirigido por API, facturado por segundo, con capacidad que consumes en vez de aprovisionar. Muchos clientes usarán ambos — una plataforma privada dedicada para cargas reguladas o estables, e IG1 Cloud para capacidad elástica, entornos de desarrollo y proyectos nuevos. Ambos están conectados sobre el mismo tejido de red.

Tu estructura, módulos, pipelines y flujos de trabajo se trasladan directamente; los tipos de recurso cambian, como cambiarían entre dos proveedores cualesquiera. En la práctica, las migraciones son un cambio de proveedor más un ejercicio de correspondencia sobre tipos de instancia, red y clases de almacenamiento — trabajo que nuestros equipos hacen contigo en lugar de dejártelo como deberes. El estado remoto puede vivir en nuestro propio punto de acceso compatible con S3, para que tu código de infraestructura deje de depender del mismísimo cloud del que intentas independizarte.

Significa que la plataforma incluye un servidor MCP que expone 149 operaciones cloud como herramientas que un agente de IA puede invocar — listar instancias, crearlas, escalar un clúster, obtener un kubeconfig, leer el gasto del mes. La seguridad no descansa en que el agente se comporte bien. Cada credencial se emite en uno de tres niveles — solo lectura, operar o destructivo — y la plataforma aplica ese nivel en cada petición, así que un agente al que diste una clave de operación no puede borrar nada, por mucho que se le insista. Tampoco puede emitirse una clave más fuerte: acuñar una credencial exige poseer ya el nivel que se reparte. Las secuencias multipaso se limitan a una lista fija de operaciones permitidas, nunca código arbitrario ni acceso a shell, y revierten si fallan. Cada llamada se escribe en tu registro de auditoría con los parámetros suministrados pero nunca sus valores. Y como el servidor MCP se ejecuta dentro de nuestro perímetro y no posee identidad propia — reenvía tu credencial en cada llamada — ningún detalle de infraestructura se envía a un servicio de terceros.

IG1 Cloud funciona sobre servidores que compramos, en centros de datos que arrendamos y operamos, conectados a redes que gestionamos, con un plano de control y una organización de soporte atendidos por nuestros propios ingenieros en Francia. No hay matriz extranjera, ninguna entidad de fuera de la UE en la cadena de tratamiento, y ninguna dependencia de un hiperescalador para la plataforma en sí. Eso es lo que nos permite decir que la CLOUD Act estadounidense no alcanza ni tus datos ni tu plano de control — una afirmación que una región europea de un cloud estadounidense no puede hacer, estén donde estén físicamente los discos.

Sí, sin reservas. Llevamos 25 años siendo un operador agnóstico al cloud y pensamos seguir siéndolo — nuestra práctica de cloud público continúa exactamente como antes. IG1 Cloud es una opción adicional para cargas donde la soberanía, la economía de salida de datos o la previsibilidad importan más. Si AWS es la respuesta correcta para una carga concreta, te lo seguiremos diciendo; tener un cloud no ha cambiado cómo asesoramos.

Una política publicada, y una compilación que la aplica. Nuevos puntos de acceso, campos, comandos y herramientas de agentes pueden aparecer en cualquier versión — tus llamadas existentes siguen funcionando, porque se espera que los clientes ignoren lo que no reconocen. Solo se retira algo en una versión mayor, y la forma antigua sigue sirviendo durante una versión completa de solape tras anunciarse la retirada. Lo que la mayoría de proveedores calla es que nuestros mensajes de error también se versionan: el texto de rechazo sobre el que ramifican tus scripts y agentes no cambia en silencio. Y como la línea de comandos, el proveedor de Terraform y los SDK se generan desde la misma descripción que sirve la API en vez de escribirse a mano contra ella, un cambio que los desincronizaría hace fallar nuestra compilación antes de poder alcanzarte.

La incorporación crea un proyecto real y dedicado con sus propias cuotas y su propia identidad — no un entorno compartido con una etiqueta. A partir de ahí, el proyecto sobre el que actúan tus peticiones lo resuelve la plataforma a partir de tu token, en cada llamada. No existe deliberadamente ningún parámetro ni cabecera que un cliente pueda enviar para apuntarse a otro proyecto, y un identificador que pertenece a otro cliente responde «no encontrado» en vez de «prohibido», de modo que la plataforma nunca confirma que el recurso de otro exista. Esa resolución ocurre en nuestro lado de la API, lo que significa que vale igual para tus ingenieros, tus pipelines y tus agentes de IA.

Ambas cosas, desde el 25 de agosto de 2026. La puerta pública está abierta: una aplicación publicada a través del edge es accesible desde internet, y un dominio de su propiedad recibe un certificado Let's Encrypt de confianza pública, pedido automáticamente en cuanto el nombre resuelve hacia nosotros — usted reclama el dominio, lo demuestra con un registro TXT, y solo entonces se enruta una petición. Hay una frontera deliberada que conviene conocer antes de una prueba de concepto: el nombre de host que la plataforma le genera es un nombre interno con un certificado interno, así que todo lo que quiera en internet público corre bajo su propio dominio. Y su parque en sí — instancias, subredes privadas, clústeres de Kubernetes — se sigue alcanzando por conectividad privada, un túnel sitio a sitio desde su centro de datos o una VPN de cliente para cada ingeniero, que es como la mayoría de clientes fundadores opera su producción de todos modos. El edge publica aplicaciones; no es una puerta hacia su red.

Esta es la respuesta honesta y actual, y deliberadamente no es de marketing. Tus datos se escriben tres veces en tres máquinas distintas y se reparan solos, y puedes tomar instantáneas de tus propios volúmenes desde cualquier superficie — así que un disco averiado o un servidor muerto no pierde nada. Contra lo que tres copias no protegen es un borrado, una corrupción o un ransomware, porque esos se replican fielmente. El servicio de copia fuera del clúster — copias de volúmenes, replicación de objetos y copias de bases gestionadas hacia almacenamiento externo al clúster — es la fase en la que estamos, con el hardware presupuestado y solicitado. Mientras tanto, el propio estado de la plataforma se copia dos veces al día y se somete a un simulacro de restauración semanal contra el sistema en producción, y a cada tenant de la versión preliminar se le dice exactamente qué está protegido antes de poner nada en la plataforma. Cuando llegue el servicio para datos de clientes, cronometraremos una recuperación completa y publicaremos la cifra medida en lugar de una deseada.

La entrega objetivo es de menos de quince minutos desde la llamada de API hasta un kubeconfig, con la red de contenedores, el controlador cloud y una clase de almacenamiento respaldada por Ceph ya instalados — un clúster cuyos nodos se unen pero nunca quedan listos es el fallo clásico del autoservicio, y es el que eliminamos por diseño. El plano de control funciona como proceso gestionado en nuestra plataforma en lugar de como máquinas virtuales que alquilas, que es lo que hace económico un clúster de entrada; los workers son instancias ordinarias en tu propio proyecto, sobre tu propia cuota. Y la línea de responsabilidad está enunciada en el diseño en vez de descubrirse en un incidente: tú eres cluster-admin en tus workers, nosotros garantizamos la plataforma, la red y la salud de la máquina de debajo, y si tu propio cambio rompe un worker lo que te debemos es un redespliegue rápido y no la reparación de un nodo que modificaste.

Por defecto, nada — hasta que lo apruebes. El acceso entre tenants era hasta ahora lo que es en cualquier proveedor cloud: permanente, unilateral e invisible. Lo eliminamos y lo reconstruimos como un ajuste que te pertenece. Eliges uno de tres modos: cada solicitud aprobada por un propietario de tu lado (el modo por defecto), acceso permanente con un alcance y una caducidad que fijas si prefieres que simplemente gestionemos las cosas, o rechazado sin más — una opción legítima, cuya consecuencia declaramos por adelantado: no podremos investigar un incidente dentro de tu tenancy. Las concesiones tienen plazo. El rompe-cristal es deliberadamente caro: rechazado de plano bajo el modo «denegado», mucho más corto que una concesión aprobada, y exige un motivo y una referencia de ticket antes de anunciarse ante ti mientras sigue activo. Cada paso se publica en un rastro de auditoría sellado con tu tenancy que puedes leer sin rol de administrador. Bajo el RGPD tú eres el responsable y nosotros un encargado que actúa sobre instrucciones documentadas; esto es esa frase convertida en un interruptor de tu consola. El trabajo de infraestructura que nombra a un host físico y no a un tenant — salud de nodos, estado del hipervisor, salud del almacenamiento — queda fuera del ámbito del consentimiento, porque el consentimiento gobierna tus datos, no nuestra sala de máquinas.

Todavía no, y preferimos decirlo a dejar que un diagrama lo insinúe. IG1 Cloud sirve hoy desde Equinix PA6 en la región de París, donde cada byte se escribe tres veces en tres máquinas distintas, así que un disco averiado o un servidor perdido es un no-evento. Una segunda zona de disponibilidad en OPCore PAR3 — una sede que IG1 ya opera para cloud privado e infraestructura gestionada — es la fase de construcción que convierte una sede resiliente en una región resiliente, con colocación y replicación entre zonas. Si una carga necesita resiliencia multisede antes de eso, dilo pronto: nuestras prácticas de cloud privado e infraestructura gestionada ya funcionan en nuestras tres sedes de París, y la respuesta honesta para esa carga hoy puede ser una de ellas y no IG1 Cloud.

Sí a ambas, y esta es la parte que la mayoría de alternativas soberanas omite. Un proyecto es aquí lo que una cuenta es en AWS: sus propias cuotas, su propia red, su propio aislamiento. Los creas tú mismo hasta el techo de tu nivel — comprobado contra tu recuento real antes de que exista nada, y rechazado en vez de permitido si ese techo no se puede leer. Luego los ordenas en un árbol organizativo y les adjuntas políticas de denegación que heredan hacia abajo: un nivel de privilegio máximo que se compone por el valor más estricto, denegaciones que se acumulan, y una rama que puede endurecer lo que heredó pero nunca ampliarlo. Es la semántica de AWS Organizations sin la factura de AWS. Dos detalles deliberados: borrar un proyecto no es una llamada de API de cliente, porque destruye todo lo que contiene y merece un humano; y cualquier credencial, incluida una de solo lectura, puede preguntar bajo qué nivel está efectivamente y qué política lo cambió — una barandilla que tus ingenieros no pueden inspeccionar es una barandilla que rodearán.

Por cómo está construida, que es el único argumento que vale a estas alturas. Aquí nada cuenta como terminado porque haya compilado o porque hayan pasado las pruebas: está terminado cuando está desplegado y una comprobación automatizada ha releído la plataforma en funcionamiento y confirmado el comportamiento — los paneles verdes pueden mentir, una relectura en vivo no. Hay cientos de controles automatizados, una vía offline de unas dos mil pruebas fijada para que no pueda encoger en silencio, y más de treinta guardas anti-deriva cuyo único trabajo es afirmar que dos copias del mismo hecho siguen coincidiendo. Cada lección aprendida a golpes se convierte en un postmortem numerado — síntoma, causa raíz, corrección, regla — y las recurrentes ascienden a guardas automatizadas para que el mismo error no pueda repetirse en silencio. Toda la plataforma se reconstruye desde su repositorio, y se ha reconstruido varias veces, que es la única prueba real de que una plataforma está automatizada y no ensamblada a mano. Y la disciplina se ve en lo que publicamos: todo en esta página está leído del sistema en producción, y lo que no está listo aparece nombrado en ella.