The cloud you already know.
The sovereignty you were promised.

It means the platform is built and running — bare metal, storage, compute, networking, Terraform, Kubernetes, data services and the tenant factory are all live in our own data centers — but access is deliberately limited to a small number of founding customers while we scale capacity. You get direct access to the engineers who built the platform, influence over what we prioritize next, and preferential commercial terms. What is limited is the number of tenants we onboard per month, not the capability set.

Our private cloud is a dedicated platform designed, sized and operated for one organization. IG1 Cloud is a shared, multi-tenant public cloud: self-service, API-driven, billed per second, with capacity you consume rather than provision. Many clients will use both — a dedicated private platform for regulated or steady-state workloads, and IG1 Cloud for elastic capacity, development environments and new projects. The two are connected on the same network fabric.

Your structure, modules, pipelines and workflows carry over directly; the resource types change, as they would between any two providers. In practice, migrations look like a provider swap plus a mapping exercise on instance types, networking and storage classes — work our teams do with you rather than hand you as homework. Remote state can live on our own S3-compatible endpoint, so your infrastructure code stops depending on the very cloud you are trying to become independent from.

It means the platform ships an MCP server exposing 149 cloud operations as tools an AI agent can call — listing instances, creating them, scaling a cluster, retrieving a kubeconfig, reading the month's spend. Safety does not rest on the agent behaving well. Every credential is issued at one of three levels — read only, operate, or destructive — and the platform enforces that level on each request, so an agent you gave an operate key to cannot delete anything, no matter how it is prompted. It also cannot issue itself a stronger key: minting a credential requires already holding the level you are handing out. Multi-step sequences are limited to a fixed list of permitted operations, never arbitrary code or shell access, and roll back on failure. Every call is written to your audit log with the parameters that were supplied but never their values. And because the MCP server runs inside our perimeter and holds no identity of its own — it forwards your credential on each call — no infrastructure detail is sent to a third-party service.

IG1 Cloud runs on servers we bought, in data centers we lease and operate, connected to networks we manage, with a control plane and support organization staffed by our own engineers in France. There is no foreign parent company, no non-EU entity in the processing chain, and no dependency on a hyperscaler for the platform itself. That is what allows us to say the US CLOUD Act does not reach your data or your control plane — a claim an EU region of a US-owned cloud cannot make regardless of where the disks physically sit.

Yes, without reservation. We have been a cloud-agnostic operator for 25 years and we intend to stay one — our public cloud practice continues exactly as before. IG1 Cloud is an additional option for workloads where sovereignty, egress economics or predictability matter most. If AWS is the right answer for a given workload, we will still tell you so; owning a cloud has not changed how we advise.

A published policy, and a build that enforces it. New endpoints, fields, commands and agent tools can appear in any release — your existing calls keep working, because clients are expected to ignore what they do not recognise. Anything is only ever removed at a major version, and the old shape keeps serving through a full release of overlap after the removal has been announced. The part most providers leave unsaid is that our error messages are versioned too: the refusal text your scripts and agents branch on does not change quietly. And because the command line, the Terraform provider and the SDKs are generated from the same description the API serves rather than written by hand against it, a change that would desynchronise them fails our build before it can reach you.

Onboarding creates a real, dedicated project with its own quotas and its own identity — not a shared sandbox with a label on it. From then on, the project your requests act upon is resolved by the platform from your token, on every call. There is deliberately no parameter or header a client can send to point itself at a different project, and an identifier belonging to another customer answers “not found” rather than “forbidden”, so the platform never confirms that someone else's resource exists. That resolution happens on our side of the API, which means it holds for your engineers, your pipelines and your AI agents identically.

Both, as of 25 August 2026. The public front door is open: an application published through the edge is reachable from the internet, and a domain you own gets a publicly trusted Let’s Encrypt certificate ordered automatically once the name resolves to us — you claim the domain, prove it with a TXT record, and only then is a single request routed. One boundary is deliberate and worth knowing before a proof of concept: the hostname the platform generates for you is an internal name carrying an internal certificate, so anything you want on the public internet runs under your own domain. And your estate itself — instances, private subnets, Kubernetes clusters — is still reached over private connectivity, a site-to-site tunnel from your data center or a client VPN for individual engineers, which is how most founding customers run production anyway. The edge publishes applications; it is not a door into your network.

Here is the honest, current answer, and it is deliberately not a marketing one. Your data is written three times across three separate machines and heals itself automatically, and you can snapshot your own volumes from any surface — so a failed disk or a dead server loses nothing. What three copies do not protect against is a deletion, a corruption or a ransomware event, because those replicate faithfully. The off-cluster backup service — volume backups, object replication and managed-database backups to storage outside the cluster — is the phase we are in, with the hardware costed and requested. Meanwhile the platform’s own state is backed up twice a day and restore-drilled every week against the live system, and every preview tenant is told exactly what is protected before they put anything on the platform. When the customer-data service lands, we will time a full recovery and publish the measured number rather than an aspirational one.

Target delivery is under fifteen minutes from the API call to a kubeconfig, with container networking, the cloud controller and a Ceph-backed storage class already installed — a cluster whose nodes join but never become ready is the classic self-service failure and it is the one we engineered out. The control plane runs as a managed process on our platform rather than as virtual machines you rent, which is what makes an entry-level cluster economical; the workers are ordinary instances in your own project, on your own quota. And the responsibility line is stated in the design rather than discovered in an incident: you are cluster-admin on your workers, we guarantee the platform, the network and the health of the machine underneath, and if your own change breaks a worker what we owe you is a fast redeploy rather than a repair of a node you modified.

By default, nothing — until you approve it. Cross-tenant access used to be what it is at every cloud provider: standing, unilateral and invisible. We removed it and rebuilt it as a setting you own. You choose one of three modes: every request approved by an owner on your side (the default), standing access with a scope and expiry you set if you would rather we simply managed things, or denied outright — a legitimate choice, whose consequence we state up front, namely that we cannot investigate an incident inside your tenancy. Grants are time-boxed. Break-glass is deliberately expensive: refused outright under “denied”, far shorter than an approved grant, and it demands a reason and a ticket reference before it announces itself to you while it is still live. Every step is published to an audit trail stamped with your tenancy that you can read without an admin role. Under GDPR you are the controller and we are a processor acting on documented instructions; this is that sentence turned into a switch in your console. Infrastructure work that names a physical host rather than a tenant — node health, hypervisor state, storage health — stays outside the consent scope, because consent governs your data, not our machine room.

Not yet, and we would rather say so than let a diagram imply it. IG1 Cloud serves today from Equinix PA6 in the Paris region, where every byte is written three times across three separate machines, so a failed disk or a lost server is a non-event. A second availability zone at OPCore PAR3 — a site IG1 already operates for private cloud and managed infrastructure — is the build phase that turns a resilient site into a resilient region, with cross-zone placement and replication. If a workload needs multi-site resilience before that lands, say so early: our private cloud and managed infrastructure practices already run across all three of our Paris sites, and the honest answer for that workload today may be one of those rather than IG1 Cloud.

Yes to both, and this is the part most sovereign alternatives leave out. A project here is what an account is on AWS: its own quotas, its own network, its own isolation. You create them yourself up to your tier’s ceiling — checked against your live count before anything exists, and refused rather than allowed if that ceiling cannot be read. You then arrange them in an organisational tree and attach deny-only policies that inherit downward: a maximum privilege tier that composes by the strictest value, denials that accumulate, and a branch that can tighten what it inherited but never widen it. It is AWS Organizations semantics without the AWS bill. Two deliberate details: deleting a project is not a customer API call, because it destroys everything inside it and deserves a human; and any credential, including a read-only one, can ask what tier it is effectively under and which policy changed it — a guardrail your engineers cannot inspect is a guardrail they will route around.

Because of how it is built, which is the only argument worth making at this stage. Nothing counts as done here because it compiled or because the tests passed: it is done when it is deployed and an automated check has read the running platform back and confirmed the behaviour — green dashboards can lie, a live read-back cannot. There are hundreds of automated gates, an offline lane of around two thousand tests pinned so it cannot silently shrink, and thirty-plus drift guards whose only job is to assert that two copies of the same fact still agree. Every hard-won lesson becomes a numbered postmortem — symptom, root cause, fix, rule — and the recurring ones get promoted into automated guards so the same mistake cannot happen twice quietly. The entire platform rebuilds from its repository, and it has been rebuilt several times, which is the only real proof that a platform is automated rather than hand-assembled. And the discipline is visible in what we publish: everything on this page is read back from the live system, and the things that are not ready are named on it.