Lunanode Hosting Inc. sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Lunanode is visibly operating: its current site offers Toronto virtual machines and storage, its status page records incidents and maintenance through 2026, and AS394745 remains announced with IPv4 and IPv6 space visible in public routing data.
• The active compute footprint appears concentrated in Toronto. Lunanode closed Montreal and Roubaix in 2023 after substantial data-centre cost increases, while some older API examples still list all three regions and should not be read as current capacity.
• Resilience is available in layers, not as an automatic property. Volumes, snapshots, floating IPs, load balancers, affinity controls and downloadable images help customers design recovery, but most of those controls remain inside the same Toronto failure domain unless the customer keeps an independent copy elsewhere.
• The evidence grade is Medium. Lunanode publishes unusually useful incident detail and exposes credible network records, but it does not publicly disclose rack count, usable power, total installed compute, current storage topology, contracted repair targets, spare-hardware depth or a second active compute region.

A cloud control panel does not remove the room behind it

Lunanode's offer is recognizably a cloud service rather than a simple rented server with a login. The company's about page describes a platform based on OpenStack and KVM, with virtual machines, block volumes, live snapshots, floating IP addresses, virtual networks, startup scripts, monitoring and an API. Its virtual-machine page divides the service into general-purpose, memory-optimized and compute-optimized plans and says instances are billed hourly. A customer can create, resize, shelve, re-image, rescue and delete machines without waiting for a physical server order.

That abstraction is real and valuable. It lets a small software company rent a fraction of a server, lets an administrator convert a capital purchase into an operating expense, and lets a project release compute when it is no longer needed. It also makes the physical dependency easy to overlook. Every virtual core maps to a processor socket in a particular chassis. Every local disk maps to drives and a controller. Every block volume depends on storage nodes and the network between them. Every public address depends on a route, an edge device, an upstream and the facility's power.

Every repair depends on a person, a replacement part and access to the rack.

Lunanode's own public record makes that chain unusually concrete. The current locations page names Toronto, says the deployment is in the Cogent Toronto facility, and describes a 10-gigabit-per-second network, redundant uplinks and power-supply systems. It names dual Intel Xeon E5-2690 v2 processors and SSD RAID10 on SSD host nodes. The related infrastructure page says customers can choose local SSD disks or distributed block storage, and that VMs in the same region communicate over a 10-gigabit-per-second private network.

Those statements identify the kind of machinery beneath the service. They do not disclose how much of it is installed, how much is free, how many racks it occupies, how much power is reserved, how many host generations remain in service, or whether every workload receives the same storage and network path. The processor named on the locations page dates from an earlier server generation. That does not make it unusable; dependable older hardware can be economically sensible for low-cost hosting. It does mean a buyer should distinguish a clearly specified host type from a continuously refreshed fleet.

The cloud, in this case, is a useful operating interface over a finite Toronto deployment. Lunanode controls its customer platform, VM scheduling, storage service, network configuration and support decisions. Cogent controls important facility and upstream conditions. Hardware vendors determine part availability. The customer controls application architecture, independent backups and the decision to maintain capacity elsewhere. Reliability emerges from all four boundaries, not from the control panel alone.

Toronto is the current operating centre of gravity

The most important fact in Lunanode's present infrastructure story is geographical concentration. The current marketing pages say the cloud platform is in Toronto. More decisively, the virtual-machine API documentation says the region parameter for VM creation must be toronto. The current security-group documentation also says a new group's region must be Toronto. These are stronger current signals than an old list of place names because they describe what the provisioning interface accepts now.

Other Lunanode pages retain historical traces. The plans and regions API page includes an example response with Montreal, Roubaix and Toronto. The virtual-network API page likewise shows those three names. The snapshot feature page still describes replication between cloud locations. None of those pages, by itself, establishes that customers can provision new production capacity in Montreal or Roubaix in July 2026.

Lunanode's status history resolves the apparent conflict. In early 2023, the company said it was sunsetting Montreal and Roubaix because of substantial cost increases imposed by the data centres it used there. Customers were told to migrate virtual machines and attached volumes to Toronto by 31 January 2023, request assistance, or seek a refund if Toronto was unsuitable. A later entry said remaining VMs in the two closing locations would be migrated to Toronto. The current Toronto-only service pages are consistent with that history; the three-region API examples are best treated as stale documentation.

The closure is more than a historical footnote. It reveals a provider-contract failure path. Lunanode did not need a fire, flood or technical collapse to lose two regions. A commercial input changed: the facilities became substantially more expensive. The company responded by withdrawing capacity and consolidating workloads. That is a rational business decision, but it illustrates why rented infrastructure is never independent of leases, power prices, transit agreements and the economics of keeping lightly used capacity available.

For customers, the effect depends on architecture. A stateless application with configuration automation and an external copy of its data can be moved. A long-lived VM with local disk, a fixed address, undocumented software changes and no tested restore can become a migration project. A European customer that selected Roubaix for latency or locality could not treat Toronto as an equivalent substitute. A Montreal customer might remain in Canada but still face different latency, peering and disaster geography.

The provider offered migration assistance and credits, yet the customer still bore the application-level work and the decision about whether Toronto met its needs.

Lunanode can sell to and serve customers in many countries while operating the visible compute platform in one city. The active physical capacity shown publicly is not globally distributed. A global sales surface and a multi-region infrastructure are different things.

Low prices are produced by utilisation, standardisation and limits

Lunanode's commercial appeal is straightforward. Its live pricing page lists small general-purpose and memory-oriented VMs from a few US dollars per month, larger configurations, and compute-optimized plans with dedicated cores. It prices block and snapshot storage by the gigabyte, additional public addresses by the month and excess bandwidth by the gigabyte. The service can therefore fit personal projects, small websites, development systems, modest business applications and workloads that do not justify a large-cloud contract.

The low entry price is not the cost of a dedicated physical machine. It is the price of a share in a managed pool. The provider buys servers, rack space, network ports, addresses, storage media and staff time, then spreads those fixed and semi-fixed costs across customers. Profitability depends on occupancy and utilisation: enough customers must pay for the installed fleet, while not all customers can demand every allocated resource at full intensity at the same instant unless the plan and capacity design allow it.

Lunanode makes some of those controls visible. General-purpose and memory plans use virtual cores; compute-optimized plans advertise dedicated cores. Bandwidth is pooled by account and region, with incoming and outgoing traffic counted. The terms of service say excess bandwidth is billed and customers can elect to shut VMs down before exceeding their pool. Shelving releases CPU and memory while retaining storage and addresses at lower cost. These are not merely billing details. They are mechanisms for converting finite equipment into sellable, elastic-looking capacity.

Installed capacity and usable capacity are therefore not the same. A rack may contain a nominal sum of processor cores and terabytes, but some must be reserved for system overhead, storage replication, failed devices, maintenance, host imbalance and customer headroom. A server waiting as a spare is installed but not earning normal revenue. A nearly full rack may still have nominal unit space while lacking a safe power margin. A storage cluster can have raw disk space that is unavailable for new customer data because replication and recovery reserves consume it.

A 10-gigabit link is a port speed, not a guarantee that every VM can sustain that rate to every destination.

No public Lunanode page quantifies these margins. The live pricing page provides a catalogue, not an inventory statement. The control panel may show plan availability to an authenticated user, but public materials do not say how many instances of each type can be created, how capacity is distributed across hosts, or what threshold triggers a hardware purchase. Buyers should consequently read the prices as valid offers at the time of order, not as proof of unlimited expansion.

This economic frame also explains the 2023 region contraction. A small provider can offer inexpensive capacity because it avoids the overhead of a hyperscale estate. The same discipline can make a lightly used or newly expensive location hard to sustain. Cheap hourly compute and permanent spare geography pull in opposite directions. A customer that needs both should pay for independent capacity and test it, rather than assume the base VM price includes an idle second site.

The facility boundary is visible but only partly described

Lunanode says its Toronto location is inside a Cogent facility. Its status notices repeatedly identify Cogent as the data-centre or upstream party involved in network work. A June 2026 notice warned of possible network downtime for software upgrades on edge routers performed by the data centre. An April 2026 notice described similar maintenance. A January 2026 incident said the upstream appeared to be conducting scheduled maintenance while Lunanode investigated interruption in Toronto.

This division of responsibility matters. Lunanode can maintain servers and its own network equipment, but it cannot independently prevent a facility edge-router upgrade or restore a failed upstream device. In September 2024, Lunanode reported that its servers and network equipment remained powered and functional while external connectivity was offline because of a Cogent power problem affecting networking equipment. The racks were alive; the service was unreachable. A customer watching only VM power state would have missed the actual failure.

The public material supports claims of redundant uplinks and power-supply systems at the design level. It does not document the physical paths, carriers, breaker domains, automatic transfer behaviour or most recent failover test. Redundant server power supplies can still feed the same failed distribution path. Two uplinks can still terminate on one device or traverse one maintenance domain. A second router can still depend on the same room or upstream. Redundancy is meaningful only when its components are independent enough to survive the failure being considered.

The status history shows both the value and the limits of spares. In March 2023, Lunanode said a Toronto hypervisor suffered a disk-plane hardware failure and service was restored after disks were swapped into a spare physical server. In February 2023, a power-supply replacement was complicated because the stocked replacement did not have matching firmware, so both supplies had to be changed during a shutdown. Those entries are concrete evidence of hands-on repair capacity. They also show that owning a spare part is not the same as having an immediately compatible repair.

A 2020 Toronto outage exposes a wider failure domain. Lunanode reported a power surge at Cogent's 245 Consumers Road data centre, server restarts and a failed power distribution unit in one rack. Three hypervisors and the volume-storage system were offline at one stage. The company said it had two spare servers and would not have been able to bring all three failed systems online quickly if none of the affected machines had booted. It later discussed improved grouping of Ceph servers and more extensive network monitoring.

That level of disclosure is useful because it names the finite resource behind recovery: two spares, three affected machines and a storage quorum problem.

Public evidence does not establish that the same spare count, rack layout or Ceph grouping exists in 2026. It would be wrong to turn a six-year-old incident report into a current inventory. The durable lesson is that Lunanode's recovery has depended on on-site topology, compatible parts and the number of machines affected at once. Those constraints remain relevant to any provider, even when the exact equipment changes.

AS394745 adds real network evidence, not a complete route map

Lunanode is not only a brand sitting behind another company's anonymous address space. ARIN-derived records and bgp.tools' AS394745 page identify Lunanode Hosting Inc. as the holder of autonomous system 394745. The registration dates to December 2015, and the organisation record dates to 2014. Public routing data queried for 12 July 2026 showed the AS announced.

The route view is small but credible. RIPEstat's announced-prefixes response for AS394745 showed 172.81.176.0/21 and IPv6 prefix 2602:ffb6::/36 across the preceding two weeks. Its routing-status response reported one IPv4 prefix, one IPv6 prefix and nine observed neighbours at the query time. ARIN-derived whois data associates 172.81.176.0/21 with Lunanode, and Lunanode's current Toronto test address falls inside that block.

The IPv4 route also illustrates the provider boundary. RIPEstat's prefix overview for the Toronto test address showed both AS174, Cogent, and AS394745, Lunanode, associated with the covering 172.81.176.0/21 at the 12 July query time. A route-origin authorisation check for AS394745 on that /21 was valid. The mixed origin view is consistent with a network that has its own identity while remaining closely coupled to Cogent routing. It is not proof that all traffic follows one path, nor does it reveal private sessions or commercial terms.

Peering adds another piece. Lunanode's PeeringDB record lists an open peering policy, two IPv4 prefixes, one IPv6 prefix and a 10-gigabit operational connection at the Toronto Internet Exchange. It does not disclose traffic levels or geographic scope, and it lists no interconnection facility for the network profile. PeeringDB places the TorIX port at Cologix TOR1. That public exchange presence can shorten paths to participating networks and reduce some transit dependence. It should not be mistaken for a second compute site. A peering port at an exchange facility can be reached by transport from servers located elsewhere in the city.

The bgp.tools view showed a set of known peers including Hurricane Electric, OVH, Cloudflare, TekSavvy and others around the query date. Such lists demonstrate observed routing adjacencies; they do not establish paid upstream diversity, equal IPv4 and IPv6 reachability, contracted capacity, or failover performance. The same page showed only the IPv6 allocation as directly originated in one summary while its detailed policy view included peers for both protocols. RIPEstat showed the IPv4 /21. Differences among route collectors, timing and classification are a reason to use several views, not a reason to declare one of them a complete topology.

The public network conclusion is therefore moderate. Lunanode has its own AS, address resources, valid route-origin controls, an active TorIX port and multiple observed neighbours. That is stronger evidence than a hosting site with no visible network identity. Yet the customer-facing Toronto service has repeatedly depended on Cogent facility and upstream work, and public records do not disclose contracted transit capacity, physical path diversity, edge-device redundancy or measured failover. Network evidence supports current operation; it does not support a claim of city-independent resilience.

Storage choice changes both performance and the failure domain

Lunanode offers two conceptually different places for a VM's disk: local host storage and detachable block volumes. The volume documentation says a volume can be attached or detached, used as a boot device, retained after a VM is deleted, converted to or from an image, and snapshotted. HDD volumes are priced separately, while SSD volumes are described as Toronto-only. The about page says volume-backed VMs can use Ceph RADOS distributed storage and may be automatically evacuated after a hardware failure.

The trade-off is important. A local SSD can offer a direct and economical path, but the VM depends heavily on its host's disks, controller and filesystem. Moving the workload may require copying or transplanting storage. A distributed volume can separate data from a single compute host and make it easier to start the VM elsewhere. It also introduces a shared storage plane. If enough storage nodes, network links or power domains fail together, many volume-backed VMs can be affected at once.

Lunanode's incident history contains examples of both patterns. The July 2020 power event impaired the volume-storage system as several servers were offline. A September 2023 outage in one Toronto rack affected block storage and VMs in that rack. Local-disk incidents in November 2024 and July 2025 led to long filesystem repair periods and customer data corruption or loss on a small number of VMs. These are not evidence that one storage choice is always superior. They show that local and distributed designs fail differently.

The July 2025 entry is especially relevant to customer responsibility. Lunanode reported downtime on one Toronto SSD hypervisor, extended filesystem repair with no early restoration estimate, and ultimately the loss of data on four virtual machines due to disk corruption. It offered affected users three months of credit for downtime and twelve months of credit for data loss. In November 2024, a failing SSD and filesystem corruption left at least five VMs with corrupted disks after an extended repair. Credits can recognise harm; they do not reconstruct customer data.

The provider's terms make the boundary explicit: snapshot functionality exists, but Lunanode does not automatically back up client data and disclaims responsibility for data loss. The snapshot page says snapshots can be taken while a VM is online, used to create or re-image VMs, and downloaded from the panel. That final capability is one of the most important resilience features because a downloaded image can leave the provider's immediate failure domain.

A snapshot kept only in the same Toronto environment is still exposed to account loss, control-plane failure, facility outage and provider contraction. The page's reference to replicating snapshots between cloud locations reflects the earlier multi-region service and should not be assumed to provide current geographic separation. A buyer needs to verify what destination is available now. If Toronto is the only active region, an independent backup needs another storage provider, another site or customer-controlled media.

Snapshots also have application limits. A disk snapshot taken while a database is busy may be crash-consistent rather than transaction-consistent unless the application is quiesced or coordinates its own backup. A downloadable image can be useless if nobody tests the restore, records encryption keys, captures external services or knows how to adapt network configuration at another host. The control panel supplies useful primitives. The customer must turn them into a recovery design.

The incident record shows the actual failure paths

Lunanode's status page is one of the strongest parts of its public evidence. It identifies current and planned work, names affected hypervisors, describes some causes and often records restoration progress. The page says entries more than six months old may be purged, although a substantial history remains visible. It is not a certified uptime report, but it is more informative than generic promises of reliability.

The incidents fall into several recurring categories.

Facility and upstream network failure. In May 2026, Lunanode reported packet loss in Toronto and said the upstream had identified the cause. Planned Cogent work in April and June 2026 carried possible downtime. In September 2024, a Cogent power problem left Lunanode's powered servers disconnected from the outside world for hours. In 2023, a Toronto rack lost power after a breaker issue. These events affect many customers at once and can make healthy VMs unreachable.

Hypervisor hardware failure. The archive records failed disks, RAID controllers, power supplies, memory modules and abnormal host errors. Some outages lasted minutes; others required prolonged repair. A virtualisation platform can move or recreate a VM only if its storage, scheduler, spare compute and network path remain available. A local-disk VM is especially tied to the physical host unless data has already been copied elsewhere.

Shared storage failure. The 2020 power event and the 2023 rack outage affected block storage. Distributed storage reduces dependence on one disk or host, but a correlated power, network or grouping problem can remove enough members to interrupt the service. This is the difference between component redundancy and system independence.

Control-plane and ancillary-service failure. A 2024 domain suspension involving lndyn.com interrupted services until Lunanode moved domains away from the registrar. Another 2024 notice said a monitoring email bug sent some users notifications intended for others. Lunanode also acknowledged that when the Toronto network was offline, email alerts were not sent because its mail server was in Toronto, and recommended SMS, voice or HTTP alerts instead. An outage can therefore impair the mechanism used to report the outage.

Data corruption and extended repair. The 2024 and 2025 SSD-hypervisor incidents show that a server returning to an online state does not guarantee every guest disk is intact. Filesystem checks can take many hours, and damaged VM disks may require customer restoration. Recovery time and recovery point are separate: power may return before data is usable, and a restored service may still have lost recent writes.

Commercial location failure. Montreal and Roubaix closed because facility costs rose. This is not ordinarily shown on a technical status graph, yet it can have the largest long-term effect because an entire location disappears. Customers had notice and migration options, but they could not preserve the region merely by rebooting.

The archive should not be converted into a simplistic outage rate. It does not provide a complete denominator, the number of active VMs, the affected-customer count for most events, or a guarantee that every minor incident is posted. Older entries may be removed. Some notices contain inconsistent dates or typographical errors. The current section, for example, includes a Toronto networking heading dated 18 May 2026 with updates dated 13 May. That weakens precise chronology but not the broader evidence that packet loss and upstream intervention occurred in May.

Nor should candour be confused with poor operation. Small providers can appear more failure-prone than silent competitors simply because they describe what happened. Lunanode's entries show technicians replacing parts, moving disks, monitoring repairs and offering credits. The correct use of the record is to identify failure mechanisms and ask how they are mitigated now, not to pretend that public incident counts alone predict the next outage.

Redundancy is available in layers, mostly inside one city

Lunanode gives customers several building blocks for resilience. The floating-IP feature lets an external address move between VMs. The load-balancer service can distribute TCP, HTTP or HTTPS traffic among several machines and remove a failed member after monitoring detects trouble. Security groups and private networks support tiered applications. The VM API exposes an affinity-group option, and its response includes a physical host identifier, allowing customers to seek placement on distinct hypervisors.

Each feature addresses a particular failure. Two application servers on different hypervisors can survive one host crash. A floating address can reduce the network changes needed to activate a replacement. A load balancer can stop sending requests to an unhealthy member. Volume-backed boot can separate data from a failed compute host. Monitoring can notify an operator before a user reports the problem.

None automatically survives the loss of Toronto. Two VMs on different hosts may share the same rack, power distribution, storage cluster, edge router, facility and upstream. A load balancer in the same region can fail with its backends. A floating IP is useful only while the regional network still routes it. A volume can outlive a VM deletion while remaining unavailable during a storage-plane or facility outage. Affinity can spread compute placement without creating geographic separation.

Customers therefore need to match design to the failure they care about. For a hobby site, a snapshot and the ability to recreate a VM may be sufficient. For a business website, separate application instances, a tested database backup and external DNS control may be appropriate. For a service with strict continuity requirements, the second copy should be with another provider or in another independently operated site, with enough reserved capacity to start the workload.

The word "redundant" should always invite four questions: redundant against what, located where, controlled by whom, and tested when? Lunanode's claim of redundant uplinks may protect against a failed link. It may not protect against Cogent maintenance or a facility-wide network issue. RAID10 protects against some drive failures. It does not replace a backup and did not prevent every corruption event in the archive. Ceph replication protects against some node failures. It can still be affected when correlated power or storage members fail.

Recovery also depends on usable capacity. Automatic evacuation requires a surviving host with enough CPU and memory. Restoring from a snapshot requires enough storage and time. Moving a large image off-site depends on bandwidth. Replacing a failed host requires compatible inventory. The public record does not say how much headroom Lunanode maintains for these operations, so customers with firm recovery targets should obtain specific answers rather than infer them from feature names.

Support, billing and account state are infrastructure dependencies too

Lunanode directs customers with infrastructure problems to open a support ticket. Its monitoring service supports HTTP, TLS-certificate expiry, ICMP, TCP and DNS checks, with email, SMS, phone and webhook notifications. Those are practical tools, particularly when the alert destination is outside the Toronto service. The 2024 email incident demonstrates why an independent alert channel matters.

Public pages do not set out a general response-time or restoration-time commitment for ordinary cloud plans. The status page often shows active work, but it is not a contractual service-level schedule. There is no public statement of 24-hour staffed coverage, escalation tiers, remote-hands arrangements, priority classes or guaranteed replacement windows. This does not mean support is absent; the detailed incident updates demonstrate active intervention. It means a buyer cannot derive a firm support target from the public material.

Billing can also stop a technically healthy service. Lunanode operates on account credit. Its billing API exposes the remaining credit balance, while the terms say a low-credit email is sent at least 48 hours before credit reaches zero and that services are suspended after the balance becomes negative, with at least seven days' notice before suspension. A payment failure, outdated contact address or missed notification can therefore become an availability event.

The terms also reserve broad suspension and termination rights, describe refund handling, and state that termination releases allocated resources and deletes associated data. Customers should understand those provisions before putting irreplaceable data into a single account. Operational separation may require more than two VMs: it may require an off-provider backup, independent DNS and domain control, multiple billing contacts, monitored credit, documented access recovery and a second place to run.

Support concentration is difficult to measure publicly. ARIN and PeeringDB records name a technical contact, but a registry contact does not reveal team size or shift coverage. No reliable public evidence quantifies Lunanode's headcount, on-site staffing or support queue. The honest conclusion is not that support is necessarily thin; it is that staff redundancy and escalation depth remain unverified.

Canadian locality is useful, but it is not a complete sovereignty answer

Toronto hosting can be attractive to customers that want their primary VM disks and volumes in Canada. Lunanode is a Canadian company in ARIN records, and its live service pages identify Toronto as the current compute location. That gives a buyer more locality information than a service that merely labels a broad region.

The company's privacy policy says customer VM, volume and image contents are stored as user data and describes limits on access and disclosure. Its data privacy agreement describes Lunanode as a processor or sub-processor in relevant circumstances, permits sub-processors, and says customers choose the country where data is stored when purchasing a service. Both documents date from 2018. They remain publicly posted, but their age and references to country choice should be reconciled with the current Toronto-only provisioning evidence.

Data location has several layers. The primary disk may be in Toronto while monitoring messages, payment records, support communications or customer-managed backups use other providers and jurisdictions. A customer can access Toronto-hosted data from anywhere. A sub-processor may participate in delivering part of the service. Domain registration, payment processing, SMS delivery and upstream connectivity have their own operator boundaries. Canadian storage is therefore a meaningful fact, not a complete legal or operational conclusion.

The 2023 closures also show why locality must be monitored over time. Roubaix once offered a French location; Montreal offered a second Canadian city. When both closed, customers had to accept Toronto or move away. A contract or compliance assessment should identify the approved location, notification expectations, export process and required response if that location is withdrawn.

Portability is comparatively tangible on Lunanode. Snapshots can be downloaded. Customers may upload their own images and installation media. Volumes can be converted to images. Floating IPs can be detached inside the platform, although the address generally cannot follow the customer to an unrelated provider. These controls can reduce lock-in if the customer actually exercises them. An image format, encryption key, DNS zone, configuration record and recent independent data backup are more useful than a theoretical export button discovered during an emergency.

A serious locality assessment should therefore ask where each data class resides, who can access it, what legal terms apply, how backups leave Toronto, how quickly the customer can retrieve a full copy, and whether that copy starts successfully elsewhere. Lunanode's public documents provide a starting point. They do not answer the whole assessment for every workload.

What would raise the evidence grade

Lunanode's public footprint is not empty. It is stronger than a cursory reading of its modest marketing presence might suggest. The company has live product and pricing pages, current Toronto provisioning instructions, detailed status notices through 2026, active address space, AS394745, IPv4 and IPv6 announcements, a TorIX presence and a long-running control surface. These are credible signs of an operating small cloud provider.

The grade stops at Medium because the most consequential resilience facts remain undisclosed. Public material does not state the number of active racks or hypervisors, current server generations across the fleet, contracted power, available power margin, storage-node count, replication layout, spare-host count, replacement-part inventory, transit contracts, physical route diversity, support staffing, customer count, utilisation, recovery objectives or restore-test results. It shows one active compute city and no verified second site for customer failover.

Evidence that would raise the grade need not expose sensitive details. Lunanode could publish a current architecture note that distinguishes facility, rack, host and storage failure domains; confirm whether customer workloads occupy more than one power domain; identify the classes of upstream diversity; state how affinity placement maps to racks; describe current volume replication and evacuation behaviour; and provide aggregate availability and incident metrics. A current backup and data-location statement could replace ambiguity left by 2018 documents and historical multi-region instructions.

For a customer, the immediate questions are practical. Is the VM on local disk or a volume? Are replicas on distinct hosts and racks? Does the application survive a host failure? Is the backup outside Lunanode and outside Toronto? Can it be restored on another hypervisor or another provider? Does monitoring still alert when Toronto cannot send email? Who watches account credit? What happens if a region is withdrawn? How much data must cross the network during recovery, and how long did the last test take?

Lunanode's value proposition does not require it to resemble a hyperscale cloud. A compact Canadian provider can be a good fit when price, directness, hourly billing and Toronto locality matter. The evidence supports that narrower proposition. It does not support treating low-cost hosted capacity as locationless or self-healing by default.

The central infrastructure fact is simple: Lunanode sells a flexible interface to real machines in a real Toronto facility. Its own history shows repairs that depended on spare servers, compatible power supplies, filesystem checks, storage quorum, upstream technicians and customer migration. Buyers can use the platform's snapshots, volumes, load balancers, floating addresses and monitoring to build resilience. The last layer still belongs to them: keep an independent copy, reserve somewhere else to run, and test the path before a rack, route, account or commercial contract forces the move.