Die Cloud, die Sie bereits kennen.
Die Souveränität, die Ihnen versprochen wurde.

Es bedeutet, dass die Plattform gebaut ist und läuft — Bare Metal, Speicher, Rechenleistung, Netzwerk, Terraform, Kubernetes, Datendienste und die Tenant-Fabrik sind alle in unseren eigenen Rechenzentren in Betrieb —, der Zugang aber bewusst auf eine kleine Zahl von Gründungskunden begrenzt ist, während wir Kapazität aufbauen. Sie erhalten direkten Zugang zu den Ingenieuren, die die Plattform gebaut haben, Einfluss darauf, was wir als Nächstes priorisieren, und bevorzugte kommerzielle Konditionen. Begrenzt ist die Zahl der Tenants, die wir pro Monat aufnehmen, nicht der Funktionsumfang.

Unsere Private Cloud ist eine dedizierte Plattform, entworfen, dimensioniert und betrieben für eine einzige Organisation. IG1 Cloud ist eine geteilte, mandantenfähige Public Cloud: Selbstbedienung, API-gesteuert, sekundengenau abgerechnet, mit Kapazität, die Sie verbrauchen statt bereitzustellen. Viele Kunden werden beides nutzen — eine dedizierte private Plattform für regulierte oder gleichbleibende Lasten, und IG1 Cloud für elastische Kapazität, Entwicklungsumgebungen und neue Projekte. Beide sind über dasselbe Netzwerkgewebe verbunden.

Ihre Struktur, Module, Pipelines und Abläufe lassen sich direkt übernehmen; die Ressourcentypen ändern sich, wie sie es zwischen zwei beliebigen Providern täten. In der Praxis sehen Migrationen aus wie ein Provider-Wechsel plus eine Zuordnungsübung bei Instanztypen, Netzwerk und Storage Classes — Arbeit, die unsere Teams mit Ihnen erledigen, statt sie Ihnen als Hausaufgabe zu geben. Der Remote-Zustand kann auf unserem eigenen S3-kompatiblen Endpunkt liegen, damit Ihr Infrastrukturcode aufhört, von genau der Cloud abzuhängen, von der Sie unabhängig werden wollen.

Es bedeutet, dass die Plattform einen MCP-Server mitbringt, der 149 Cloud-Operationen als Werkzeuge bereitstellt, die ein KI-Agent aufrufen kann — Instanzen auflisten, sie anlegen, einen Cluster skalieren, ein kubeconfig abrufen, die Monatsausgaben lesen. Die Sicherheit beruht nicht darauf, dass der Agent sich gut benimmt. Jeder Satz Anmeldedaten wird auf einer von drei Stufen ausgestellt — nur Lesen, Bedienen oder Zerstörend —, und die Plattform setzt diese Stufe bei jeder Anfrage durch: ein Agent, dem Sie einen Bedienschlüssel gegeben haben, kann nichts löschen, egal wie er dazu aufgefordert wird. Er kann sich auch keinen stärkeren Schlüssel ausstellen: Anmeldedaten zu prägen setzt voraus, die vergebene Stufe bereits zu besitzen. Mehrstufige Abläufe sind auf eine feste Liste erlaubter Operationen begrenzt, nie beliebiger Code oder Shell-Zugriff, und werden bei einem Fehlschlag zurückgerollt. Jeder Aufruf wird mit den übergebenen Parametern, aber nie deren Werten, in Ihr Audit-Log geschrieben. Und weil der MCP-Server innerhalb unseres Perimeters läuft und keine eigene Identität besitzt — er leitet Ihre Anmeldedaten bei jedem Aufruf weiter —, wird kein Infrastrukturdetail an einen Drittdienst gesendet.

IG1 Cloud läuft auf Servern, die wir gekauft haben, in Rechenzentren, die wir mieten und betreiben, angebunden an Netze, die wir verwalten, mit einer Control Plane und einer Support-Organisation, die von unseren eigenen Ingenieuren in Frankreich besetzt sind. Es gibt keine ausländische Muttergesellschaft, keine Nicht-EU-Einheit in der Verarbeitungskette und keine Abhängigkeit von einem Hyperscaler für die Plattform selbst. Das erlaubt uns zu sagen, dass der US CLOUD Act weder Ihre Daten noch Ihre Control Plane erreicht — eine Aussage, die eine EU-Region einer US-eigenen Cloud nicht treffen kann, gleich wo die Festplatten physisch stehen.

Ja, ohne Vorbehalt. Wir sind seit 25 Jahren ein cloud-agnostischer Betreiber und wollen das bleiben — unsere Public-Cloud-Praxis läuft genau wie bisher weiter. IG1 Cloud ist eine zusätzliche Option für Lasten, bei denen Souveränität, Egress-Wirtschaftlichkeit oder Planbarkeit am stärksten zählen. Wenn AWS für eine bestimmte Last die richtige Antwort ist, sagen wir Ihnen das weiterhin; eine eigene Cloud zu besitzen hat nichts daran geändert, wie wir beraten.

Eine veröffentlichte Richtlinie und ein Build, der sie durchsetzt. Neue Endpunkte, Felder, Befehle und Agentenwerkzeuge können in jedem Release auftauchen — Ihre bestehenden Aufrufe funktionieren weiter, denn von Clients wird erwartet, dass sie ignorieren, was sie nicht kennen. Entfernt wird etwas nur bei einer Hauptversion, und die alte Form bedient nach der Ankündigung der Entfernung noch ein volles Release lang weiter. Was die meisten Anbieter verschweigen: auch unsere Fehlermeldungen sind versioniert — der Ablehnungstext, auf den Ihre Skripte und Agenten verzweigen, ändert sich nicht still. Und weil die Kommandozeile, der Terraform-Provider und die SDKs aus derselben Beschreibung erzeugt werden, die die API ausliefert, statt von Hand dagegen geschrieben zu sein, lässt eine Änderung, die sie entkoppeln würde, unseren Build scheitern, bevor sie Sie erreichen kann.

Das Onboarding legt ein echtes, dediziertes Projekt mit eigenen Quoten und eigener Identität an — keine geteilte Sandbox mit einem Etikett darauf. Von da an wird das Projekt, auf das Ihre Anfragen wirken, von der Plattform bei jedem Aufruf aus Ihrem Token aufgelöst. Es gibt bewusst keinen Parameter und keinen Header, den ein Client senden könnte, um sich auf ein anderes Projekt zu richten, und eine Kennung, die einem anderen Kunden gehört, antwortet „nicht gefunden“ statt „verboten“, sodass die Plattform nie bestätigt, dass die Ressource eines anderen existiert. Diese Auflösung geschieht auf unserer Seite der API, was bedeutet, dass sie für Ihre Ingenieure, Ihre Pipelines und Ihre KI-Agenten gleichermaßen gilt.

Beides, seit dem 25. August 2026. Die öffentliche Eingangstür ist offen: Eine über den Edge veröffentlichte Anwendung ist aus dem Internet erreichbar, und eine Domain, die Ihnen gehört, erhält ein öffentlich vertrauenswürdiges Let's-Encrypt-Zertifikat, automatisch bestellt, sobald der Name auf uns auflöst – Sie beanspruchen die Domain, weisen sie über einen TXT-Eintrag nach, und erst dann wird eine Anfrage geroutet. Eine Grenze ist bewusst gesetzt und sollte vor einem Proof of Concept bekannt sein: Der Hostname, den die Plattform für Sie erzeugt, ist ein interner Name mit einem internen Zertifikat – alles, was öffentlich sein soll, läuft daher unter Ihrer eigenen Domain. Und Ihr Bestand selbst – Instanzen, private Subnetze, Kubernetes-Cluster – wird weiterhin über private Konnektivität erreicht, einen Site-to-Site-Tunnel aus Ihrem Rechenzentrum oder ein Client-VPN für einzelne Ingenieure, wie ohnehin die meisten Gründungskunden ihre Produktion betreiben. Der Edge veröffentlicht Anwendungen; er ist keine Tür in Ihr Netz.

Hier ist die ehrliche, aktuelle Antwort, und sie ist bewusst keine Marketingantwort. Ihre Daten werden dreimal auf drei getrennte Maschinen geschrieben und heilen sich selbst, und Sie können von jeder Oberfläche aus Snapshots Ihrer eigenen Volumes ziehen — eine defekte Festplatte oder ein toter Server verliert also nichts. Wogegen drei Kopien nicht schützen, ist ein Löschvorgang, eine Beschädigung oder ein Ransomware-Vorfall, denn diese replizieren sich getreu mit. Der Sicherungsdienst außerhalb des Clusters — Volume-Sicherungen, Objektreplikation und Sicherungen verwalteter Datenbanken auf Speicher außerhalb des Clusters — ist die Phase, in der wir stehen, mit kalkulierter und beantragter Hardware. Währenddessen wird der Zustand der Plattform selbst zweimal täglich gesichert und wöchentlich gegen das laufende System wiederhergestellt, und jedem Preview-Tenant wird genau gesagt, was geschützt ist, bevor er irgendetwas auf die Plattform legt. Wenn der Dienst für Kundendaten steht, stoppen wir eine vollständige Wiederherstellung und veröffentlichen die gemessene Zahl statt einer erhofften.

Die Zielauslieferung liegt unter fünfzehn Minuten vom API-Aufruf bis zum kubeconfig, mit Container-Netzwerk, Cloud-Controller und einer Ceph-gestützten Storage Class bereits installiert — ein Cluster, dessen Knoten beitreten, aber nie bereit werden, ist der klassische Selbstbedienungsfehler, und genau den haben wir wegkonstruiert. Die Control Plane läuft als verwalteter Prozess auf unserer Plattform statt als virtuelle Maschinen, die Sie mieten, was einen Einstiegscluster wirtschaftlich macht; die Worker sind gewöhnliche Instanzen in Ihrem eigenen Projekt, auf Ihrer eigenen Quote. Und die Verantwortungslinie steht im Entwurf, statt in einem Vorfall entdeckt zu werden: Sie sind Cluster-Admin auf Ihren Workern, wir garantieren die Plattform, das Netzwerk und die Gesundheit der Maschine darunter, und wenn Ihre eigene Änderung einen Worker bricht, schulden wir Ihnen ein schnelles erneutes Ausrollen und nicht die Reparatur eines Knotens, den Sie verändert haben.

Standardmäßig nichts — bis Sie es genehmigen. Tenant-übergreifender Zugriff war bisher das, was er bei jedem Cloud-Anbieter ist: dauerhaft, einseitig und unsichtbar. Wir haben ihn entfernt und als Einstellung neu gebaut, die Ihnen gehört. Sie wählen einen von drei Modi: jede Anfrage von einem Eigentümer auf Ihrer Seite genehmigt (die Voreinstellung), dauerhafter Zugriff mit einem Geltungsbereich und einem Ablauf, den Sie setzen, falls Sie möchten, dass wir die Dinge schlicht verwalten, oder rundweg abgelehnt — eine legitime Wahl, deren Folge wir vorab nennen: wir können dann keinen Vorfall innerhalb Ihrer Tenancy untersuchen. Gewährungen sind zeitlich begrenzt. Der Notfallzugriff ist bewusst teuer: unter „abgelehnt“ rundweg verweigert, weit kürzer als eine genehmigte Gewährung, und er verlangt eine Begründung und eine Ticketreferenz, bevor er sich bei Ihnen meldet, während er noch aktiv ist. Jeder Schritt wird in eine mit Ihrer Tenancy gestempelte Audit-Spur veröffentlicht, die Sie ohne Administratorrolle lesen können. Nach der DSGVO sind Sie der Verantwortliche und wir ein Auftragsverarbeiter, der auf dokumentierte Weisungen hin handelt; dies ist dieser Satz, verwandelt in einen Schalter in Ihrer Konsole. Infrastrukturarbeit, die einen physischen Host statt eines Tenants benennt — Knotenzustand, Hypervisor-Status, Speicherzustand —, bleibt außerhalb des Einwilligungsbereichs, denn die Einwilligung regiert Ihre Daten, nicht unseren Maschinenraum.

Noch nicht, und wir sagen das lieber, als es ein Diagramm andeuten zu lassen. IG1 Cloud liefert heute aus Equinix PA6 in der Region Paris aus, wo jedes Byte dreimal auf drei getrennte Maschinen geschrieben wird — eine defekte Festplatte oder ein verlorener Server ist also ein Nicht-Ereignis. Eine zweite Verfügbarkeitszone bei OPCore PAR3 — ein Standort, den IG1 bereits für Private Cloud und verwaltete Infrastruktur betreibt — ist die Aufbauphase, die aus einem widerstandsfähigen Standort eine widerstandsfähige Region macht, mit zonenübergreifender Platzierung und Replikation. Wenn eine Last standortübergreifende Ausfallsicherheit braucht, bevor das steht, sagen Sie es früh: unsere Praxen für Private Cloud und verwaltete Infrastruktur laufen bereits über alle drei Pariser Standorte, und die ehrliche Antwort für diese Last kann heute eine davon sein statt IG1 Cloud.

Ja zu beidem, und das ist der Teil, den die meisten souveränen Alternativen auslassen. Ein Projekt ist hier, was ein Konto auf AWS ist: eigene Quoten, eigenes Netzwerk, eigene Isolation. Sie legen sie selbst an, bis zur Obergrenze Ihrer Stufe — gegen Ihren tatsächlichen Bestand geprüft, bevor irgendetwas existiert, und abgelehnt statt erlaubt, wenn diese Obergrenze nicht gelesen werden kann. Dann ordnen Sie sie in einem Organisationsbaum an und hängen Nur-Verbot-Richtlinien an, die nach unten vererben: eine Höchstprivilegienstufe, die sich aus dem strengsten Wert zusammensetzt, Verbote, die sich summieren, und ein Zweig, der verschärfen kann, was er geerbt hat, aber nie erweitern. Es ist die Semantik von AWS Organizations ohne die AWS-Rechnung. Zwei bewusste Details: das Löschen eines Projekts ist kein Kunden-API-Aufruf, weil es alles darin zerstört und einen Menschen verdient; und jeder Satz Anmeldedaten, auch ein nur lesender, kann erfragen, unter welcher Stufe er tatsächlich steht und welche Richtlinie sie geändert hat — eine Leitplanke, die Ihre Ingenieure nicht einsehen können, ist eine Leitplanke, die sie umfahren werden.

Wegen der Art, wie sie gebaut ist — das ist in diesem Stadium das einzige Argument, das zählt. Hier gilt nichts als fertig, weil es kompiliert hat oder die Tests durchgelaufen sind: fertig ist es, wenn es ausgerollt ist und eine automatisierte Prüfung die laufende Plattform zurückgelesen und das Verhalten bestätigt hat — grüne Dashboards können lügen, ein Rücklesen im Betrieb nicht. Es gibt Hunderte automatisierter Prüfungen, eine Offline-Spur von rund zweitausend Tests, festgeschrieben, damit sie nicht still schrumpfen kann, und über dreißig Drift-Wächter, deren einzige Aufgabe es ist, zu bestätigen, dass zwei Kopien derselben Tatsache noch übereinstimmen. Jede teuer erkaufte Lehre wird zu einem nummerierten Postmortem — Symptom, Grundursache, Behebung, Regel —, und die wiederkehrenden werden zu automatisierten Wächtern befördert, damit derselbe Fehler nicht zweimal still passieren kann. Die gesamte Plattform baut sich aus ihrem Repository neu auf, und sie wurde mehrfach neu aufgebaut — der einzige echte Beweis, dass eine Plattform automatisiert und nicht von Hand zusammengesetzt ist. Und die Disziplin zeigt sich daran, was wir veröffentlichen: alles auf dieser Seite ist vom laufenden System abgelesen, und was nicht fertig ist, wird darauf benannt.