Summary
- cloud&more Inc is not just a consulting brand. ARIN records show an active autonomous system, AS399289, named CLAMO and registered to cloud&more Inc, plus IPv4 and IPv6 address space that appears in the company's public DNS footprint.
- The infrastructure claim is still only partly visible from the outside. Public pages say services are hosted in Canada and built around controlled infrastructure, but they do not name the data centres, rack contracts, power design, backup topology, restore objectives, spare hardware stock or second upstream that would turn a sovereignty story into a resilient hosting service.
- The sharpest failure path is not a single dramatic outage scenario. It is the ordinary chain where one rack, one upstream, one repair queue, one unpaid invoice, one provider contract or one migration gap decides whether customers can still reach mail, files, hosted applications and recovery copies.
The public claim is larger than the visible plant
cloud&more Inc's public site is direct about the product story it wants Canadian buyers to hear. The company describes itself as a provider of sovereign cloud, hosting and digital transformation for Canadian businesses, and the home page says cloud&more "designs and operates" platforms for Canadian businesses from a first cloud workspace to fully managed private infrastructure. The same site advertises Canadian hosting, PIPEDA alignment, no third-country transfer, a Hugo workspace built on Nextcloud, private compute services, custom application development, ERP and CRM, cyber security services and consulting around digital sovereignty. Those claims are visible on the company's own English home page and on the service landing pages that describe the offer around sovereign infrastructure, Hugo and business applications.
That makes cloud&more a useful infrastructure case precisely because the surface is small. Many infrastructure failures do not start at the hyperscale edge. They start with a local or regional provider that has enough control to sell a differentiated service, but not enough public evidence for a customer to understand how much of the service is owned, leased, subcontracted, monitored, stocked or recoverable. cloud&more's record has both sides.
There is an active company website, a public phone number, a Canadian office address, a privacy page, service terms, a Nextcloud partner listing, a Hugo mobile application listing and an autonomous system. There is also no public facility list, no published rack count, no published route-map history, no named data-centre operator, no announced storage platform, no published backup retention table, no public service-level schedule and no visible post-incident record.
The right reading is neither to dismiss the company nor to treat the marketing as finished proof. A provider can be young, specialised and useful without publishing the same evidence a listed carrier publishes. But when the product is hosted capacity, the hidden parts are not administrative trivia. They are the capacity. A customer's files, virtual servers, mailboxes, chat history, CRM records and recovery copies live on disks, memory, network ports, cross-connects, uninterruptible power systems and staff routines somewhere.
If those layers are not visible, the buying question shifts from "Is this Canadian?" to "What exactly has to keep working for the Canadian service to remain reachable?"
The independent company evidence is enough to identify the operator. The Nextcloud partners page lists cloud&more as a Canadian cloud services provider and says its suite includes email, web hosting, CRM, ERP, Nextcloud, video calling, chat, social media, V-Server, AI infrastructure and custom application development. The Google Play listing for Hugo Cloud names Cloud&More Inc. as the developer, gives the Moncton address, and describes a Nextcloud file access client. Digital Main Street's vendor page describes cloud&more as an Atlantic Canadian cloud solutions provider and links back to cloudandmore.ca, while reporting no reviews on that listing. These are not capacity certifications. They are identity and market-footprint signals. They support the conclusion that cloud&more is an operating business with a public product surface, not a dormant name.
The network record shows control, but it is compact
The strongest hard evidence is the network registry record. ARIN's RDAP entry for AS399289 shows an active autonomous system named CLAMO, registered on January 27, 2021 and registered to the ARIN organisation handle CLOUD-98. The same ARIN record links the ASN to cloud&more Inc and records cloudandmore.ca as a registration comment. ARIN's organisation record for CLOUD-98 names cloud&more Inc, shows Canadian contact addresses in Moncton, and lists abuse, technical, DNS, routing and network-operations contacts. The contact records were refreshed in 2025 and 2026, which is a small but useful sign that the registry identity is maintained.
ARIN also shows cloud&more associated with a single IPv4 /24, 23.172.240.0/24, and an IPv6 /36, 2602:fcc2::/36. The IPv4 block is only 256 addresses. That does not cap total customer count, because modern hosting can sit behind name-based virtual hosting, private addressing, reverse proxies and application layers. But it is a useful scale marker: the externally visible address estate is not the footprint of a very large public cloud. BGP Tools likewise lists AS399289 as active under ARIN, with one IPv4 prefix and one IPv6 prefix, and identifies GTT Communications Inc. AS3257 as the visible upstream. BGP Tools' prefix detail pages for 23.172.240.0/24 and 2602:fcc2::/36 also name AS399289 as the origin and cloud&more as the ASN name.
The current DNS footprint ties the public web and mail service back to that address space. A live DNS lookup for cloudandmore.ca resolved the web service to 23.172.240.101 and 2602:fcc2::ffff:17ac:f065, both within the ARIN blocks tied to CLOUD-98. The domain's mail exchange records pointed at mx1.cloudandmore.ca and mx2.cloudandmore.ca, and its name servers included ns.clamo.cloud and ns.clamo.tech. The public measurement page from Internet.nl for cloudandmore.ca reports the same web server addresses and also records ns.clamo.tech inside 23.172.240.0/24 and 2602:fcc2::/36. That matters because it shows cloud&more is not merely pointing a brochure site at a generic shared host under another provider's address. At least part of the company's public web, DNS and mail identity is bound to its own numbered resources.
But compact control is still compact control. The public record seen here does not show multiple upstreams. It does not show peering at an exchange. It does not show a second country, second metro or second autonomous system carrying production traffic. It does not show whether the Canadian hosting claim sits in one facility, multiple cages, a leased rack in a carrier-neutral building, an owned room, a managed colocation contract or a partner-operated cloud. A single visible upstream is not a fault by itself, especially for a smaller provider, but it is a material dependency.
If AS3257 is the only practical path in and out, then a customer buying "sovereign" capacity is also buying the repair and escalation path between cloud&more and that upstream.
The route-security picture deserves the same careful reading. Internet.nl reports that the route announcements for the web server and one of the name-server paths had an RPKI origin-validation state of NotFound, meaning that it did not find a published route origin authorisation for 23.172.240.0/24 or 2602:fcc2::/36 as originated by AS399289. It describes this as increasing the risk that routing errors or route manipulation can make the server unreachable or send traffic to the wrong network. NotFound is not the same as Invalid; it does not say another network is authorised instead. It says the cryptographic statement that would let other networks positively validate the origin was not found by that service. For a company selling data-control assurance, that is a fixable gap customers should ask about.
There is also a measurement nuance: BGP Tools' prefix pages stated, at access time, that the two cloud&more prefixes were not visible in the default-free zone, while Internet.nl reported route details for the same prefixes. Different collectors, timing and vantage points can explain that difference. The important customer lesson is not to overread one page. It is to ask for longitudinal route evidence, upstream diversity and route-authorisation status, because a static registry entry is not the same thing as stable global reachability.
Canadian hosting is a legal promise and a facility question
cloud&more's terms give customers a clearer legal hook than the marketing page alone. The Terms of Sale, last updated August 30, 2024, define "Cloud" as a combination of hardware, services, software and networking elements made available under a solution description. The terms say solutions are invoiced monthly, that customers are responsible for one dedicated email address for service notices, and that cloud&more may terminate affected solutions if a customer is delinquent on payment obligations for 30 days or more. They also say cloud&more may terminate if a change in its relationship with a third-party software or technology provider has had a material adverse effect on its ability to provide the solution. The privacy section says that if a solution description specifies the region where data will be stored, cloud&more will not move the data from that region without notifying the customer. A later customer-obligations section says that unless the solution description says otherwise, services will be provided from facilities inside Canada and customer data will be transmitted and stored inside Canada.
Those clauses are doing real work. They turn "Canadian hosting" into a contract-dependent service attribute rather than a slogan. They also reveal the dependency boundary. The promise depends on the solution description, on any reseller terms, on third-party software or technology providers, on the customer keeping account and notice details current, and on the actual facilities used. In other words, a buyer should not treat the home-page phrase as the whole deal. The binding evidence is the order form, the solution description, the service schedule and the provider list.
The privacy page adds another boundary. The Privacy Policy names cloud&more Inc at 770 St George Blvd in Moncton and identifies Norbert Demps as president and CEO. It says cloud&more only offers B2B services, and it describes data collected on the website as stored on servers operated by an external host under a data processing agreement. It also says reach measurement uses self-hosted Matomo at statistics.cloudandmore.ca and is not sent to third parties or an advertising network. The Cookie Policy, updated June 22, 2026, reinforces the same public posture: strictly essential cookies, no advertising cookies and self-hosted analytics only after consent.
There is no contradiction in a sovereignty provider using an external host for some website data if that host is inside the promised region and bound by contract. But it does show why facility evidence matters. The public pages describe "controlled infrastructure" and "Canadian-hosted infrastructure"; the privacy page refers to an external host; the ASN shows cloud&more resources; the terms allow third-party technology dependencies. A customer needs the facility map to reconcile those pieces. Which services run on cloud&more-owned servers? Which run in leased colocation? Which use a partner's platform?
Which backups leave the primary room? Which administrators have access? Which contracts create emergency rights for the customer if cloud&more loses a provider relationship?
Canadian privacy law does not make those questions optional. The Office of the Privacy Commissioner of Canada's PIPEDA brief says PIPEDA applies to private-sector organisations across Canada that collect, use or disclose personal information in commercial activity. The OPC's cross-border processing guidance says PIPEDA does not prohibit transfers for processing in another jurisdiction, but the organisation remains accountable and must use contracts or other means to provide a comparable level of protection. The OPC's cloud-computing guidance for small and medium-sized enterprises tells cloud customers to understand their privacy responsibilities, including when personal information moves into cloud services. The point for cloud&more buyers is subtle: staying in Canada can reduce some jurisdictional concerns, but it does not remove the customer's accountability or the need to inspect the actual service chain.
Hosted collaboration makes the repair window personal
The Hugo story makes cloud&more's dependency stack more concrete. The company's own site calls Hugo a sovereign collaborative platform built on Nextcloud, with file sharing, communication, project management and other workspace functions running on Canadian infrastructure. The Google Play listing for Hugo Cloud says the app lets users access files on a Nextcloud server, upload files, share files, sync favourites and use instant upload for photos and videos. The listing also gives a support email under gethugo.ca and names Cloud&More Inc. as the developer.
Nextcloud's partner page lists cloud&more among partners and includes V-Server, web hosting, email, chat, video calling, CRM, ERP and Nextcloud in the service mix.
That is a lot of daily business activity for a small provider surface. If the hosted workspace is unavailable, the affected user does not experience an abstract "cloud" issue. They experience missing files before a meeting, failed mobile upload, delayed mail, a broken chat room, a CRM screen that does not load, a project folder that cannot be shared, or a backup that cannot be restored. If the outage lands during migration, the failure becomes more awkward: the old system may already have stale data, the new system may not be fully proven, and the customer's staff may not know which source of truth is current.
The physical dependency under that experience starts in the rack. Collaboration systems need storage arrays or storage nodes, database services, application servers, caching, directory services, SSL certificates, load balancers or reverse proxies, and network paths. They need backups that are not merely local snapshots on the same fault domain. They need a way to restore individual files, full user accounts and full application states. They need enough spare capacity to survive a failed disk group, node, switch port, power feed, fibre path or hypervisor host without turning a small incident into a service-wide pause.
The public record does not show whether cloud&more has that depth. It does not show a second site, a separated backup vault, a storage immutability arrangement, a restore objective, a support escalation ladder or a customer-visible status page. The site does claim 24/7 monitoring and a response time of 24 hours; it also lists business hours on one service page as Monday through Friday, 9:00 AM to 5:00 PM Atlantic time. Those can coexist if monitoring is automated and human support is business-hours-first.
But a customer running mail, files or CRM needs to know what happens at 2:00 AM on a holiday when a storage node fails, a certificate renewal breaks, a DNS change propagates incorrectly, or an upstream session drops.
The Canadian Centre for Cyber Security's cloud assessment and authorization guidance is useful here because it frames cloud risk as shared. It says organisations must understand both the provider's controls and their own residual risk. Its defence-in-depth guidance for cloud-based services tells organisations to choose deployment and service approaches based on factors such as control, locality, service levels, scalability and security. Its recommended cyber security contract clauses for cloud services point toward contract language for incident response, continuous monitoring, data location and defined responsibilities. That is exactly the kind of detail a smaller Canadian cloud provider must turn into customer-facing commitments if it wants buyers to rely on its sovereign hosting claim for critical work.
The likely failure path is ordinary, not exotic
The core failure path for cloud&more is easy to miss because the public story is about jurisdiction and ownership. The failure path is operational.
Start with transit. BGP Tools shows GTT Communications as the visible upstream for AS399289. IPinfo's public AS page for AS399289 also showed a traceroute from Halifax reaching 23.172.240.116 through GTT before entering AS399289. If that is the only live transit path, a GTT outage, cross-connect fault, misconfiguration, billing issue or repair delay can make cloud&more services unreachable even if the servers are healthy. If a second upstream exists but is private, not visible or not carrying the same prefixes, customers still need proof. A diversity claim should include carrier names, separate physical entrances where relevant, separate routers, BGP failover behaviour, and a record of failover drills.
Then add route authorisation. Internet.nl's NotFound result for the web server and ns.clamo.tech paths does not prove traffic was hijacked or broken. It shows a missing route-security assurance that many networks now expect. In a world where more operators filter invalid routes and check origin authorisations, a provider with customer-facing hosted services should be able to say whether ROAs are published, whether max-length values are appropriate, and who is responsible for maintaining them. Route security is not just a carrier hygiene issue. For a sovereignty provider, it is part of proving that the path to the Canadian server is also governed.
Then add the rack. If the company has one primary facility, a power event, cooling incident, fire alarm, access-control problem, remote-hands delay or maintenance window can decide service continuity. If it has multiple facilities, the relevant question is whether capacity is hot, warm or cold. A second facility that stores backups but cannot serve live traffic is valuable, but it is not the same as active-active service. A second facility that can serve Hugo but not customer-specific ERP or mail is partial resilience.
A second facility that depends on the same upstream, same support person and same storage replication error is less diverse than it sounds.
Then add hardware inventory. A small /24 does not prove a small physical estate, but a small public network often correlates with a more hands-on capacity pool. Customers should ask whether critical components are vendor-supported, whether replacement disks and power supplies are on site, whether the provider has spares for network edge devices, and whether the storage design can absorb a rebuild without unacceptable performance collapse. Hardware shortages matter most when a provider promises tailored private infrastructure.
A custom environment can be excellent when the team is close to the stack; it can also be slower to replace than a commodity cloud instance if only one person knows the build.
Then add support labour. cloud&more's public materials emphasise personal, direct contact. That can be a strength for smaller organisations that do not want anonymous ticket queues. It also concentrates knowledge. If the customer depends on one relationship owner, one senior engineer or a small rotating group, the recovery plan should say who can act when that person is unavailable. The Terms of Sale require the customer to maintain a dedicated email address for notices, which is sensible, but an outage that includes mail service can break the notice path unless alternative contacts and status channels are agreed in advance.
Then add billing and provider contracts. The Terms of Sale allow suspension or termination paths for delinquent payment, acceptable-use violations, and material adverse changes in a third-party software or technology relationship. None of those clauses is unusual. They matter because many cloud failures are commercial before they are technical. A reseller dispute, licence change, failed renewal, card failure, delayed wire transfer or upstream contract change can produce the same customer-visible result as a server outage.
For critical workloads, customers should require notice periods, data-export rights, emergency payment remediation, and a transition window if a third-party dependency changes.
Finally add migration. cloud&more's anti-lock-in and ownership language is attractive, especially where Nextcloud and open-source components are involved. But portability is never only a brand promise. NIST's cloud computing definition frames cloud around network access to shared configurable resources. NIST's cloud synopsis and recommendations notes that interoperability and portability vary by service type and are often easier when the building blocks are well-defined. A customer moving from Hugo, hosted mail, CRM or private application hosting needs export formats, identity-provider handover, DNS cutover steps, encryption-key access, retention schedules and a tested restore path on another environment. Without those, "own your data" can still leave the customer waiting on the original provider during a disputed or urgent exit.
The installed-versus-usable capacity question remains open
Infrastructure sellers often talk about capability in broad terms: private cloud, V-Server, IaaS, managed services, sovereign workspaces, high-performance computing, security services and hosted applications. The useful buyer distinction is installed capacity versus usable capacity. Installed capacity is what the provider has racked, cabled, licensed and powered. Usable capacity is what remains after redundancy, maintenance, spare headroom, backups, peak demand and failure tolerance are considered.
cloud&more's public materials do not provide enough evidence to calculate either number. The website says the company operates controlled infrastructure and refers to Canada and Germany in the broader oceans group story. The Nextcloud partner listing confirms the service catalogue at a high level. ARIN and BGP records show a small visible network.
None of that shows how many compute hosts exist, how much storage is committed, how much is free, whether customer environments are dedicated or pooled, whether disaster recovery uses the same vendor stack, whether snapshots are offsite, whether backups are tested, or how much customer growth can be absorbed without new hardware procurement.
For a small Canadian buyer, that may be acceptable if the workload is low risk and the contract is transparent. For a regulated buyer, a professional-services firm, a local public body, a healthcare-adjacent service, a financial adviser, a law office or a manufacturer with operational files, it is not enough.
The minimum diligence pack should include a current architecture overview, facility location at least by metro and operator class if exact address is restricted, power and cooling redundancy at the facility level, upstream and DNS design, backup schedule, restore targets, retention policy, encryption and key-management approach, support hours, escalation path, subcontractor list, data-location commitment, and a recent restore exercise summary.
The Uptime Institute's outage research explains why this is not pedantry. Its Annual Outage Analysis 2025 says preventing outages remains strategic as modern architectures and external threats create new risks. Uptime's 2025 public summary says power remains the most common cause of serious and severe data-centre outages while IT and network-related issues are increasing. Its 2024 executive summary said power issues were consistently the most common cause of serious and severe data-centre outages, while network issues were the largest single cause of IT service outages. Those are exactly the layers that cloud&more's public pages do not quantify.
The economics are also important. A small provider can offer high-touch service because it is close to the customer, but that same closeness can hide hard tradeoffs. Keeping extra servers idle for failover costs money. Carrying spare drives, optics, power supplies and routers costs money. Buying a second transit provider costs money. Paying for offsite backup storage that is isolated from the primary stack costs money. Staffing a midnight escalation path costs money.
If those costs are not visible in the public service description, they have to appear somewhere else: in the price, in the contract, in the recovery limits or in the customer's residual risk. A low-cost sovereign workspace may be perfectly sensible for everyday collaboration, but it should not be assumed to have the same recovery envelope as a multi-region enterprise cloud unless the provider states and proves that envelope.
This is where cloud&more's small address footprint becomes a useful question, not an accusation. A /24 and a /36 can support meaningful hosted services, especially where most customers connect through domain names and application gateways. But a customer should ask how many failure domains sit behind the address space. Are web, mail, DNS, Hugo and customer applications on separate clusters or on shared hosts? Are backups reachable if the primary public prefix is filtered or withdrawn? Can a customer recover through a management network, a second site or a temporary alternate address block?
Does the provider keep enough headroom to restore a large customer while normal service continues? The public evidence does not answer those questions, which is exactly why installed capacity and usable capacity should stay separate in any assessment.
Unofficial market signals point to a narrow public footprint
The softer market signals support a downgrade in confidence, not a rejection. Digital Main Street lists cloud&more with no reviews. LinkedIn's public company snippet for cloud&more Inc showed a small follower count. The Google Play listing provides evidence of an application surface but not of install volume or enterprise adoption. A founder biography at demps.ca says cloud&more was co-founded in the 2019-2021 period to answer the need for independent Canadian cloud infrastructure and data residency, and describes later ecosystem expansion around cloud&more, Digital Sovereign, eperi partnership, secure collaboration and AI services. That biography helps explain the strategic story, but it is not independent operating evidence.
These signals suggest a company with a real niche, a founder-led posture and limited public proof of scale. They cannot prove customer count, revenue, uptime, staff depth, facility quality, backup performance or security maturity. They also cannot prove the opposite. Many smaller B2B infrastructure providers have few public reviews because their customers do not discuss hosting arrangements in public. What would settle the question is not more slogans.
It is signed customer references where appropriate, independent assurance reports, facility attestations, named upstream diversity, route-authorisation records, backup restore evidence, and a clear statement of which parts of the service are cloud&more-operated versus partner-operated.
That is why the operating status should be read as "visible but not fully evidenced." The company has maintained registry resources, public services and a partner presence. It has not published the infrastructure detail that would let a cautious customer treat its hosted capacity as transparently redundant. In a commissioning decision, that warrants continued coverage with explicit caveats. In a buying decision, it warrants a short proof phase before putting critical workloads on the platform.
Who is affected when this system fails
The first affected group is cloud&more's own customers using Hugo or other hosted services. They may be small and medium Canadian businesses, professional firms, community organisations or regional enterprises attracted by local control and data-residency claims. If files, mail, chat, CRM, ERP or hosted applications become unavailable, the outage lands in everyday work rather than in a back-office abstraction.
The second affected group is customers in migration. cloud&more's offer includes transformation, custom applications and movement away from large foreign platforms. Migration creates temporary double-dependency. During the cutover, DNS, mail flow, file synchronisation, identity, user permissions and backups can be split across old and new environments. A provider outage or support delay during that window can freeze a customer between systems.
The third affected group is downstream partners and resellers, if any are using cloud&more as an infrastructure layer under their own services. The Terms of Sale contemplate reseller purchases and customer solutions for end users, while saying solutions are not for resale unless the applicable arrangement allows it. That means the public blast radius may not always show the cloud&more name. A local consultant, software shop or managed-service firm could be relying on cloud&more capacity behind a branded customer environment.
The fourth affected group is cloud&more itself. A small provider's reputation can be damaged by a failure that a larger cloud customer might absorb as routine. Missing ROAs, an unresolved transit problem, a prolonged storage rebuild or a slow migration exit can become evidence against the entire sovereignty promise. For a company selling trust, the repair window is not merely technical downtime. It is the period in which customers decide whether "local control" gave them more agency or simply moved the dependency closer to home.
What a stronger evidence file would show
The clearest upgrade would be a concise infrastructure disclosure that avoids sensitive detail but answers operational questions. It would state whether production workloads run in one or more Canadian data centres, whether cloud&more owns or leases the hardware, which categories of subcontractor are involved, whether there is a second upstream, whether DNS is split across independent networks, whether ROAs are published for the AS399289 prefixes, how backups are separated from the primary service, and what restore objectives apply to Hugo, mail, application hosting and customer-specific environments.
The second upgrade would be a resilience proof. That could be a customer-safe summary of a recent restore exercise, a status-history page, or a table showing support severity levels and target response times. A provider does not need to publish every architecture secret to prove discipline. It can show that a file restore, a full account restore, a host failure, a router failure, a transit failover and a provider-contract contingency have each been exercised within a defined period.
The third upgrade would be a portability pack. For Hugo and Nextcloud-based services, customers should know how to export files, shares, calendars, contacts, mail, chat records, project data, identity data and audit logs. For ERP, CRM and custom applications, they should know structured data extract formats, code ownership, build dependencies, encryption-key handling and termination assistance. For hosted virtual servers or private infrastructure, they should know image-export options, IP-address portability limits, DNS handover steps and the cost of transition support.
The fourth upgrade would be route and DNS hardening. Publishing and maintaining ROAs for the visible prefixes, documenting upstream diversity, separating authoritative DNS across independent networks, maintaining a security contact file, and using modern web security headers would not prove data-centre resilience. But they would align the public edge with the trust story. Internet.nl's measurement already points to concrete, fixable items. Fixing them would be an easy way to reduce ambiguity at the edge of the service.
The conclusion: medium evidence, not medium ambition
cloud&more Inc has enough public evidence to be treated as an operating Canadian cloud-service entity with a genuine network identity. The company is present on its own site, in ARIN, on Nextcloud's partner list, in the Hugo Cloud app listing and in Canadian vendor directories. Its public DNS and web addresses sit inside its own ARIN-registered address space. Its terms make Canadian facility use a default for services unless the solution description says otherwise. Its pitch is coherent: local control, open-source-oriented collaboration, tailored business systems and a sovereignty posture for Canadian organisations.
The missing evidence is just as important. There is no public proof of multi-site production capacity, no named data-centre footprint, no published backup and restore table, no route-authorisation proof in the Internet.nl measurement, no visible second upstream, no public status history and no customer-safe capacity disclosure. That means the article title should be read literally. cloud&more sells hosted capacity, but the capacity still depends on racks, transit and repair windows that remain mostly outside public view.
For a buyer, the practical stance is staged trust. Use the public record to confirm identity and direction. Use a pilot to confirm support quality, restore behaviour, data export and migration friction. Use the contract to pin down region, subcontractors, service levels, backup retention, termination assistance and emergency contacts. Use independent measurements to monitor route security and DNS.
A sovereignty cloud is valuable only if sovereignty survives the ordinary failures of hosting: a failed power feed, a missing spare, a route flap, a bad maintenance window, a renewal dispute, a staff absence and a customer who needs their data back before the repair is complete.