Summary
- Delos Cloud is no longer only a memorandum or policy concept. Its own releases say the first operations centre in the greater Gütersloh area went live in September 2025, the second operations centre in the greater Leipzig area went live in January 2026, the security operations centre was already ready, and the data centres were in final preparation for production service.
- The commercial offer is a German public-sector cloud built on Microsoft Azure technology and operated by Delos Cloud with Arvato Systems personnel. Delos says it owns the infrastructure, runs the platform and licenses the products, while Microsoft contributes technology and Arvato supports German operation.
- Public routing evidence is real. RIPE RDAP for AS198678 names Delos Cloud GmbH, RIPEstat announced-prefix data shows four IPv4 prefixes and one IPv6 aggregate, and RIPEstat routing status shows broad collector visibility. The visible dependency is also clear: RIPEstat neighbour data sees AS212185, another Delos Cloud system, as AS198678's single public neighbour.
- The resilience test is therefore not whether Delos Cloud has a credible public footprint. It does. The test is whether customers can verify facility power, cooling, carrier diversity, maintenance practice, stock and support escalation behind the hosted services before critical public-sector workloads depend on them.
The public evidence now supports a serious operating inquiry
Delos Cloud GmbH is visible through official company pages, SAP releases, partner pages, customer-pilot material and Internet registry data. Its about page positions the company as a sovereign platform for digital public services in Germany, aligned with German security requirements and intended to support federal, state and municipal IT providers. Its product page says the offer is centred on Microsoft services provided sovereignly by Delos Cloud, including consumption-based and user-based services, while also leaving room for third-party software, open-source software and customer-developed applications.
That is a stronger public position than the "thin footprint" hypothesis would suggest if read as a question about company existence. The better downgrade is different. Delos Cloud has enough evidence to be treated as a real, advanced build. It does not yet publish enough physical and operational detail for outsiders to score every data-centre, transit, maintenance and migration dependency as production-proven. In a public-sector cloud, that distinction matters more than brand familiarity. A sovereign offer is still a hosted-capacity offer.
It still has to convert buildings, racks, routers, staff and contracts into services that remain usable when equipment fails.
The timeline is important. A September 2025 SAP release says Delos Cloud put its first operations centre into service in the greater Gütersloh area. The release says more than sixty people would be present there, that Arvato Systems operating staff would run Delos Cloud services, and that the centre had a major role in platform operation, security and certifications. It also said a second operations centre in the greater Leipzig area was close to completion, a third operations centre in the greater Frankfurt area would start construction shortly, and a security operations centre in the greater Frankfurt area was ready.
A January 2026 SAP release moved the story forward. It says the second operations centre in the greater Leipzig area had been placed into service, that the operations-centre infrastructure for production operation was complete, and that two completed operations centres gave the platform georedundant operational protection against outages and crisis scenarios. The same release says the associated security operations centre was ready and that Delos Cloud data centres were in final preparation for production operation. It also says the Leipzig centre would provide 80 workplaces and round-the-clock operation under strict security measures.
The public customer evidence also moved beyond generic interest. Delos Cloud's customer page lists pilot customers and named examples across federal and state-level public use cases, including one federal employment institution, a North Rhine-Westphalia finance and technology project, and cultural institutions in Baden-Württemberg. A May 2026 SAP release says Staatstheater Stuttgart started a pilot for Microsoft Office 365 and selected Azure services on the Delos Cloud platform, with the Badisches Staatstheater Karlsruhe also involved and SVA acting as consulting and implementation partner. A June 2026 SAP release says Delos Cloud had signed strategic partnerships with 15 companies at the start of its partner programme.
Taken together, these sources justify a serious infrastructure analysis rather than a sceptical dismissal. The question is no longer whether Delos Cloud appears in public records. The question is where the line lies between proven launch infrastructure and the parts customers still need to inspect: physical data halls, carrier routes, support escalation, restore paths, security attestations and commercial dependency on the Microsoft technology base.
Germany is the service area, but the site map is still bounded
Delos Cloud's service-area promise is unusually explicit. Its materials repeatedly say the platform is for the public sector in Germany and that data processing and operation are to remain in Germany. The February 2025 pricing release says the platform is meant for German public customers, that sensitive administrative data is processed in data centres and operating sites exclusively in Germany, and that Delos Cloud GmbH and the platform are subject to German jurisdiction. The D-Trust certificate release makes the same locality point while describing German TLS certificates for encrypted and authenticated communication.
That locality is commercially valuable. It is also not a complete site map. The public releases identify operations centres in the greater Gütersloh and Leipzig areas and a security operations centre in the greater Frankfurt area. They do not publish data-hall addresses, utility-feed designs, rack counts, power densities, building owners, meet-me rooms, fuel arrangements or carrier entrances. They say Delos Cloud data centres were in final preparation in January 2026. They do not name those data centres in the public releases reviewed here.
That boundary should be kept clear. An operations centre is where people monitor, operate, secure and respond. A data centre is where compute, storage and network equipment draw power, reject heat and connect to carriers. The two are related, but they are not interchangeable. A two-site operations arrangement can improve staff and command resilience even if the compute platform has separate physical dependencies. Conversely, two data halls can fail a customer if the operating desk, access control, carrier escalation or change approval is unavailable.
Delos Cloud's public material is strongest about the operations-centre layer and weaker about the data-hall layer.
The same caution applies to georedundancy. The January 2026 release says two completed operations centres secure operation through georedundancy against outages and crisis scenarios. That is an important claim about the operating layer. It does not by itself prove that every customer workload is synchronously replicated across two independent data halls, that every management system has active-active control, that every customer service has tested regional failover, or that every storage service can meet a specific recovery point. Those details may exist in customer documentation, but they are not all public.
For procurement, the right site question is therefore specific. Which region, availability design and data-centre pair supports the service being ordered? Which functions are controlled from Gütersloh, Leipzig or Frankfurt, and which functions run inside the data halls? Which failure can an operations centre absorb, and which failure requires data-centre staff, carrier engineers, spare hardware or Microsoft technology support? The public material opens that line of diligence; it does not close it.
The operator boundary is the core sovereignty claim
Delos Cloud's sovereignty argument rests on a separation of roles. The February 2025 pricing release says Delos Cloud uses Microsoft Azure hyperscale technology but brings those services sovereignly to German administration. It says Delos Cloud GmbH, as owner of the infrastructure, takes over platform operation and product licensing. Microsoft contributes as technology supplier. The October 2024 SAP contract release and a Bertelsmann report on the same contracts describe final contracts among Delos Cloud, Microsoft and Arvato Systems and say Arvato Systems will support platform operation in Germany.
This structure is material because a public-sector buyer is not only buying virtual machines or Office collaboration. It is buying a legal and operational allocation of control. Delos Cloud says it provides Microsoft technology in an environment operated by a German company, under German jurisdiction, with German security-cleared personnel and with data processed in Germany. That is a different proposition from buying ordinary public-cloud services in a global region and adding a German billing wrapper.
The boundary also creates dependency. If Microsoft is the technology supplier, Delos Cloud still depends on Microsoft software development, security updates, product evolution and licensing rights. If Arvato Systems staff operate services in the operations centres, Delos Cloud depends on Arvato hiring, training, clearance, shift coverage and facility procedures. If SAP is the parent and investor, Delos Cloud benefits from SAP scale but also sits inside a strategic programme that has to keep funding, contracts and public trust aligned. Sovereignty reduces some risks but concentrates others in a carefully designed chain.
The November 2025 resilience announcement with Bleu and Microsoft illustrates that chain. The SAP release says Delos Cloud and Bleu agreed cross-border technical and operational cooperation for extensive crisis and emergency scenarios, while Delos Cloud and Microsoft signed a separate agreement meant to support business continuity in Europe if external restrictions affected Microsoft cloud services for certain customers. This is useful because it shows Delos Cloud has thought about geopolitical service-continuity risk. It also shows why the operator boundary cannot be treated as a single wall. Some emergency remedies require legal rights, software access, Delos capacity, operational staff and customer migration capability at the same time.
The supportable conclusion is balanced. Delos Cloud has a public sovereignty design with named role separation. The design is meaningful. It is also not a substitute for proof that the physical facilities, update paths, staff procedures and emergency transfer arrangements work under load. A customer does not need to reject the design. A customer does need to test it against failure.
What Delos Cloud sells is not one simple cloud product
The Delos Cloud product catalogue spans infrastructure, platform and collaboration services. The portfolio page lists Azure Foundational Services, Azure Mainstream Services, Office 365, SAP services, third-party solutions, open-source software and customer-developed applications. It includes compute, storage, networking, databases, container services, monitoring and security-related items across the portfolio. The roadmap page frames the service set as a staged path toward a sovereign public-sector cloud.
That breadth matters for capacity. A virtual machine consumes CPU, memory, storage, network ports, host scheduling capacity, management-plane capacity and support time. A managed database consumes storage, memory, backup capacity and operational care. A collaboration tenant consumes identity, mail, storage, policy and support capacity. A backup or site-recovery service consumes secondary storage, network throughput, restore procedures and test time. A Kubernetes service consumes control-plane capacity, worker nodes, images, logging and security maintenance. A buyer sees one cloud catalogue. The operator has to run many capacity pools.
The February 2025 pricing release adds the economic frame. It says Delos Cloud would price sovereign Microsoft services for German public customers at 15 percent above the current Microsoft Germany list price, and that the price applies to Microsoft infrastructure and platform services provided by Delos Cloud, including Azure Foundational Services, Azure Mainstream Services and Microsoft Office 365. The surcharge is the visible price of sovereignty, but it is not a capacity guarantee.
A 15 percent uplift can pay for German operation, security requirements, separate infrastructure and control arrangements only if the platform reaches enough demand and if the underlying plant is planned with usable reserve.
Usable reserve is the hidden denominator. Delos Cloud can announce operations centres and a product portfolio, but a customer evaluating a production move needs capacity figures that are harder to publish: commissioned IT load, sold load, spare load, host clusters by service, storage reserve, network oversubscription, backup capacity, support staffing, patch windows and restore performance. Installed servers are not the same as usable cloud capacity. A rack with hardware but no tested automation, no spare storage, no approved maintenance path or no carrier diversity cannot carry critical workloads safely.
A region that can start a pilot tenant is not automatically ready for a large department migration.
This is why the platform's open and vendor-neutral claim matters. The partner programme and product pages say third parties can bring solutions to Delos Cloud. That can improve ecosystem depth, but it also adds variation. A partner-built application on Delos infrastructure may have different support, licensing, patch and restore terms from an Office 365 service. An open-source component may have different maintenance responsibilities from a Microsoft-provided component. Customer-developed applications may need landing zones, monitoring, backup, secrets handling and network segmentation that Delos supplies only in part.
The cloud catalogue is the start of capacity planning, not the end.
Routing evidence proves reachability, not the whole physical route
Delos Cloud's network evidence is stronger than many early-stage sovereign-cloud projects. RIPE RDAP for AS198678 identifies the autonomous system as deloscloud, registered on 1 May 2023, with Delos Cloud GmbH as registrant. RIPEstat's AS overview reported the AS announced on 12 July 2026. The announced-prefixes view showed five visible prefixes in the 28 June to 12 July 2026 window: 123.2.0.0/15, 142.221.0.0/16, 161.37.0.0/16, 168.86.0.0/17 and 2a07:3040::/32.
The scale of those prefixes is not trivial. RIPEstat routing status reported four IPv4 prefixes with 294,912 IPv4 addresses and one IPv6 aggregate equivalent to 65,536 /48s. It also reported 326 of 326 sampled IPv4 peers and 322 of 322 sampled IPv6 peers seeing the routes at the query time. RIPE RDAP IP records for the Delos IPv4 ranges identify Delos Cloud GmbH as the address holder for the visible allocations. RIPEstat RPKI validation returned valid origin status for AS198678 and 123.2.0.0/15, and the corresponding IPv6 validation returned valid for AS198678 and 2a07:3040::/32.
Those facts support one important claim: Delos Cloud has live public Internet routing under its own name. They do not support every claim a cloud buyer cares about. The RIPEstat neighbour view saw one public neighbour for AS198678: AS212185. RIPE RDAP for AS212185 identifies that AS as deloscloudconnect, registered to Delos Cloud GmbH on 26 June 2025. RIPEstat announced-prefix data for AS212185 showed two IPv4 /23s and two IPv6 /48s, while RIPEstat neighbour data for AS212185 saw AS2914, AS3356 and AS198678.
That pattern looks like an internal origin AS behind a Delos connect AS that then reaches global transit through large upstreams. It may be perfectly deliberate and resilient. It may also hide physical dependencies that the public BGP view cannot see. Does AS212185 receive diverse fibre entrances? Do AS2914 and AS3356 enter through separate meet-me rooms, conduits and optical systems? Can either carry full production load if the other fails? Are management and customer planes separated? Is there Internet exchange peering not visible in PeeringDB? Public routing cannot answer these questions.
It can only show the path shape that collectors see.
The absence of a public PeeringDB entry is also bounded evidence. A query to PeeringDB for AS198678 returns no network record. PeeringDB is voluntary; absence does not mean Delos Cloud lacks facilities, private interconnects or upstream contracts. It does mean the public cannot use PeeringDB to verify facility presence, exchange ports, traffic policy or peering contact details. For a sovereign cloud that depends on trusted connectivity into public-sector networks, the missing public interconnection profile increases the need for direct customer evidence.
The network grade is therefore medium rather than weak. The routes are live, RPKI-valid and broadly visible. The public route graph does not reveal enough physical diversity to treat the network edge as proven resilient. A customer should ask for the route-origin design, upstream carrier list, physical entrance diversity, DDoS handling, private public-sector connectivity, route-leak protections, failover test results and maintenance-notice rules before relying on Delos Cloud for high-impact workloads.
Power and cooling remain the unglamorous proof points
A sovereign cloud is still a power plant and cooling plant with software layered on top. The public Delos releases say data is processed in German data centres and that those data centres were in final preparation for production operation in January 2026. They do not disclose utility capacity, transformer topology, UPS design, generator rating, fuel runtime, cooling topology, water exposure, fire compartmentation or rack-density limits. That omission is understandable for security and commercial reasons, but it leaves the buyer with questions that cannot be skipped.
The BSI C5 catalogue page and the C5:2026 catalogue PDF show why this level of evidence is normal for cloud assurance. Cloud security includes physical security, operations, incident handling, business continuity, portability, service levels and supply-chain controls. Delos Cloud's own materials say it is aligned with BSI requirements and aims to support processing of sensitive public-sector data. That claim should ultimately be backed by attestations and test evidence, not only by launch statements.
For power, a customer needs to know the service boundary. Are the customer workloads placed in two physically independent data halls? Are utility feeds independent from substation to rack? How much IT load is commissioned versus merely installed? Can the generator plant carry IT load and cooling at the same time? What happens during refuelling in a prolonged outage? Which systems are concurrently maintainable, and what maintenance states reduce redundancy? A/B rack feeds do not mean much if they converge upstream at one switchboard or one UPS train.
For cooling, the customer needs a heat-removal map. A platform can remain electrically powered while inlet temperatures rise, components throttle and hosts shed load. Does the cooling plant have enough reserve at the sold load? Are chillers, pumps, controls, water supply and heat exchangers backed by independent power? Can cooling maintenance happen without moving customer workloads? What is the incident path if a cooling unit, controller or sensor network fails? These are not academic concerns. They decide whether a short plant fault becomes a service incident.
For fire and water exposure, the customer needs building-specific mitigation. German location helps with jurisdiction and staffing, but it does not reveal floor elevation, leak detection, gas suppression, smoke zoning, fuel storage, neighbouring tenant risk or emergency access. An official security assessment may cover those facts. The public releases do not publish them. Until the facts are visible to the buyer under appropriate confidentiality, the safe public statement is that data-centre location is German and data-hall resilience is not publicly scoreable.
Repair windows are where customers find out who really operates the service
Maintenance windows turn design into reality. A service can have two sites, two carriers and duplicate components yet still fail if repair procedures require unsafe manual steps, if spare parts are missing, if staff cannot reach the site, or if a change is applied without a rollback path. Delos Cloud's strongest public evidence on this front is its operations-centre build: two completed operating sites, security-cleared German staff from Arvato Systems, a security operations centre and a growing partner ecosystem.
That is positive. It also creates the next set of questions. Which team can open a data-hall rack? Which team can replace a failed storage shelf? Which team can approve a router change? Which team can delay or reject a Microsoft technology update? Which team notifies customers of a maintenance window? Which team declares an incident? In a three-party design, customer experience depends on the contract and authority map as much as on equipment count.
The Arvato Systems Delos Cloud page frames Arvato as a partner for the sovereign cloud for administration, and the September 2025 and January 2026 Delos releases both identify Arvato Systems operating staff inside the operations centres. The Bertelsmann report adds that Arvato Systems will operate the platform and that several German locations are involved in long-term operation. That gives Arvato an important role in the repair chain. It does not disclose exact escalation ladders, remote-hands response time, spare-stock policy or ticket targets.
Repair windows also interact with public-sector change control. A normal hyperscale cloud may roll out changes continuously across global regions. A sovereign public-sector cloud may need stricter notice, approval, documentation and separation of duties. That can improve control, but it can slow fixes if not designed well. The customer should ask for standard maintenance lead times, emergency-change rules, customer approval points, rollback procedures and evidence that planned maintenance has been completed without service loss at representative scale.
Support cover matters in the same way. The operations-centre releases promise round-the-clock operation. Round-the-clock operation does not automatically mean every service has 24/7 expert support, every partner application can be repaired at night, or every customer has the same severity path. Delos Cloud's partner programme divides partners into service, sell and build roles. That means a customer may have Delos Cloud, a service partner, a software vendor and an internal public-sector IT provider in one incident path. A repair window has to specify who calls whom, who owns the clock and who can make the fix.
Customer migration is a dependency, not a one-time onboarding task
Delos Cloud exists because public-sector customers want modern cloud services without giving up locality, jurisdiction and operational control. That migration promise is central. It is also one of the easiest places to overstate resilience. Moving workloads into a sovereign cloud does not automatically make them portable, restorable or independent from the underlying technology base.
The Delos customer page describes pilots as a way to test technical, contractual and organisational arrangements before larger adoption. The Staatstheater Stuttgart release says the pilot will test Office 365 functions and selected Azure services under real conditions, with attention to security, efficiency and integration into public cultural operations. That is a good use of pilots. It treats migration as empirical rather than assumed.
For customers, the practical migration questions are concrete. How are identities integrated? How are tenant policies set? Which Office 365 data can be exported and restored? Which Azure services are included at launch and which arrive later? Can virtual machines be moved out as images, or only rebuilt? How are databases, backups, logs, encryption keys and monitoring data exported? What happens if a public-sector body starts on ordinary Microsoft services and later moves to Delos Cloud, or starts on Delos Cloud and needs an emergency move elsewhere?
The more a workload uses managed services, the more migration depends on product-specific export paths.
The German Administrative Cloud Strategy material and FITKO DVC guidance point toward a broader federal cloud ecosystem rather than one isolated platform. That context is important. Delos Cloud may be one large component, but public bodies also need interoperability, procurement clarity and a way to avoid replacing one dependency with another dependency that is merely national. Data locality solves one problem. Data portability solves a different one.
The November 2025 Microsoft continuity agreement makes migration even more explicit. It says certain customers could have the option to move workloads to Delos Cloud if external restrictions prevented Microsoft from serving them. That is a strategic contingency. Its practical value depends on capacity, legal rights, software access, compatible service versions, customer readiness, bandwidth and test exercises. An emergency migration that has never been rehearsed is a hope, not a recovery capability.
The buyer should therefore treat migration artefacts as live operational evidence. Required evidence includes landing-zone patterns, identity integration guides, export instructions, service-by-service limitations, backup and restore tests, rollback criteria, cost impact and customer acceptance tests. The objective is not to make every workload cloud-agnostic. The objective is to know exactly where dependence is intentional, where it is temporary and where it becomes dangerous.
The main failure paths are ordinary, not exotic
Delos Cloud's strategic setting can make the risk feel geopolitical, but most service failures would still start in ordinary infrastructure.
The first path is rack or host failure. A server, storage shelf, top-of-rack switch or power distribution unit fails. If spare hardware is local and automation works, the customer may see little effect. If the failure hits a small service cluster, an immature region or a management system with limited reserve, customers may see provisioning errors, degraded performance or failed restores. Delos Cloud's public materials do not publish cluster sizes, spare ratios or restore times.
The second path is upstream or carrier failure. Public BGP shows AS198678 behind AS212185 and AS212185 adjacent to large transit providers. The design may have good private diversity, but the public route graph does not prove it. A carrier maintenance event, fibre cut, optical platform fault or route leak could isolate customer workloads or management paths even if compute remains healthy. Customers need to know the physical path diversity, not just the AS numbers.
The third path is software update and provider-contract failure. Delos Cloud depends on Microsoft technology while retaining German operation and control. Security updates, feature changes, licensing and emergency rights all have to cross that boundary safely. Too little update flow creates security and compatibility risk. Too much unmediated update flow weakens the sovereignty argument. The public releases show contracts exist; customers need the operational rules and evidence.
The fourth path is support and staff saturation. Two operations centres reduce staff-site risk, but a broad incident can still overload service desks, partner teams and escalation queues. Public-sector customers will want incident classification, severity targets, communication templates, out-of-hours authority and evidence from exercises. A major authentication, mail, network or storage incident affects far more people than a single virtual machine outage.
The fifth path is billing, procurement and entitlement mismatch. Delos Cloud's public offer is limited to eligible public customers in Germany and runs through partners and public-sector IT providers. A service may be technically ready but blocked by contract, entitlement, budget, procurement catalogue, partner availability or security approval. Hosted capacity becomes usable only when the customer can order, configure, connect and support it within the public-sector rules that apply.
The sixth path is data-portability failure. If a customer cannot export identities, mail, storage, databases, snapshots or logs fast enough, a service outage becomes a lock-in incident. Delos Cloud's DVC alignment and partner ecosystem may reduce that risk, but proof requires tested exits, not only standards language.
None of these paths is a reason to dismiss Delos Cloud. They are the paths any serious cloud platform has to make boring. Boring means documented, tested, rehearsed, measured and contractually owned.
Hosting economics decide how much resilience can be kept in reserve
The February 2025 price statement is useful because it exposes the economic problem as well as the buyer proposition. Delos Cloud says sovereign Microsoft services would be priced at 15 percent above the current Microsoft Germany list price for eligible public customers. That is a relatively crisp number for a product category often described only in strategic language. It lets customers ask a hard question: what must that margin cover?
The answer is wider than software licensing. The surcharge has to support German data-centre infrastructure, German operations-centre staffing, security-cleared personnel, compliance work, separate certificate arrangements, partner coordination, customer onboarding, incident response, support coverage and enough unused capacity to absorb growth and failure. Some of those costs are fixed before the first large customer arrives. Some scale with usage. Some become visible only during outages, when spare hosts, spare storage, alternate network paths and senior engineers have to be available even though they may sit idle on ordinary days.
This is where installed capacity and usable capacity split apart. A platform may have hardware installed in a German data hall, but the saleable portion is lower after reserve, maintenance headroom, disaster-recovery allocation, management-plane needs, backup space and growth buffers are deducted. If the platform sells too close to its installed ceiling, maintenance becomes riskier. If it keeps large reserves, the economic case needs enough customer demand to fund them. The customer sees a cloud price. The operator manages an inventory problem under security and locality constraints.
Public-sector procurement can amplify the challenge. Customers may arrive in waves after framework agreements, pilot approvals or budget cycles. A slow ramp can leave expensive infrastructure underused. A sudden ramp can stress service teams, quota planning and partner capacity. Some customers may need conservative limits while they complete security checks; others may want large migrations once a pilot succeeds. Delos Cloud's partner ecosystem can help absorb that work, but only if partner readiness, Delos quotas and customer governance line up at the same time.
For a buyer, the economic diligence is practical. Ask which services are generally available, which are capacity-limited, which require reservation, which have region or tenant quotas, and which support terms change with service class. Ask how Delos handles a sold-out zone, a scarce storage tier, a large Office migration, a sudden backup expansion or an emergency migration from another environment. A sovereign cloud can be good value only if the price buys not just locality and legal control but enough reserve to survive ordinary infrastructure stress.
Who is affected when the system fails
The direct customers are German public bodies and their IT providers. The practical users can be civil servants, theatre staff, finance teams, job-centre workers, municipal administrators, case handlers, security teams and citizens who depend on public digital services. The specific affected population depends on which service fails. An Office collaboration outage can affect staff communication. A virtual-network outage can isolate applications. A database or storage incident can stop case processing. An identity incident can block access across many services at once.
The responsibility chain is layered. Delos Cloud is the public platform operator and infrastructure owner according to its releases. Microsoft supplies the technology base. Arvato Systems supports German operation. Service partners may design, implement and migrate customer environments. Build partners may run application logic on the platform. Public-sector IT providers may contract, integrate and support the final service. A citizen experiencing an unavailable service will not see those layers, but the incident response will pass through them.
This is why the article title matters. Delos Cloud sells hosted capacity. Hosted capacity depends on racks, transit and repair windows even when the legal wrapper is sovereign and the software base is familiar. A failed storage shelf is not solved by jurisdiction. A carrier cut is not solved by a policy statement. A migration bottleneck is not solved by a price list. Sovereignty is a control claim; reliability is an operating record.
The strongest public case for Delos Cloud is that it has moved step by step from contracts to facilities, pilots, partners and routes. The strongest public caution is that the final production evidence is necessarily more specific than the public announcements. The data halls need current attestations. The transit design needs diversity proof. The repair chain needs authority proof. The customer exit paths need rehearsal. Once those are available to buyers, Delos Cloud can be evaluated as a production platform rather than a strategic promise.
What would settle the remaining questions
The evidence needed from Delos Cloud is not a demand for sensitive floor plans or customer names. It is the normal assurance package for critical hosted capacity.
First, publish or provide under suitable confidentiality the data-centre operating boundary: facility operator, German location region, data-hall scope, utility and generator class, cooling resilience, physical security controls, fire and water protections, and current certification or attestation scope. The goal is not to reveal exact rack rows. The goal is to show what system boundary has been assessed.
Second, provide service-by-service capacity evidence. Customers need to know what is technically available now, what is in pilot, what is planned, what depends on Microsoft release cadence, and what has enough spare capacity for migration waves. The Delos roadmap and portfolio are useful, but production workloads need current availability, quotas, limits, maintenance states and support commitments.
Third, disclose the network design at the right level. Public BGP already shows AS198678 and AS212185. Customers still need upstream diversity, physical entrance diversity, private public-sector connectivity, routing security, DDoS response, route failover tests and maintenance procedures. The absence of PeeringDB is not a defect by itself, but the missing public interconnection view should be replaced by direct evidence for customers.
Fourth, prove repair. That means recent evidence of power transfer tests, cooling failover, carrier failover, security-incident handling, backup restore, identity recovery, storage recovery, patch rollback and customer communication. Maintenance windows should say not only when work occurs but what redundancy remains during the work.
Fifth, prove portability. Customers need tested paths for tenant data, virtual machines, databases, logs, keys, backups and application dependencies. The DVC context makes interoperability a strategic goal; Delos Cloud still has to show how a specific customer can enter, expand, pause, recover or exit.
With that evidence, the Delos Cloud assessment can become stronger than "advanced but still needing proof at the physical and operational layer." Without it, the responsible conclusion is measured. Delos Cloud GmbH has public operating milestones, customer pilots, partner scale, a clear sovereignty design and live network resources. What remains to be verified is not the existence of the company. It is the reliability of the capacity sold under its name when the ordinary machinery of cloud service fails.