Summary

  • NexGen Cloud Limited is an active UK company, incorporated on 15 April 2020, with Companies House classifying it under data processing, hosting and related activities. RIPE records separately identify NexGen Cloud Ltd as the registrant behind AS204415.
  • Hyperstack's public documentation describes deployment regions named CANADA-1, NORWAY-1 and US-1, with region-specific features rather than one uniform global platform. The same documentation says object storage is currently available only in CANADA-1, which makes backup and data-exit planning a placement issue, not just a product checkbox.
  • RIPEstat observed AS204415 as announced on 12 July 2026, with four IPv4 prefixes and no IPv6 visibility in its routing-status view. The neighbour view showed AS31169 Sognenett AS and AS35132 Enivest AS, while PeeringDB returned no public network profile for the ASN query.
  • NexGen's own service documents create useful resilience questions. The SLA page states a 100.0% uptime undertaking, but scheduled maintenance, force majeure and customer-side errors are excluded; the terms say spot virtual machines can be interrupted without a service-level guarantee and that customers remain responsible for backups and workload fault tolerance.
  • The evidence grade is Medium. NexGen has stronger public operating evidence than a thin hosting shell, but public evidence still does not prove rack-level diversity, spare GPU depth, tested restore times, independent transit contracts, or customer migration paths under stress.

The cloud interface hides a very specific geography

The most useful way to read NexGen Cloud is not as a generic cloud provider, but as a UK company selling access to a set of named GPU-cloud regions and services whose limits are visible in its own documents. The home page describes NexGen Cloud as accelerating access to GPUs on-demand and in large-scale sovereign AI cloud environments, while Hyperstack presents the customer-facing product as an AI cloud for on-demand GPU virtual machines, Kubernetes and related storage services. Those claims are meaningful only if they can be tied to a physical estate, network path and support process.

The physical estate is partly visible. Hyperstack's region guide at docs.hyperstack.cloud/docs/resource-management/regions describes regions as distinct geographic locations, each backed by a dedicated data center. It names NORWAY-1 in Vestland, Norway, CANADA-1 in Quebec, Canada, and US-1 in Texas, United States. It also says that Norway and Canada are sustainably powered regions, while the US region is a standard energy region. That is already more specific than the usual cloud marketing map: the region code is a placement claim, and placement claims create recovery duties.

The same page also makes clear that the regions are not identical. It says high-speed networking using SR-IOV is supported only for compatible virtual machines and Kubernetes clusters in network-optimized environments within CANADA-1 and US-1. The region comparison table marks high-speed networking as not available in NORWAY-1. The feature list also treats volume support and public-IP support as region features, not universal properties. A customer planning a workload on NexGen's cloud cannot simply ask whether Hyperstack has a GPU. The customer has to ask which region, which SKU, which network feature, which storage option, and which fallback remains if that region or feature is unavailable.

That is where the company's public evidence is useful. NexGen is not asking the market to trust a blank brand. There are legal records, network records, product pages, service terms, a status page and detailed product documentation. But none of those sources alone is a full resilience audit. A region guide can show intended locations; it cannot show whether two customer workloads are in independent rooms, whether enough spare GPUs are in stock, whether a failed power domain has been tested, or whether the support team can move a customer out of a constrained location before a maintenance event becomes a deadline.

The legal entity and network record point to the same operating surface

The entity trail starts in the UK. Companies House lists NEXGEN CLOUD LIMITED, company number 12556681, as active, incorporated on 15 April 2020, with a registered office at 6th Floor, 99 Gresham Street, London, EC2V 7NG, and a nature of business of data processing, hosting and related activities. Companies House warns that it does not check the accuracy of filed information, so that record should be treated as legal registry evidence, not an operational certification. Still, it anchors the company name and basic hosting-related business classification.

The network trail also points to NexGen. RDAP for AS204415 lists the AS name as nexgen, active status, and NexGen Cloud Ltd as the registrant organization. RIPEstat AS overview identifies the holder as nexgen NexGen Cloud Ltd and marks the ASN as announced at the 12 July 2026 query time. RIPEstat whois data shows import and export policy lines with AS31169 and AS35132, and created and last-modified dates of 24 June 2022 for the aut-num entity.

Those records help answer the basic identity question: this is not merely a product page divorced from a routeable edge. But they do not prove that every Hyperstack customer path uses AS204415, or that every customer workload is directly reachable through the prefixes listed in public BGP views. Cloud services often mix provider-owned addresses, facility networks, private management links, third-party model services, entity-storage endpoints and customer-managed public addresses. A buyer should therefore ask which part of the service sits behind AS204415 and which part uses another supplier's network or storage plane.

NexGen's own documents reinforce that the operating surface is not just an ASN. The general terms describe services delivered through a platform and API, customer accounts, virtual private server environments, spot virtual machines, storage-location choices, service credits, third-party payment processing and account-balance consequences. The data processing agreement describes NexGen Cloud Limited as a supplier of data processing services and sets controller-processor obligations for customer personal data. In other words, the service boundary includes legal, account, storage and support layers as well as the public route edge.

AS204415 is live, but the visible edge is narrow

The current route view is stronger than a dormant registration. RIPEstat routing status observed AS204415 with first-seen route evidence for 149.36.0.0/23 in August 2022 and a last-seen route for 94.101.98.0/24 at 08:00 UTC on 12 July 2026. It counted four announced IPv4 prefixes, covering 1,280 IPv4 addresses, and no announced IPv6 prefixes in the status response. It also reported 325 of 325 RIS IPv4 peers seeing the route set and zero of 322 IPv6 peers seeing IPv6.

RIPEstat announced prefixes listed four current IPv4 prefixes for the 28 June to 12 July 2026 window: 69.19.139.0/24, 149.36.0.0/23, 94.101.98.0/24, and 31.192.247.0/24. That is a real public edge, not an empty shell. It is also bounded. Four IPv4 prefixes are enough to matter for customer reachability, management endpoints or service ingress, but the list does not establish the size of the GPU fleet, the depth of storage, or the number of independent data-centre positions.

The IPv6 absence in RIPEstat is also worth naming carefully. It does not mean NexGen lacks all IPv6 capability anywhere in its private or supplier estate. It means that this public RIPEstat routing-status response saw no AS204415 IPv6 announcement at the query time. For customers whose own resilience plan depends on dual-stack reachability, that is a procurement question. They need to know whether workloads receive IPv6, whether IPv6 is available only in selected regions, whether the public API and storage endpoints support it, and whether incident support treats IPv4 and IPv6 as equal operational products.

Route-origin validation is another limit. RIPEstat RPKI validation for 149.36.0.0/23 returned an unknown status with no validating ROAs in the response. The same was true for the sampled 94.101.98.0/24 validation query. Unknown is not the same as invalid, and it should not be described as a route leak. It does mean the public evidence reviewed here did not show route-origin authorization for those sampled origin-prefix pairs. A customer that relies on AS204415 for production ingress should ask NexGen whether route-origin authorizations exist for every current production prefix and when unsigned routes will be signed.

Transit evidence points north, not to a full diversity proof

RIPEstat's neighbour view for AS204415 showed two visible neighbours at the 12 July 2026 query time: AS31169 Sognenett AS and AS35132 Enivest AS. The whois record includes import and export policy lines for both. On its face, that is better than a single visible upstream. It suggests that NexGen's public edge is not hanging from one observed adjacent ASN.

But the test for resilience is not simply whether two ASNs appear in a public graph. Two BGP neighbours can still share geography, facility exposure, supplier ownership, fibre routes, power dependencies or remote-hands queues. They can also be relevant to a specific regional footprint while customer services elsewhere depend on other providers, private interconnects or platform endpoints not visible through AS204415. Public BGP shows a routing relationship, not a commercial contract or a duct map.

The absence of a public PeeringDB profile adds another caveat. The PeeringDB API query for AS204415 returned no network profile in this check. That is not a fault by itself; many legitimate networks do not maintain a PeeringDB page. It does remove one common public source for facilities, exchange points, traffic policy, looking-glass links and advertised interconnection locations. In the absence of that profile, a customer has to request the same details directly: which sites carry production ingress, which routers terminate upstreams, which routes fail over automatically, and whether any exchange or carrier facility is a single point for a critical region.

The practical issue is especially important for GPU cloud. GPU workloads can be expensive to stop, checkpoint and restart. If a network path fails while training, inference or data movement is active, the customer may incur wasted compute time as well as downtime. BGP convergence can restore reachability, but it does not restore a lost training step, a corrupted local cache or an incomplete entity upload. Transit evidence therefore has to be interpreted alongside storage semantics and workload checkpointing, not as a standalone internet-health badge.

Region choice changes the failure mode

Hyperstack's region guide turns location into an explicit operational choice. CANADA-1 is listed in Quebec, NORWAY-1 in Vestland, and US-1 in Texas. The guide says a region represents a distinct geographic location backed by a dedicated data center, allowing resources to be deployed across isolated sites for improved redundancy and resilience. That language is useful because it frames regions as independent failure domains. It also means that the customer's recovery design depends on whether the service actually lets the customer use more than one region for the relevant resource type.

The same page shows why region equivalence cannot be assumed. High-speed networking is available for compatible resources in CANADA-1 and US-1, while NORWAY-1 is marked as not available for that feature. The page says region features determine which capabilities are available, including volumes and public IP addresses. A customer using the cloud for ordinary batch jobs may be able to move more easily between regions than a customer that depends on SR-IOV networking, a specific GPU family, attached volumes, or public-IP controls.

The flavor documentation reinforces this. It lists GPU families and variants with region-specific availability, such as B200, H200, H100, A100, RTX PRO 6000, L40 and RTX A6000 configurations. In the public chunk reviewed here, B200 SXM appears in CANADA-1, H200 SXM appears in CANADA-1, and H100 SXM variants appear in both Canada and the United States with different memory and storage details. Those details matter because installed capacity is not the same as usable capacity. A GPU shown as available in one region cannot be treated as an automatic replacement for a different GPU, network feature or storage layout in another region.

This is the procurement edge of cloud dependency. If a customer chooses NexGen because it needs a particular GPU and interconnect, the fallback must be tested at that same level of specificity. Can a workload move from H100 SXM in the US to H100 PCIe in Canada? Does the software tolerate a different network profile? Are images, volumes and entity data available in the target region? Is quota reserved, or would the customer compete for spare stock during the same incident that triggered a move? A cloud console can make a region switch look simple; the workload may not agree.

Storage is the clearest place where locality becomes risk

The most direct locality warning comes from Hyperstack's entity-storage documentation. The object storage page says Hyperstack object storage is S3-compatible and designed for datasets, logs, media and backup files. It also says the service is currently exclusively available in CANADA-1, that this determines where data is physically stored, and that geographic replication and regional redundancy are not currently supported. That is an unusually concrete statement, and it should shape every customer backup plan.

The implication is not that the service is unusable. S3-compatible object storage in one region can be perfectly reasonable for many workloads. The implication is that object storage should not be advertised internally by a customer as a multi-region recovery copy unless the customer builds an additional copy elsewhere. If the entity store is the place where training checkpoints, exported datasets, logs, snapshots or recovery images are meant to land, the customer should know that the Hyperstack-documented entity store is tied to one region in the public documentation reviewed here.

The ephemeral storage documentation and the terms make the other side of the storage boundary clear. GPU virtual machines may include local ephemeral storage or local NVMe-like scratch capacity for performance, but local temporary storage is not the same as durable backup. NexGen's terms for spot virtual machines are explicit that data stored on spot virtual machines is ephemeral and will be permanently lost upon termination of the spot instance, and that users are responsible for sending important data to external storage or checkpoints. The terms also say spot virtual machines may be interrupted or terminated without prior notice and without service-level guarantees.

That creates a direct customer test. If the customer runs spot workloads, can each job checkpoint to storage outside the spot instance before interruption? If the customer uses on-demand GPUs, does the application still write critical state to object storage, a shared volume, or a separate customer-controlled repository? If object storage is in CANADA-1, what happens to a workload running in US-1 or NORWAY-1 if the network path to Canada is slow, unavailable or temporarily constrained? The storage plan is where "cloud dependency" becomes a recoverability number.

The SLA is a repair promise with exclusions, not a physics waiver

NexGen's service level addendum states that NexGen Cloud Limited agrees to maintain a minimum uptime of 100.0% for the services covered by the addendum. That number is eye-catching, but the surrounding mechanics are more important than the headline. The page defines downtime as the period during which a relevant service is unavailable to the customer due to service disruptions, measured monthly, excluding scheduled maintenance periods. It excludes scheduled maintenance, force majeure events and customer-side interference or errors from the uptime calculation.

The claim process also matters. The addendum says a customer seeking a rebate must email NexGen within five calendar days of the end of the relevant monthly billing cycle with supporting information. It says NexGen reviews the circumstances and, if a claim is approved, rebates by credit to the account on a pro-rata basis, capped at the amount paid for the affected services in the billing cycle. It also says the customer may terminate without penalty if NexGen does not achieve the minimum uptime requirement for three consecutive months.

That is a reasonable commercial structure, but it is not a substitute for recovery design. A credit after the month ends does not restart a training run, repair a missed inference deadline, restore a lost local cache or move data out of a region. A customer should read the SLA as part of the commercial remedy stack, not as the operational restoration plan. The restoration plan still needs region failover, monitoring, data export, spare capacity, and a decision about which workloads are allowed to run on interruptible capacity.

The same distinction applies to scheduled maintenance. The addendum excludes planned maintenance when reasonable prior notice is given. For many customers that is workable. For customers running continuous services, maintenance windows have to be mapped against their own user commitments. Is there a multi-region design that can absorb planned work? Are public IPs movable? Can a volume be restored elsewhere? Does the customer have a tested image and IaC path outside the affected region? Without those steps, a scheduled window can still become a customer incident even if it is not downtime under the rebate formula.

Billing and account state are part of the infrastructure

Hosted capacity can fail through a finance path as well as a fibre path. NexGen's terms say customers must enter credit-card and other information and pre-pay for services in US dollars through third-party payment processors unless invoicing is separately agreed. They also say that when account credit is fully used, service will temporarily cease, with data stored for a maximum of thirty calendar days until more credit is authorised. The terms then say that after thirty days of continuous negative credit balance, NexGen has the right to delete data from storage.

That is not unusual for self-service cloud. It is also not a back-office detail. For a customer that treats NexGen as production infrastructure, billing state becomes an availability dependency. A failed card, a procurement delay, a tax-profile issue, an account lock, a quota change or an invoicing dispute can stop service as surely as a failed upstream. The remedy is not simply "pay the bill"; the remedy is to define who monitors account balance, who can approve emergency top-up, who receives billing warnings, and how critical data is exported before a commercial hold becomes a technical loss.

The terms also say users are responsible for configuration, usage, security and backup of their output. That is the shared-responsibility line in plain commercial language. NexGen may provide compute, storage, network and platform tools, but the customer still controls what is backed up, where copies are kept, which firewall rules are set, how secrets are stored and what happens when a virtual machine is reclaimed or suspended. The customer should therefore audit its own side of the dependency as hard as it audits NexGen's side.

The status and support channels should be part of the same review. Hyperstack's status page provides a public subscription surface for service updates, while product pages and docs refer to support and account access. A buyer should verify that incident notices, account access and support escalation do not all depend on the same affected service path. If the console is unreachable, can the customer still open a priority ticket? If a public-IP incident affects the workload, does the status page describe it at region and service level, or only as generic platform degradation? These details decide how fast a problem becomes diagnosable.

Data sovereignty is a feature only when the customer can prove placement

NexGen's public materials use sovereign cloud language, and the terms say customers can specify the geographic region and jurisdiction in which output is to be stored when storage options are available. The same clause says that if there is no specification or written agreement, NexGen may store output in its available locations, determined in its sole discretion. That makes data sovereignty a configuration and contract issue, not merely a brand attribute.

The data processing agreement adds a compliance layer. It says the customer is the controller and NexGen is the processor for customer personal data, refers to UK and EU data protection law, and requires security measures appropriate to risk, including confidentiality, integrity, availability and resilience of processing systems. It also describes breach notification, sub-processor rules, assistance with data-subject rights, and return or deletion of personal data after expiry or termination. Those are relevant controls, but they do not tell a technical operator exactly where every dataset, log, checkpoint or support attachment resides on a given day.

The entity-storage page supplies one concrete placement answer: S3-compatible object storage is documented as physically stored in CANADA-1 and not regionally redundant. The region guide supplies another: GPU and network capabilities vary by named region. The terms add the contract rule: customer selection matters, and in the absence of selection NexGen may use available locations. A customer with statutory, client-contract or internal-policy locality requirements should convert those public statements into written order terms and technical evidence.

That evidence should include the primary compute region, storage region, backup region, support-access geography, sub-processor list, log retention, export method and deletion process. It should also include a test: deploy a representative workload, write data, export it, delete it, and confirm that the provider can state where the primary and exported copies were held. A locality claim that cannot survive a restore test is not yet an operational control.

Hardware stock is a dependency, not a pricing footnote

The economics of NexGen's service are inseparable from finite GPU inventory. Hyperstack's pricing page advertises on-demand GPU pricing and lists models such as H200, H100, A100, L40, A6000 and newer Blackwell-generation options. The public pricing presentation says costs are billed per minute and that larger enterprise-scale contracts should contact the company directly. The docs and pricing pages together show a product built around access to scarce accelerators, not a general-purpose VM commodity.

That scarcity changes resilience. A CPU-only workload can often be restarted on a different virtual machine class with modest changes. A GPU workload may be tied to a specific memory size, interconnect, driver stack, CUDA version, storage bandwidth, network profile or reservation. If the preferred SKU is unavailable in one region, a customer may not be able to fall back to a smaller GPU without changing batch size, model sharding, inference latency or cost. If the customer's recovery plan assumes eight H100s but only single-GPU instances are available, the plan is not a plan.

The flavor docs make this tangible. They list hardware families with different vCPU, RAM, root disk, ephemeral storage, feature support and region availability. They also indicate that some features, such as hibernation and snapshots, differ by flavor. The customer cannot evaluate recovery by asking only whether "GPU capacity" exists. It needs an inventory-aware matrix: which exact flavors run the workload, which exact alternates are acceptable, which regions support those alternates, which storage moves with the workload, and which feature gaps matter during an incident.

For NexGen, this is also where a stronger public footprint creates a higher burden. The company publishes enough detail for customers to ask precise questions. That is good. It means the next step is not skepticism for its own sake, but operational proof: quota commitments, reservation terms, region-specific availability, restoration exercises, and a statement of what happens when a hardware failure, supply shortage or maintenance event affects a scarce GPU class.

Failure paths customers should rehearse

The first failure path is a regional or facility event. Hyperstack's own region language says regions are isolated sites intended to reduce the chance that power outages or network failures in one region affect others. A customer should test whether its application can actually use that isolation. Can it recreate images in a second region? Are volumes portable or region-bound? Are public IPs replaceable? Does object storage in Canada become the restore source for workloads elsewhere, and can the customer tolerate that dependency?

The second failure path is an upstream or public-edge event. RIPEstat shows AS204415 with two observed neighbours, but the public record does not prove full physical diversity. Customers should monitor RIPEstat announced prefixes, routing status, BGP.tools, Hurricane Electric, and Cloudflare Radar for independent route changes. Monitoring does not replace NexGen's own operations, but it gives the customer an outside view when routes change suddenly.

The third failure path is storage and checkpoint loss. Spot virtual machines are explicitly interruptible, and local data on spot instances can be lost. Object storage is documented as one-region in the current public docs. Customers should run a small but complete restore rehearsal: checkpoint a job, terminate the instance, restore into a fresh environment, validate the output, and time the whole process. The result matters more than the existence of a backup setting.

The fourth failure path is account and support friction. The terms can pause service after credit exhaustion, and the SLA requires timely customer claims. The buyer should know who can top up an account, who can approve an invoice, who receives incident notices, who has admin access, and who can retrieve data if the normal operator is unavailable. These are not clerical details. They are the difference between a contained outage and a day spent proving entitlement.

Monitoring turns the brand into a measurable dependency

Customers should treat NexGen's public edge and product documentation as monitoring inputs, not just procurement reading. AS204415 is visible enough to watch from outside the provider. A customer can track whether the four current IPv4 prefixes remain announced, whether a new prefix appears, whether a prefix disappears, whether the observed neighbours change, and whether route-origin validation improves from the sampled unknown state. Those observations do not diagnose every problem, but they give the customer a baseline before an incident.

The monitoring plan should be layered. At the internet layer, watch AS204415 through RIPEstat, Cloudflare Radar, BGP.tools and a customer-owned probe that reaches the actual service endpoint. At the region layer, watch the regions and features that the workload actually uses: CANADA-1 object storage, US-1 or CANADA-1 high-speed networking, public IP attachment, volume creation and snapshot or hibernation support for the selected flavor. At the workload layer, measure checkpoint frequency, restore time, entity upload completion, API availability and support response. One green ping to a public address is not enough for a GPU workload whose real failure is an un-restorable checkpoint.

The outside route monitor should also be humble. A route change can be a planned improvement, a supplier change, traffic engineering, route filtering, a collector artifact or a real incident. The value is not that the customer can run NexGen's network from the outside. The value is that the customer can ask better questions quickly: did the affected endpoint sit behind AS204415, did both observed neighbours disappear, did a public IP detach fail, did the entity store remain reachable, and did the service status page acknowledge a regional issue?

This discipline matters because the most costly failure may not be total outage. A partial failure can leave the console alive while storage is slow, leave object storage alive while GPU quota is unavailable, leave one region healthy while a customer's reserved shape is not available there, or leave the route visible while support cannot approve an urgent account change. Customers who monitor only a binary up/down state discover these layers too late. Customers who monitor the named regions, service features and data paths can decide whether to wait, fail over, checkpoint or pause before cost accumulates.

Who feels the failure

The visible buyer of NexGen capacity may be a machine-learning team, a SaaS operator, a research lab, a media company, a data vendor, a reseller or an internal platform group. The affected party during a failure may be someone else. A training job that loses local scratch data can delay a product release. An inference endpoint that depends on one GPU region can slow a customer-facing application. A billing lock can interrupt a data team's overnight batch. A public-IP issue can break customer integration tests even when the actual compute node is healthy.

That propagation is why the article treats hosted capacity as infrastructure rather than as a simple subscription. A user may never see the rack, router, upstream, entity-storage bucket, payment processor or support queue. Yet every one of those layers can decide whether the service survives a stress event. NexGen's public documentation is useful precisely because it exposes enough of the service shape to let customers model those layers: named regions, public prefixes, documented storage locality, service terms, spot-risk language and SLA mechanics.

For regulated or sovereignty-sensitive customers, the impact chain has a legal dimension. If an output is stored in a region selected by the customer, that choice needs to match policy. If the customer does not specify a location and the terms allow available locations to be used, that may be unacceptable for some datasets. If object storage is used as a recovery store and the public documentation places it in Canada, the customer has to decide whether Canada is acceptable for that data, whether another copy is required, and whether the recovery process can prove deletion or return at the end of the engagement.

For cost-sensitive customers, the impact chain is financial. Per-minute GPU billing is attractive because it lets teams use expensive hardware without owning it. It also means that failed jobs, stalled transfers and poor checkpoint discipline become direct spend. A network or storage fault can waste the hour already purchased; a slow recovery can force a second run; an unavailable preferred SKU can push the team onto a more expensive or less efficient shape. The resilience review is therefore not separate from hosting economics. It is one of the ways the customer keeps the advertised economics real.

What would raise the evidence grade

NexGen's public evidence earns a Medium grade because the company has live identity, product, network and contract signals, but the public record stops short of operational proof at the level customers need for critical dependency decisions. The most useful missing evidence is not a bigger slogan. It is specific, boring proof.

For network resilience, NexGen could publish or provide to customers a current route-origin authorization statement, a PeeringDB-style interconnection summary, facility diversity information, and a change-notification policy for production prefixes. It should separate AS204415 customer ingress from any product endpoints that use third-party networks. It should also explain whether IPv6 is available to customers and, if so, where it sits relative to the public AS204415 observations.

For regional resilience, customers need a tested map of which services exist in which regions. The map should distinguish compute, public IPs, volumes, object storage, high-speed networking, hibernation, snapshots, Kubernetes and support tooling. It should state whether each feature can be restored to a second region, whether capacity is reserved, and what data-loss window applies. The entity-storage documentation is admirably explicit about one-region availability; the recovery plan should be equally explicit about how customers avoid making that one region their only backup.

For service operations, NexGen's SLA and terms should be read together with evidence from recent exercises. A customer should ask for measured restoration times, support escalation paths, maintenance-notice examples, incident-status granularity, and account-continuity procedures. It should also ask how enterprise contracts differ from self-service accounts, because reservation, invoicing and private-cluster terms may materially change the dependency.

The practical conclusion

NexGen Cloud matters because it sits in the increasingly important layer between GPU scarcity and customer workloads. The public evidence does not support dismissing it as a paper network. It does support treating it as a real dependency that must be tested like infrastructure, not consumed like a pure software subscription.

The strongest facts are clear: a UK company record, an active AS204415 registration, current IPv4 announcements, named Hyperstack regions, region-specific networking features, a one-region entity-storage statement, public terms, a public SLA and a data-processing agreement. The weakest facts are equally clear: no public PeeringDB profile, no observed AS204415 IPv6 route in the RIPEstat status response, unknown RPKI status for sampled prefixes, no public rack-level diversity proof, and no public evidence of customer restore exercises.

For a customer, the right posture is neither alarm nor blind trust. Use NexGen where its GPU economics and region options fit the workload, but make the dependency visible. Choose the region deliberately. Keep critical data outside local ephemeral storage. Treat spot VMs as interruptible by design. Watch the public route edge. Get written locality terms where sovereignty matters. Test restore before the first incident. And remember that a cloud invoice still depends on racks, carriers, power, hardware stock, billing continuity and people who can fix the service when the interface stops abstracting the problem.