cnh-primary CLOUD & HEAT Technologies GmbH sells hosted capacity that still depends on racks, transit and repair windows

Summary

• cnh-primary maps to AS203592, the RIPE-registered autonomous system named "cnh-primary" and registered to CLOUD & HEAT Technologies GmbH. RIPE RDAP shows the AS as active, and RIPEstat showed it announced at 2026-07-15 00:00 UTC.
• The route surface is current and unusually well documented for this batch: RIPEstat listed 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29 and 2a0c:2c0:dd80::/44 as announced by AS203592, with valid RPKI for all four observed origins.
• PeeringDB records AS203592 as CLOUD & HEAT Technologies GmbH, with one listed facility, IBH Dresden C2, and one DD-IX connection at 10 Gbps with IPv4 and IPv6 addresses and route-server participation.
• The company's own pages describe IaaS, managed Kubernetes, OpenStack-based on-premises distribution work, GPU instances, Ceph storage, German data-centre hosting, ISO 27001 and ISO 9001 badges, SCS-compatible cloud work and customers such as Scalytics, tracetronic, Nyris, elevait, alphaspeech, flow.d and N+P.
• The evidence grade is Strong for network identity and product existence, Medium for facility and interconnection locality, and only Medium for resilience because public material does not disclose rack count, power topology, spare server pools, exact availability-zone placement, backup proof, customer-export tests or incident history.

The name starts as a route, but the company is broader than a route

The directory entry at https://btw.media/en/directory/cnh-primary-cloud-heat-technologies-gmbh points to a very specific public-infrastructure identity: cnh-primary CLOUD & HEAT Technologies GmbH. The "cnh-primary" part is not marketing flourish. It is the RIPE AS name for AS203592, shown in the RIPE Database at https://rest.db.ripe.net/ripe/aut-num/AS203592.json and in RDAP at https://rdap.db.ripe.net/autnum/203592. The AS was registered on 4 December 2015 and last changed on 28 January 2026. RDAP identifies the registrant as CLOUD & HEAT Technologies GmbH, with the Dresden address also visible on the company's own contact pages. That gives the article a firmer starting point than many small cloud profiles: there is a named company, a named AS, a public office identity, and active Internet-number registration.

The second layer is product evidence. CLOUD & HEAT's English homepage at https://www.cloudandheat.com/en/ describes the company as a Dresden cloud service and cloud technology provider with products built on OpenStack, Proxmox VE and Kubernetes. Its IaaS page at https://www.cloudandheat.com/en/products/cloud-services-in-germany/infrastructure-as-a-service/ sells compute sizes, block and object storage, GPU instances and German-hosted cloud capacity. Its managed Kubernetes page at https://www.cloudandheat.com/en/products/cloud-services-in-germany/managed-kubernetes-germany/ describes self-managed, on-demand, basic and full-service Kubernetes models. Its Patron page at https://www.cloudandheat.com/en/products/on-premises-cloud-infrastructures/on-premises-cloud-tailored/cloudandheat-a-ready-to-use-openstack-distribution/ sells an OpenStack distribution and optional operations support. This is not merely a dormant AS attached to a shell page.

That said, the company has more than one operating layer, and those layers should not be collapsed. AS203592 is the public routing layer. The IaaS and Kubernetes pages are product pages. The Patron and on-premises pages are consulting, software and managed-operation offers. The energy-efficiency pages and OpenInfra profiles describe sustainability and open-source positioning. A customer buying a virtual machine depends on different things from a customer buying a supported OpenStack distribution for its own hardware. A customer using managed Kubernetes depends on API access, clusters, persistent volumes, monitoring and maintenance windows.

A customer buying consulting depends on people and process more than on AS203592. The public company evidence is real, but each product has a different failure path.

The key question is therefore not whether CLOUD & HEAT exists. It plainly does. The question is what public evidence supports when the company is read as hosted infrastructure. RIPE, RIPEstat and PeeringDB support an AS203592 network map. The company site supports a public cloud and managed-service catalogue. OpenStack Marketplace at https://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-services lists Cloud & Heat cloud services and says the product is OpenStack Powered. OpenStack's supporting-company profile at https://www.openstack.org/community/supporting-organizations/profile/cloud-and-heat describes Cloud & Heat as a Dresden provider of cloud services and cloud technologies. None of these sources, however, provides a complete public capacity audit.

This is the distinction that matters for buyers. A public AS can be healthy while one availability zone has no spare machines. An OpenStack cloud can be listed while a particular GPU class is sold out. A managed Kubernetes offer can promise monitoring while a customer still needs its own backup, deployment and export plan. A facility entry can show a Dresden presence without revealing rack count, power feed design or remote-hands terms. The public record is strong enough to place cnh-primary in a serious infrastructure category, but it still has to be read with engineering caution.

The route evidence is current, visible and cleaner than a simple company page

RIPEstat's AS overview for AS203592 at https://stat.ripe.net/data/as-overview/data.json?resource=AS203592 identified the holder as "cnh-primary CLOUD & HEAT Technologies GmbH" and showed announced=true at 2026-07-15 00:00 UTC. That is a time-specific but important signal: the AS was not just registered; it was visible in public routing data on the publication date. RIPEstat's announced-prefixes endpoint at https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS203592 listed four routes in the two-week window ending 15 July 2026: 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29 and 2a0c:2c0:dd80::/44.

The routing-status endpoint at https://stat.ripe.net/data/routing-status/data.json?resource=AS203592 made the signal stronger. It reported two IPv4 prefixes, two IPv6 prefixes, 1,280 IPv4 addresses, 524,288 IPv6 /48 units, four observed neighbours, and full observed visibility in the RIPE RIS peer set for both IPv4 and IPv6 at the query time. Those numbers are not customer capacity. They do show that AS203592 was broadly visible from route collectors and not a one-peer private footnote.

The individual prefix views line up. RIPEstat showed 185.128.116.0/22 announced by AS203592 at https://stat.ripe.net/data/prefix-overview/data.json?resource=185.128.116.0/22 and 94.198.185.0/24 announced by AS203592 at https://stat.ripe.net/data/prefix-overview/data.json?resource=94.198.185.0/24. It also showed the IPv6 aggregate 2a0c:2c0::/29 at https://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0::/29 and the more specific 2a0c:2c0:dd80::/44 at https://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0:dd80::/44. The IPv6 more-specific relationship matters because it hints at segmented IPv6 use rather than a single undifferentiated allocation.

RPKI is also aligned. RIPEstat returned valid for AS203592 and 185.128.116.0/22 at https://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=185.128.116.0/22, valid for 94.198.185.0/24 at https://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=94.198.185.0/24, valid for 2a0c:2c0::/29 at https://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0::/29 and valid for 2a0c:2c0:dd80::/44 at https://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0:dd80::/44. RPKI validity does not prevent a rack failure, but it reduces one class of routing failure: strict networks are less likely to reject these origins as invalid.

The RIPE Database also shows administrative continuity behind the prefixes. The 185.128.116.0/22 WHOIS view at https://stat.ripe.net/data/whois/data.json?resource=185.128.116.0/22 shows netname DE-CLOUDANDHEAT-20151125, country DE, organisation ORG-CHTG1-RIPE and a route object originated by AS203592. The 94.198.185.0/24 view at https://stat.ripe.net/data/whois/data.json?resource=94.198.185.0/24 shows netname DE-CLOUDANDHEAT-20081029, country DE and a route object originated by AS203592 after a January 2026 update. The 2a0c:2c0::/29 view at https://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0::/29 shows a 2018 RIPE allocation to the same organisation and route6 objects for AS203592. The 2a0c:2c0:dd80::/44 view at https://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0:dd80::/44 is especially interesting because it is named IBH-DD8 and has a December 2025 creation date. That points to a more recent Dresden-local segment, but it still does not reveal the workloads behind it.

For a customer, the route conclusion is straightforward. AS203592 is a live network, and the public routing evidence is strong. The harder conclusion is about service capacity. Prefixes and ROAs do not tell us how many hypervisors are installed, how many tenants are active, which flavours are out of stock, where the GPU pool is physically located, or how often block storage is tested after a node failure. They answer the network-identity question. They do not answer the procurement question.

The Dresden facility and exchange record is real, but it is not the whole cloud

PeeringDB adds the clearest public physical clue. The network lookup at https://www.peeringdb.com/api/net?asn=203592 lists CLOUD & HEAT Technologies GmbH as AS203592, with a regional scope, IPv6 enabled, open peering policy, one exchange and one facility. The network entity at https://www.peeringdb.com/api/net/40650 shows the facility set as IBH Dresden C2 and the exchange set as DD-IX. The netfac endpoint at https://www.peeringdb.com/api/netfac?net_id=40650 repeats the IBH Dresden C2 association. The netixlan endpoint at https://www.peeringdb.com/api/netixlan?asn=203592 lists DD-IX, a 10 Gbps speed field, IPv4 address 193.201.151.80, IPv6 address 2001:7f8:79::3:1b48:1, route-server peer true and operational=true.

That combination is unusually useful. It places AS203592 in a named Dresden interconnection environment rather than leaving readers with only a corporate address. PeeringDB's facility record at https://www.peeringdb.com/api/fac/14039 identifies IBH Dresden C2 as an IBH connect GmbH facility in Dresden, with the public website path for housing and rackspace at https://www.ibh.de/rechenzentrum/housing-rackpace. The DD-IX exchange record at https://www.peeringdb.com/api/ix/4282 identifies DD-IX as an exchange in Dresden, lists IBH Dresden C2 and SachsenEnergieCenter Dresden in its facility set, and points to https://dd-ix.net, https://dd-ix.net/stats and https://status.dd-ix.net. The DD-IX site describes the exchange as a non-commercial platform for Dresden, built to keep local traffic local and serve the Saxony region.

The physical reading should still stay precise. PeeringDB proves that AS203592 has a listed facility association at IBH Dresden C2 and a DD-IX connection. It does not prove that all of CLOUD & HEAT's IaaS compute sits in that one facility. It does not prove the storage layout. It does not reveal whether the DD-IX port is directly cabled to customer hypervisors, a border router, a lab segment, a management network or an exchange-facing edge. It does not reveal cross-connect diversity, switch diversity, rack power feeds, generator coverage, cooling redundancy or remote-hands repair commitments.

The company itself broadens the picture beyond one PeeringDB facility. Its IaaS page says public cloud infrastructure is operated exclusively in data centres in Germany and that customer data is processed and stored in GDPR-compliant form. Its managed Kubernetes page says Kubernetes data is processed and stored in GDPR-compliant ISO 27001-certified data centres in Germany. Its 2024 SCS article at https://www.cloudandheat.com/en/news-press/strengthening-digital-sovereignty-new-ways-in-the-cloud-with-yaook-and-scs-compatibility/ discusses a Leipzig data-centre project with envia TEL, Yaook and SCS. Its 2026 certification news, surfaced from the same site, says Cloud&Heat received "Certified SCS-compatible IaaS" recognition and that the award would be presented at the SCS Summit on 21 June 2026. Those points make the footprint more than a single AS-port story, but they do not turn the whole capacity map into public knowledge.

Power and cooling are part of the physical dependency, not just a sustainability claim. The IaaS page says Cloud&Heat uses direct hot-water cooling and integration into local heating circuits to enable energy-efficient operation and server waste-heat use. The OpenStack marketplace page also describes water-cooled servers and the reuse of server waste heat. This is useful context: if the cloud is designed around heat reuse, the building plant, water loop, heat exchanger, local heat offtake and maintenance windows become part of the service dependency. A conventional data-centre customer mostly asks about power and cooling redundancy.

A Cloud&Heat customer should also ask how heat-reuse maintenance is isolated from compute availability.

The Dresden evidence therefore supports a middle statement. There is public proof of a Dresden interconnection point and public company proof of German cloud hosting. There is not enough public proof to map every customer workload to a rack, every availability zone to a building, or every GPU instance to a specific power and cooling chain. Buyers can treat Dresden as a meaningful operating centre, not as a complete infrastructure diagram.

Product evidence is stronger for OpenStack and Kubernetes than for spare capacity

CLOUD & HEAT's product pages are unusually concrete for a regional cloud provider. The IaaS page lists compute sizes from 1 vCPU / 2 GB RAM / 15 GB SSD through 8 vCPU / 30 GB RAM / 100 GB SSD, offers standard and Memory+ price families, advertises HDD block/object storage, and says storage clusters are triple-redundant Ceph clusters for entity and block storage. It also lists GPU instance classes including T4, A10, V100 and A100. That page explicitly says that a triple-replicated NVMe pool can be provided within available capacities.

That phrase is important: the company sells useful resources, but it also acknowledges that some storage class is capacity-limited.

The managed Kubernetes page is similarly specific. It describes a self-managed option on OpenStack, on-demand support, Managed Kubernetes Basic with 9/5 support and four-hour response time, and Managed Kubernetes Full Service with different support levels. Both managed tiers list deployment across multiple availability zones for high availability, API protection via VPN, GitOps-based cluster administration, load balancer service, OpenStack Cinder persistent volumes, local static and dynamic storage and network policies.

Full Service adds ingress, Certmanager, a Prometheus and Grafana monitoring stack, 24/7 cluster monitoring and alerting, and GPU instances. These are operational claims, not just slogans.

The Patron page strengthens the OpenStack side of the story. It says Cloud&Heat Patron is a ready-to-use OpenStack distribution, based on open-source lifecycle management with Yaook, with enterprise-grade components, SCS compatibility, automation, no vendor lock-in and support options. The page offers a model where the customer operates the cloud and a model where Cloud&Heat provides operation and monitoring, fault analysis, fault repair and maintenance such as updates. It mentions 9-5 and 24/7 support contract options.

This tells us that CLOUD & HEAT is not only reselling virtual machines; it sells operational knowledge around OpenStack itself.

OpenInfra sources corroborate the open-infrastructure positioning. The OpenStack Marketplace page at https://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-services lists Cloud & Heat cloud services and says the product is OpenStack Powered. The OpenInfra supporting-company page at https://www.openstack.org/community/supporting-organizations/profile/cloud-and-heat describes its technology stack as including OpenStack, Kubernetes, Yaook and Krake, and says the company contributes to Sovereign Cloud Stack efforts. The SCS Standards Forum page at https://sovereigncloudstack.org/en/about-scs/forum-scs-standards/ lists Cloud&Heat Technologies GmbH among members committed to secure cloud infrastructures and notes collaboration with the Open Infrastructure Foundation.

The customer signal is also public. The IaaS page names Scalytics, tracetronic, Nyris, elevait, alphaspeech and flow.d under customers. The managed Kubernetes page names N+P Informationssysteme GmbH and elevait GmbH & Co. KG. The homepage carries quotes from N+P, elevait and STACKIT: N+P and elevait describe Cloud&Heat as their managed Kubernetes provider, while STACKIT describes Cloud&Heat as a cloud technology partner helping with OpenStack knowledge. The OpenStack Marketplace page links to customer case studies for elevait, N+P, Nyris and flow.d. These are meaningful affected-party signals, but they are not a tenant inventory.

The installed-versus-usable distinction is where the analysis has to slow down. Installed capacity is the servers, storage, GPUs, switches, DD-IX ports, upstreams, OpenStack clusters, Kubernetes control planes and support tooling under the company's control or management. Usable capacity is the portion a customer can order, allocate, keep running, recover and leave without unacceptable downtime. Public pages show product classes, support models, customer names and technology choices.

They do not show current GPU stock, per-flavour quotas, total hypervisor count, Ceph failure-domain design, overcommit ratios, maintenance calendars, backup retention, or tested cross-zone recovery.

The "within available capacities" caveat on the NVMe storage note is a useful window into the reality of smaller cloud economics. A cloud provider can advertise a storage class and still limit that class because high-performance drives are expensive, facility power is finite, storage replication consumes raw capacity, and customer demand changes. That does not make the offer weak. It makes it physical. A buyer should translate every service line into a capacity question: how much is installed, how much is reserved, how much can be delivered this month, and what changes when demand spikes?

Upstream, support and repair risk sit below the marketing layer

The public routing policy in the RIPE Database lists AS3320, AS15372, AS6830 and AS8220 around AS203592. RIPEstat's observed-neighbours endpoint at https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS203592 saw AS15372, AS3320, AS8220 and AS213973 on 14 July 2026. RIPEstat identifies AS15372 as IBH connect at https://stat.ripe.net/data/as-overview/data.json?resource=AS15372, AS3320 as Deutsche Telekom at https://stat.ripe.net/data/as-overview/data.json?resource=AS3320, AS8220 as Colt at https://stat.ripe.net/data/as-overview/data.json?resource=AS8220, AS6830 as Liberty Global at https://stat.ripe.net/data/as-overview/data.json?resource=AS6830 and AS213973 as BCIX Management at https://stat.ripe.net/data/as-overview/data.json?resource=AS213973. This is a credible mix of local, national and commercial connectivity signals.

The caveat is that a public neighbour list is not a contract map. It does not say which path is paid transit, which path is peering, which path is backup, which prefixes are accepted where, which route filters are strict, which maintenance windows overlap, or whether customer traffic is pinned to a particular edge. It also does not prove that a Kubernetes API endpoint and an IaaS storage backend have identical network protection. The good news is that AS203592 is not publicly visible as a single-neighbour island.

The procurement question is whether the relevant customer service has enough real path diversity to survive the specific failure the customer cares about.

Facility failure is the next layer. If a workload runs in a German data centre connected to AS203592, the service depends on rack power, cooling, upstream cross-connects, switches, routers, storage networks and staff access. The PeeringDB facility for IBH Dresden C2 lists diverse serving substations=true, which is a positive facility-level clue. It still does not disclose CLOUD & HEAT's rack power design, dual-cord coverage, maintenance bypass, battery runtime, generator test history or whether a particular customer VM can be moved away from the affected facility during a local incident.

The DD-IX connection helps with local traffic exchange, but an exchange outage and a data-centre outage are different events.

Support failure is equally important. The managed Kubernetes page gives a 9/5 support tier with four-hour response time for Basic and 24/7 monitoring and alerting for Full Service. The Patron page offers 9-5 and 24/7 support contract options for operated OpenStack environments. The IaaS page promises personal, service-oriented advice from OpenStack and DevOps experts. Those are useful public commitments, but the customer still needs the contract. The page does not disclose escalation targets for storage failure, hypervisor evacuation, GPU replacement, route leak, DNS outage, abuse ticket, billing lockout or emergency data export.

The DNS evidence adds a small but useful operational clue. A DNS query during this review resolved www.cloudandheat.com through cloudandheat.com to 185.128.119.78, which sits inside the 185.128.116.0/22 prefix announced by AS203592. The same query showed mail.cloudandheat.com as MX, INWX nameservers and SPF records that include the mail host and Google. This suggests the public website is served from the company's own routed space rather than only from a large third-party CDN. That is positive for network identity, but it also means the company's public site can be affected by its own AS, web host or facility dependencies.

The customer impact path follows from the product stack. A network failure can affect public cloud reachability, managed Kubernetes APIs, load balancers, customer ingress, software distribution endpoints, and possibly the provider's own website or support surfaces. A storage failure can affect volumes and object storage. A power or cooling incident can affect hypervisors and GPU machines. A support or operations shortage can extend restoration time even if the hardware is repairable. A contract or billing failure can block changes, exports or urgent scaling.

The public material proves that the company is experienced in these domains; it does not prove every failure path has been rehearsed.

This is not a criticism unique to CLOUD & HEAT. It is the normal shape of regional cloud dependency. The provider can be more transparent, more open-source aligned and more local than a hyperscale platform, while still being subject to the same physical constraints: space, power, cooling, optics, spare parts, route filters, maintenance windows and human availability.

Data locality is a strength, but locality is not automatic recoverability

CLOUD & HEAT's strongest reader-facing promise is locality and digital sovereignty. The IaaS page says the public cloud infrastructure is operated exclusively in data centres in Germany and that data is processed and stored in compliance with GDPR. The managed Kubernetes page says data is processed and stored in GDPR-compliant ISO 27001-certified data centres in Germany. The homepage says customers can use CLOUD & HEAT's infrastructure or on-premises deployments. The SCS and OpenInfra sources frame the company around open standards, portability and digital sovereignty.

Those claims matter. A German or European customer trying to avoid opaque offshore hosting has a different risk model when the public cloud page says Germany, OpenStack and open-source stack rather than a generic global region. The SCS-related material matters for interoperability. The 2024 company article says SCS standards are meant to increase interoperability and portability of cloud applications. The 2026 certification news says Cloud&Heat received Certified SCS-compatible IaaS recognition. The OpenInfra profile says the company contributes to standards such as SCS. This is all relevant to the topic of data sovereignty and locality.

But locality should not be mistaken for recovery. A customer can know that data is in Germany and still not know whether it is replicated between Dresden and Leipzig, between two Dresden rooms, across two availability zones in one building, or inside one storage cluster with failure domains. The managed Kubernetes page says deployment across multiple availability zones for high availability, but it does not define those zones publicly.

The IaaS page says triple-redundant Ceph clusters and an optional triple-replicated NVMe pool within available capacity, but it does not disclose whether replicas are rack-local, room-local, building-local or campus-separated. The public pages do not show backup location or restore history.

This matters for customers with compliance obligations. If a workload requires German storage, CLOUD & HEAT's public pages support the starting claim. If the workload requires a particular German state, power zone, availability-zone separation, backup segregation, air-gapped export or regulated-sector continuity plan, the public pages are not enough. The customer should ask for a statement of data location, subprocessors, backup location, storage-replication scope, staff access, maintenance windows and tested restoration.

If the workload uses managed Kubernetes, the customer should also ask where the control plane, etcd, persistent volumes, image registry, monitoring data and logs live.

The migration path is clearer because of the technology choices. OpenStack, Kubernetes, Cinder volumes, Ceph-backed storage, GitOps and SCS compatibility can all reduce lock-in if they are implemented with export rights and tested tooling. A customer can run infrastructure-as-code, maintain external backups, keep DNS under its own control, containerise applications and prepare a destination OpenStack or Kubernetes environment. But the public pages do not promise that every image, volume, snapshot, entity bucket, floating IP, load balancer or GPU workload can be exported quickly.

Standard technologies make migration possible; they do not make it automatic.

The right conclusion is therefore mixed. CLOUD & HEAT has a credible sovereignty story because it combines German hosting, OpenStack, Kubernetes, SCS work and local interconnection. The same story must be tested at the service boundary: which service is German-hosted, which part is on-premises at a customer, which part depends on IBH or DD-IX, which part depends on third-party mail or DNS, and which part can move during a provider outage? Sovereignty is not only about country. It is about control during stress.

Who is affected if cnh-primary fails?

The first affected group is public cloud and IaaS customers. The IaaS page names customers including Scalytics, tracetronic, Nyris, elevait, alphaspeech and flow.d. It sells compute, GPU and storage resources and positions the cloud for German data protection and digital sovereignty. If AS203592 or the relevant facility path fails, customer virtual machines may remain powered but become unreachable. If the storage layer fails, data availability and volume attachment become the issue. If capacity is exhausted, the customer may be unable to scale even though existing instances keep running.

The second group is managed Kubernetes customers. The managed Kubernetes page names N+P Informationssysteme GmbH and elevait GmbH & Co. KG. It describes API access over VPN, OpenStack Cinder persistent volumes, load balancers, monitoring, ingress, Certmanager and multi-zone deployment. If the provider's cloud layer fails, Kubernetes may reschedule pods but still lose volumes, ingress or external reachability. If the control plane or VPN path fails, developers may lose management access. If the monitoring stack is part of the provider's full-service offer, incident visibility can degrade along with the service itself.

The third group is customers using CLOUD & HEAT as an OpenStack operations partner rather than as a host. The homepage quotes STACKIT saying Cloud&Heat supports development and expansion of cloud infrastructure with OpenStack know-how. The Patron page sells OpenStack distribution, installation, commissioning, operation, monitoring, fault analysis and updates. A failure in AS203592 may not directly take down a customer-operated cloud, but a support outage can still matter during upgrades, incidents or emergency changes.

Consulting and managed-operation customers are affected through staff availability, remote access, documentation and escalation, not necessarily through cnh-primary routes.

The fourth group is regional networks and local traffic entities. The PeeringDB and DD-IX evidence places AS203592 at DD-IX in Dresden. A local exchange path can improve regional latency and resilience when it works; it can also become a dependency if customers assume local traffic will stay local. DD-IX itself is a broader exchange with multiple entities and facilities, so a CLOUD & HEAT problem is not a DD-IX problem by default. But customers using services close to Dresden should monitor both AS203592 and DD-IX status because the local interconnection path is part of the performance story.

The fifth group is the provider's own public presence. DNS placed www.cloudandheat.com inside 185.128.116.0/22. If the same network or hosting stack supports the company's public site, an infrastructure incident may make product pages and some customer entry points unavailable at the moment customers need information. The public DNS evidence does not prove the support ticket system is on the same stack, and the SPF record includes Google, so mail may have a different dependency path. Still, public communications should be part of customer due diligence: where is the status page, what happens if the main website is unavailable, and which emergency contacts remain reachable?

This is why affected-region language should be conservative. The assignment marks the region as Global because cloud and hosted services are reachable globally and the directory category is global cloud service. The strongest operating region in public evidence is Germany, especially Dresden and Saxony, with a documented DD-IX connection and German data-centre claims. Customers outside Germany can still use the services, but the physical dependency is not global in the hyperscale sense. It is a German cloud and cloud-technology provider with global reachability.

Redundancy proof is good at the network edge and incomplete at the service layer

There are several positive redundancy signals. AS203592 has four observed neighbours in RIPEstat, not one. It has public routing visibility across all observed RIS peers for IPv4 and IPv6 at the query time. It has RPKI-valid origins for all four observed prefixes. PeeringDB shows route-server participation at DD-IX. The managed Kubernetes page promises multi-availability-zone deployment for high availability. The IaaS page mentions triple-redundant Ceph clusters and a triple-replicated NVMe option. The Patron page offers operation and monitoring contracts, including 24/7 options.

The gaps are equally important. Public routing visibility does not disclose traffic engineering. PeeringDB's 10 Gbps DD-IX port does not disclose utilisation or failover. RPKI validity does not prove route-change readiness. "Multiple availability zones" does not define blast-radius separation. "Triple-redundant Ceph" does not state replica placement. "24/7 monitoring" does not reveal response staffing, escalation authority or restoration targets. ISO certificates and OpenStack Powered status show process and technology posture, but they are not incident records.

A buyer should not translate these public claims into a blanket high-availability guarantee.

The strongest practical redundancy proof a buyer can request is not a brochure. It is a tested recovery run: take a representative VM, volume, entity bucket, Kubernetes workload and database; simulate a zone failure; measure restore time; test DNS change; export images and volumes; rebuild in a second provider or customer site; and verify application-level consistency. For Kubernetes, ask how etcd, persistent volumes, ingress controllers, load balancers and registry dependencies recover. For OpenStack, ask how Nova, Neutron, Cinder, Glance, Keystone, Ceph and external DNS behave when a storage node, hypervisor, router or facility link fails.

Migration proof should also be product-specific. An IaaS customer needs image export, volume snapshot/export, entity data transfer, address-change planning and quota release. A Kubernetes customer needs manifests, Helm charts, GitOps repositories, secrets handling, persistent-volume migration and external backup. A GPU customer needs alternate hardware availability and driver compatibility. An on-premises Patron customer needs documentation, runbooks, update paths and rights to keep operating if support changes. These are different tests, and public pages do not answer all of them.

The company is helped by its open-source choices. OpenStack and Kubernetes reduce some lock-in compared with proprietary-only platforms. SCS compatibility is designed to increase interoperability and portability. Yaook and Tarook point toward automated lifecycle management. But the value of open standards appears only if the customer controls its configuration, backups, credentials and build instructions. Open source is not a substitute for exit planning. It is the foundation for a better exit plan.

The final dependency grade

cnh-primary CLOUD & HEAT Technologies GmbH should be upgraded from the initial "thin footprint" suspicion. The public evidence is not thin. AS203592 is live. RIPE shows current announcements, valid origins and German number resources. PeeringDB shows a Dresden facility and DD-IX connection. The company site sells IaaS and managed Kubernetes with meaningful technical detail. OpenStack and OpenInfra sources corroborate the company's role in open cloud infrastructure. SCS-related sources support the sovereignty and interoperability story. Customer references are visible.

The downgrade is not about existence. It is about resilience proof. Public evidence does not disclose total installed compute, GPU stock, storage raw capacity, tenant count, per-zone design, rack count, facility-contract terms, power topology, remote-hands procedures, backup location, restore history, incident history, exact support staffing or tested customer exits. The IaaS page's "within available capacities" language is a helpful reminder that usable capacity is finite. A buyer should treat every public capacity phrase as an invitation to verify stock, quotas and recovery paths.

The most useful grade is split. Network identity and route evidence: Strong. Product and customer evidence: Strong. Facility and local interconnection evidence: Medium-strong, because Dresden and DD-IX are visible but the whole cloud footprint is not publicly mapped. Hosted-capacity resilience evidence: Medium, because public pages make concrete availability, support and storage claims, but they stop short of hard proof. Migration evidence: Medium, helped by OpenStack, Kubernetes and SCS, but dependent on contract terms and customer preparation.

The practical test is whether a customer can turn these public strengths into operational control. A buyer that treats Cloud&Heat as a strategic German cloud provider should ask for a current capacity statement, not only a service catalogue: available CPU, memory, GPU, block storage, object storage, backup storage and network quota by site or availability zone.

It should ask whether a new virtual machine can be provisioned during a partial storage event, whether a Kubernetes cluster can be rebuilt without provider-held secrets, whether floating IPs can be reassigned during router maintenance, whether entity data can be exported without throttling, and whether support can execute emergency changes when the public site or a peering path is impaired. Those are ordinary questions for serious hosted capacity. They do not weaken the company story; they make the strong public evidence usable.

For monitoring, track AS203592, 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29, 2a0c:2c0:dd80::/44, the DD-IX port, the cloudandheat.com site, and public status or support paths. For procurement, ask for facility statements, availability-zone definitions, route-diversity evidence, support response terms, backup and export proofs, and a tested migration plan. The company has credible infrastructure. The decision point is whether the specific service a customer buys has enough usable capacity and enough rehearsed recovery to survive the physical failures that all hosted capacity eventually meets.