Spidernet Cloud Solutions sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Spidernet's website markets several forms of business hosting, but it names no data-centre building, facility operator, cloud platform, hardware configuration, power topology, carrier set, service-level commitment or public incident history. The offer is visible; the operating design is not.
• APNIC registered Spidernet's AS154632 on 17 April 2026 and allocated 162.4.2.0/23, or 512 IPv4 addresses, on 20 April. On 12 July AS154632 originated no routes, while 162.4.2.0/24 was globally visible through Go2Cloud Solutions' AS151988. The other half, 162.4.3.0/24, was not visible.
• Every sampled public path to the active Spidernet prefix ended AS18229 AS151988: CtrlS immediately upstream of Go2Cloud, which originated Spidernet's block. This proves reachability through that chain, not physical route diversity, spare bandwidth, a second site or a direct commercial relationship of any particular form.
• The public sales pages were last substantially assembled in 2021 and repeatedly describe another company, Surchi Infotech. They provide generic service descriptions rather than current specifications, prices, backup terms, restoration targets or migration procedures.
• The evidence grade is Weak. A buyer should require a named hosting location, contracting entity, facility and network operators, tested recovery points and times, backup ownership, support escalation, maintenance rules, data-export procedures and a second failure domain before putting an irreplaceable workload on the service.

A cloud catalogue without an infrastructure map

Spidernet Cloud Solutions presents a familiar small-business hosting proposition. Its navigation lists cloud database hosting, email hosting, cloud ERP, file hosting, Tally hosting, website hosting and server maintenance. The home page also offers software and application development. Taken at face value, this is not one product but a stack: compute, storage, databases, messaging, business applications, public web delivery and human support.

Each layer has a physical cost. A hosted database occupies memory, processor time and durable storage. Email needs storage, filtering, reputation management and reliable DNS. A Tally or ERP session needs a server, a software entitlement, stable latency and a way to reconnect staff after a failure. A website needs addresses, routing, web servers and certificates. All of them ultimately depend on powered hardware in a data centre, cross-connects to upstream networks, replacement parts and people authorised to repair or move the service.

Spidernet does not publish that underlying map. None of the service pages identifies a city of hosting, a facility, a rack operator, a hardware platform, a storage architecture, a hypervisor, an availability zone, an upstream carrier or a disaster-recovery site. The contact page gives a Karol Bagh office address, one telephone number and an email address. It does not say that customer servers are installed at that address, and an office address must never be mistaken for a data-centre location.

The distinction is not pedantic. If Spidernet leases virtual machines from another cloud, rents dedicated servers, colocates its own hosts, resells a partner's instances or manages equipment owned by customers, the answer changes who controls every repair. It changes who can replace a failed drive, who can reroute traffic, who owns backups, who receives an incident ticket, who authorises emergency access and who remains liable when one supplier blames another. The public pages do not choose among those operating models.

Cloud abstraction can make capacity appear detached from place. The NIST definition of cloud computing is explicit that the abstraction still rests on a physical layer of server, storage and network resources. It also notes that customers may know location only at a higher level such as a country, state or data centre. Spidernet's pages do not consistently provide even that higher-level placement for the services on offer.

The first finding is therefore modest but important: Spidernet has a real service catalogue and a reachable business contact, yet the catalogue cannot be converted into an inventory of operating assets. A prospective customer can see what the company wants to sell. It cannot see where the service runs, how much capacity is commissioned, or which components are shared.

The public identity needs a signed contract, not a name match

The strongest current identity record comes from the regional internet registry. APNIC's record for AS154632 names Spidernet Cloud Solutions, lists the Karol Bagh address used on the company website, and gives the same telephone number. It names Lalit Jain as the administrative and technical contact and uses email addresses at spidernet.net.in. That alignment makes the website and APNIC organisation a coherent operating identity.

A similarly named legal entity also appears in Indian company-information services. ZaubaCorp's profile records Spidernet Cloud Solutions LLP, number AAQ-6356, as incorporated in Delhi in September 2019. But the profile gives a Pitampura registered address and designated partners Kumar Roshan and Jatin Kumar. Those details do not match the Karol Bagh address and Lalit Jain contact in APNIC's records.

The shared name is a signal, not proof that the LLP is the counterparty behind the current hosting operation. Companies can move offices, appoint staff, trade under brands or use service addresses. Registry aggregators can lag. None of that permits a customer to assume the legal connection. The invoice, order form, tax registration and service agreement should name the contracting party, its registered number and its address. The same document should say whether that party owns the equipment, acts as a reseller or provides management over another supplier's infrastructure.

The website itself makes this need unusually acute. The About page says that "Surchi Infotech" provides the described services. The database, email, ERP, file, Tally, website-hosting and maintenance pages repeat the Surchi name. The privacy page refers to surchiinfotech.com, and the disclaimer assigns statements and liabilities to Surchi Infotech. Meanwhile, the header, contact details and domain present Spider Net.

This may be old content reused during a site build, an earlier trading arrangement or a simple editorial error. Public evidence does not settle which. It does settle what the pages cannot do: they cannot reliably identify the party promising the cloud service or the terms that govern it. A privacy statement written for another domain cannot answer who controls a Spidernet customer's personal data. A disclaimer naming another business cannot define Spidernet's liability for downtime.

The age of the material reinforces that caution. Spidernet's public WordPress record for the database page and the corresponding records for most cloud and server-support pages date their last modification to June 2021. The footer says copyright 2021. The networking records arrived almost five years later, in April 2026. A business can add infrastructure without rebuilding its website, but buyers should not treat old generic copy as a current technical schedule.

This boundary matters to recovery. During a routine month, a customer may interact only with a familiar salesperson or support engineer. During an outage, authority follows contracts. The party with the customer relationship may not control the rack; the party controlling the rack may not control the network; the address holder may not be the route origin; and the person able to replace a disk may work for a fourth company. A signed responsibility matrix is more valuable than a shared brand name.

April's number resources show an operation in transition

Spidernet's network footprint is new enough to read almost as a commissioning sequence. APNIC registered organisation ORG-SCS6-AP on 7 April 2026. It registered AS154632 on 17 April. On 20 April it allocated 162.4.2.0 through 162.4.3.255, a portable /23 containing 512 IPv4 addresses. The registry records are active and use Spidernet's domain, address and contact details.

Hours after the address allocation, one more-specific route appeared. RIPE NCC's routing-status history for 162.4.2.0/24 first observed the prefix at 16:00 UTC on 20 April, originated by AS151988. By the 12 July observation it was visible to all 326 IPv4 full-table peers in the RIPE RIS sample. A route-origin validation check found a valid authorisation for AS151988 to originate that /24.

Those are meaningful controls. Portable address space gives Spidernet an address asset that is not merely borrowed from a web-hosting account. A valid route authorisation reduces one class of accidental or unauthorised origin announcement. Global visibility means the route was not a local experiment seen by only a few networks. The active /24 was reachable as a routing destination across the measured internet.

The limitations are equally concrete. RIPEstat's view of AS154632 showed no first route, no last route, no IPv4 or IPv6 address space and no observed neighbour on 12 July. Its announced-prefix list was empty. A separate CIDR Report likewise described the ASN as not announced and not visible as a transit AS.

Spidernet therefore held an autonomous system but was not using it as a visible routing origin. Its live prefix was originated by Go2Cloud Solutions Private Limited's AS151988. The second half of Spidernet's allocation, 162.4.3.0/24, was not visible in the global table. No IPv6 prefix was associated with Spidernet's ASN in the snapshot.

This pattern can be entirely legitimate. A customer may ask its transit or hosting provider to originate portable space while it prepares its own routers. It may prefer provider-managed BGP. It may deliberately announce only the addresses it needs. It may reserve the other /24 for growth, migration or a second site. What the pattern cannot prove is that AS154632 has independent transit, that the unused /24 is installed on standby equipment, or that a second data centre can announce it after a failure.

The operating-status conclusion is thus neither "nothing exists" nor "a cloud network is fully commissioned." One Spidernet prefix was live, globally visible and properly authorised. Spidernet's own routing identity was dormant. That looks like a young or provider-dependent network arrangement, and it should be evaluated as such until a current network design shows otherwise.

One live prefix follows one visible provider chain

The active prefix also reveals where control leaves Spidernet. Hurricane Electric's AS151988 view identifies the origin as Go2Cloud Solutions Private Limited and lists 162.4.2.0/24 as Spidernet Cloud Solutions address space. RIPEstat's AS151988 snapshot showed that network originating three IPv4 /24s, with no IPv6 routes and one observed neighbour.

In the public looking-glass paths for Spidernet's prefix, the final two networks were consistently AS18229 followed by AS151988. AS18229 belongs to CtrlS. In other words, the route collectors saw Go2Cloud originating the Spidernet prefix and reaching the wider internet immediately through CtrlS. Upstream paths beyond CtrlS varied, but the edge visible nearest the prefix did not.

This is network evidence, not a declaration of ownership. BGP paths do not reveal which company owns the server, who pays for the cross-connect, what commercial agreement exists, or which building contains the router. They do not show whether a private backup session is configured but inactive. They do show that every public route sampled depended on AS151988 as origin and AS18229 as its immediate upstream.

That chain creates at least three separate failure questions. First, can Spidernet continue operating if its agreement with the origin provider is suspended, misconfigured or not renewed? Second, can Go2Cloud reach another upstream if the CtrlS connection or the relevant router fails? Third, can the customer service survive a data-centre problem even if BGP remains healthy? The route table answers none of those with redundancy.

Portfolio claims can obscure the issue. CtrlS is a substantial data-centre and network operator, and Go2Cloud publicly markets managed servers and cloud infrastructure. Their capabilities do not automatically transfer into a two-site design for Spidernet. A single virtual machine in a capable facility remains a single virtual machine. A route through a large carrier remains one visible edge unless another independently tested edge exists for the same workload.

Neither AS154632 nor AS151988 had a public network profile in the PeeringDB API for Spidernet or the PeeringDB API for Go2Cloud when checked. PeeringDB is voluntary, so absence is not evidence of bad engineering. It means there is no operator-maintained public inventory there of facilities, exchange points, traffic scale, interconnection policy or network operations contacts to corroborate a diverse footprint.

A buyer does not need Spidernet to operate a global backbone. It does need an honest service boundary. If all traffic enters through one provider at one site, the service should be priced, backed up and contracted as a single-provider service. If Spidernet claims redundant transit, it should name the second upstream, show a second BGP path, state surviving capacity and explain whether the physical entry and power path are separate.

Allocated addresses are not usable cloud capacity

The /23 allocation creates a tempting headline number: 512 IPv4 addresses. That is not the same as 512 saleable servers, 512 active customers or even 512 usable host addresses. Network and broadcast conventions, gateway assignments, infrastructure devices, abuse controls and customer subnetting reduce usable space. More importantly, only one /24 was routed in the 12 July snapshot.

Even 256 routed addresses say little about compute. A provider can place many websites behind one address, assign several addresses to one firewall, reserve addresses for future customers, or route an empty subnet. Conversely, private-addressed virtual machines may sit behind a small public edge. The number of IP addresses does not disclose processor cores, memory, storage, input/output performance or oversubscription.

The external measurements are sparse. IPinfo's page for the Spidernet prefix associated the range with the company and AS151988, but reported no hosted domains and no addresses responding to its recent ping scan. A host can intentionally block ICMP, and domain attribution can miss private or newly deployed services. These negative observations do not prove an empty network. They do reinforce that public data does not demonstrate a substantial active customer estate.

The company's own sales site is not evidence for the new block. At the time checked, spidernet.net.in resolved to 82.180.143.143, address space associated with Hostinger's AS47583, not to Spidernet's portable allocation. Its mail exchange pointed to Rediffmail Pro, and its authoritative DNS used third-party name servers. Outsourcing a corporate website, email and DNS is ordinary. It simply means those services cannot be counted as workloads proving use of the new network.

Installed capacity must be measured at several layers. At the address layer, one /24 was installed in global routing and one was not. At the routing layer, the company's own ASN was not installed as an active origin. At the server layer, no public host count or hardware inventory was available. At the storage layer, no raw or usable capacity was published. At the resilience layer, there was no evidence of a second site carrying a current copy of customer data.

Usable capacity is smaller still. A rack with 20 servers is not 20 servers of safe customer capacity if all are full, if there is no spare host for evacuation, or if storage rebuilding consumes the remaining input/output margin. A second transit circuit is not usable redundancy if it cannot carry the normal peak. A backup is not usable recovery capacity if restoration has never been timed. Spidernet publishes none of these utilisation or headroom measures.

That makes the economics opaque. Low-cost hosting often works by pooling hardware, bandwidth and support labour. Pooling is not inherently poor practice; it is the foundation of much cloud computing. The risk appears when a provider sells elasticity or resilience without retaining spare resources. Customers need to know whether their fee buys a reserved allocation, a fair-share pool, a best-effort service or a managed instance from another supplier.

Every product has a different failure path

Spidernet's service menu groups several workloads under the cloud label, but their recovery requirements differ. A generic assurance that servers are maintained cannot cover them all.

For a hosted database, the critical question is the transaction boundary. A server snapshot taken once a day may lose almost 24 hours of changes. A replicated database can reduce loss, but only if the replica is current, isolated from the same storage failure and protected from a mistaken deletion that propagates. The database-hosting page mentions PostgreSQL, MySQL and SQL Server and describes a managed service. It gives no recovery-point objective, restoration time, version support, replication design, backup retention or export format.

Email has a different dependency chain. Inbound messages rely on DNS, mail-exchange records, address reputation, anti-spam systems, storage and account authentication. A storage outage may make old mail inaccessible while new mail queues elsewhere; a DNS error may divert delivery; a compromised account may send spam and damage the reputation of shared addresses. Spidernet's email-hosting page claims dedicated servers and spam-free arrangements but provides no mailbox quota, redundancy design, journaling, retention, authentication standard, continuity method or recovery target.

File hosting concentrates business records into shared storage. Availability depends not only on disk redundancy but on metadata, identity services, permissions and an uncorrupted copy outside the primary fault domain. Spidernet's file-hosting page explains the general idea of shared cloud file systems. It does not state where files reside, whether storage is replicated, how versions are retained, how deleted material is recovered or how quickly a customer can export a large dataset.

ERP and Tally hosting add session and licensing dependencies. Staff may reach a remote desktop or application server over the public internet. If the route fails, accounting, inventory, payroll or order processing can stop even when the underlying data remains intact. A software update can be as disruptive as a hardware failure. The ERP page promises implementation and support, while the Tally page mentions standard backups and data protection. Neither specifies application versions, licence responsibility, maintenance windows, user concurrency, database ownership, backup frequency, restore tests or a route back to local operation.

Website hosting may be easier to recreate if the customer controls its code, database and DNS. It becomes difficult when the provider is the only party holding the current database, certificate keys or domain credentials. Spidernet's website-hosting page is an introduction to selecting commercial hosts rather than a schedule of Spidernet plans. It offers no storage, traffic, runtime, control-panel, backup, security or availability specification.

The shared lesson is that "backup" and "cloud" are not recovery designs. Each product needs a named unit of loss, a tested restoration sequence and a person authorised to start it. A five-minute route outage, a dead motherboard, corrupted storage, a ransomware event and termination of a supplier contract require different responses.

Racks, power and parts remain the hidden foundation

No public source identified a Spidernet-owned data centre or even the partner facility serving 162.4.2.0/24. The route through Go2Cloud and CtrlS may suggest where an interconnection exists, but BGP cannot locate the customer hardware. Geolocation databases can be useful clues and are often wrong at building level. The responsible conclusion is that physical location remains unverified.

Without a named site, power resilience cannot be assessed. A serious facility schedule would describe utility feeds, uninterruptible power systems, generator topology, fuel autonomy, maintenance bypasses and the A/B path to the ordered server or rack. It would explain whether both power supplies of a dual-corded server reach separate distribution chains. Spidernet publishes none of this, and no generic description of cloud hosting can substitute for it.

Cooling has the same opacity. A server can remain powered while throttling or shutting down because room cooling, rack airflow or a local fan has failed. High outside temperature, a maintenance error or a dense rack can remove headroom. Customers need alarms, operating ranges and a response plan tied to the actual room. No such data is public for Spidernet's offer.

Hardware stock is a particularly practical constraint for a small provider. Virtualisation can move a guest away from a failed host only if another host has compatible capacity and shared storage remains available. A dedicated server cannot be live-migrated in the same way. Replacement depends on stocked disks, power supplies, memory, controllers or a complete spare chassis. The company does not publish a hardware catalogue, stock policy or replacement target.

The server-maintenance page acknowledges that components deteriorate and that maintenance is needed to reduce downtime. Yet it frames maintenance as a generic plan and again names Surchi Infotech. It does not say whether Spidernet monitors customer servers, whether support is remote or on-site, which hours are covered, what constitutes an emergency, or how quickly a technician can reach the rack.

Repair windows are therefore a first-order service feature. "24/7" is often used to describe ticket submission, not guaranteed intervention. A customer should distinguish response time, diagnosis time, site-access time, parts-delivery time and restoration time. It should ask whether weekends and public holidays alter each target. If the facility operator provides remote hands, the contract should state how Spidernet escalates and who pays for emergency work.

Planned maintenance also needs a rule. Firmware, hypervisor, network, power and cooling maintenance can all require risk. A mature service states notice periods, blackout dates, maximum duration, redundancy during the work and the customer's right to entity. Spidernet's public site does not provide a maintenance calendar, status page or service-level schedule.

Support concentration can turn a fault into a long outage

The public contact surface is narrow: one phone number, general email addresses and a postal address. APNIC's records identify one named administrative and technical contact. This is enough to reach the organisation; it is not evidence of a staffed operations centre, an on-call rotation or separate escalation paths.

Support concentration matters because the first minutes of an incident are diagnostic. A customer needs someone who can distinguish an application error from storage failure, route withdrawal, expired licence, exhausted disk or billing suspension. If every issue begins with one general inbox, the provider needs an internal way to page the correct operator. No such structure is published.

The chain becomes longer when another network originates the address block. A connectivity incident may require the customer to contact Spidernet, Spidernet to contact Go2Cloud, and Go2Cloud to contact its facility or upstream. Each party may have its own severity definitions and evidence requirements. A traceroute supplied by the customer may not be enough; the upstream may want router logs; the facility may wait for an authorised contact. Minutes accumulate at contractual boundaries.

Provider-contract failure can be more damaging than equipment failure. If an invoice is disputed or a reseller account is suspended, servers and routes can disappear while the hardware remains healthy. Because Spidernet's prefix is currently originated by AS151988, continuity depends on the right to maintain or transfer that announcement. Portable addresses help only if Spidernet has credentials, route objects, authorisations and another willing network ready to announce them.

Billing terms are not published on the Spidernet site. There is no visible grace period, suspension procedure, data-retention period after cancellation, refund rule or promise of export access during a dispute. Customers should not infer those protections. They should obtain them in the order form, especially for accounting and email workloads that become urgent the moment access stops.

The same applies to abuse complaints. Hosting networks receive reports about spam, scans, compromised websites and unlawful content. A provider may null-route an address or suspend a server to protect the wider network. The customer agreement should state notice, investigation, emergency action and appeal. APNIC lists an abuse mailbox, which is a useful operational contact, but a mailbox alone does not define how a mistaken or malicious complaint is handled.

Recovery requires a second fault domain, not a second copy in the same rack

The public evidence supports no claim of multi-site capacity. Spidernet's unused 162.4.3.0/24 could eventually support another deployment, but an unannounced subnet is not a recovery site. Likewise, a backup on another disk in the same storage array does not survive array failure; a replica in the same room may not survive power or cooling loss; and two network sessions sharing one provider do not survive that provider's failure.

A minimum resilient design begins with fault domains. The primary and recovery copies should not share the same host, storage controller, rack power, room, access router or facility when the business impact requires protection from those failures. The network path to the recovery site should be independently reachable. Identity and DNS services needed to activate it should not depend solely on the failed site.

Recovery targets must be numerical. Recovery point objective answers how much data can be lost; recovery time objective answers how long service can remain unavailable. These are not identical to backup frequency. A backup taken every hour may still require two days to restore if the provider has never rehearsed the process or lacks spare hardware.

NIST's contingency-planning guidance recommends business-impact analysis, preventive controls, recovery strategies, an alternate site where appropriate, testing and continuing maintenance. Although written for federal information systems, the sequence is useful for any buyer. It turns "we take backups" into a set of questions about what is protected, how it returns and who proves that it works.

For Spidernet, the decisive evidence would be a dated restoration report. It should show a representative database or application restored from an isolated copy, the amount of data lost, the elapsed time, the capacity available at the recovery location and any manual steps. A network test should show the recovery endpoint reachable without the primary origin arrangement. The results need not be public, but a serious customer should be allowed to review them.

Customers should also hold their own export. Database dumps, mail archives, file-system snapshots, application configuration, DNS zones and licence records should be retrievable in documented formats. Encryption keys must be available without the failed provider. The export interval should reflect business tolerance, and restoration should be tested somewhere outside Spidernet's environment.

Data portability is an economic control as much as a technical one. A service that is cheap to enter but costly to leave can lock a customer into rising prices or weak support. The contract should state export bandwidth, fees, assistance, format, timing and deletion after exit. None of the public product pages supplies those terms.

Locality is unresolved, and some customers cannot ignore it

Spidernet is registered in APNIC's Indian region and presents a New Delhi contact. The live route passes through Indian organisations. None of those facts proves that customer data, backups or support access remain in India. An IP registration country is an administrative attribute, not a server-room coordinate. A provider can route Indian address space to another city or country, and a management team can access a server remotely.

The company's hosted-database, file, email, ERP and Tally offers can contain personal, financial and operational information. Buyers therefore need a data-location schedule listing the primary site, backup site, log storage, support-access locations and subprocessors. "Cloud in India" should mean a named country commitment, not an inference from a Delhi phone number.

India's legal position is also more specific than the broad slogan of data localisation. The Digital Personal Data Protection Act, 2023 has a phased commencement, with central obligations taking effect on different dates. It does not create a simple blanket rule that every workload must stay in India. Customers must assess the provisions in force for their role and data at the relevant time rather than relying on the word cloud.

Sector rules can be narrower and stricter. The Reserve Bank of India's 2018 direction on payment-system data requires covered system providers to store the entire data relating to payment systems in systems only in India, subject to its stated treatment of a foreign transaction leg. That requirement applies to the regulated payment context, not automatically to every Spidernet customer. A payment-system entity considering hosted databases or ERP cannot accept an unspecified location.

Operational duties are also relevant. CERT-In's cyber-security directions page links requirements affecting service providers, data centres, VPS providers and cloud providers, including incident reporting, time synchronisation, log retention and subscriber validation. The directions themselves put real importance on records and incident response. A buyer should ask which party retains the required logs, where they are stored, how clocks are synchronised and who reports an incident.

Spidernet publishes no data-processing agreement, subprocessor list, location list, retention schedule or incident-notification term for its hosting services. Its privacy page names a different domain and company. Until a current contract supplies the missing information, the data-sovereignty evidence remains weak.

What failure would look like to customers

The main failure paths are not theoretical even though no specific Spidernet outage was found in the public record.

A rack or host failure would first affect the virtual machines or dedicated servers on that equipment. Customers might see frozen sessions, unavailable websites or database timeouts. Recovery would depend on spare compute, storage integrity and a technician or orchestration system able to restart the workload elsewhere. Without a published host-evacuation design, customers cannot assume automatic movement.

An upstream or route-origin failure would make healthy servers unreachable. Because the active prefix is originated by AS151988 and visibly exits through AS18229, an error at either boundary could remove public access. A second application copy using the same prefix and path might fail at the same time. Recovery would require another announcement, another provider, a different address, DNS change or an application-level failover that customers have already configured.

A storage or backup failure could be quieter. The application may continue operating while backups stop, leaving the weakness undiscovered until a deletion or corruption event. The customer then learns that the nominal retention is incomplete or that restoration credentials are missing. The only reliable defence is monitored backup completion plus periodic restore testing.

A support failure extends every other event. If no authorised person answers, a ten-minute hardware action becomes a multi-hour interruption. If the reseller must wait on an upstream ticket, priority depends on its contract with that supplier. Customer-facing response targets should therefore include the provider chain, not merely Spidernet's acknowledgement time.

A billing or contract failure can remove service abruptly. Auto-renewal errors, disputed usage, licence expiration or an upstream account balance may trigger suspension. The customer needs a notification ladder, emergency contact, grace period and read-only export right. For financial records and email, loss of access can create legal and operational consequences before data is physically lost.

A migration failure can trap the customer during an otherwise planned exit. Database versions may differ, mail archives may be incomplete, file permissions may not map, and a Tally environment may depend on configuration or licensing held by the host. The migration path should be rehearsed while the relationship is healthy.

The people affected extend beyond the buyer's IT team. Employees may lose accounting or ERP sessions. Customers may be unable to place orders or receive messages. Suppliers may not receive purchase orders. Finance staff may miss filings or reconciliation windows. A small hosted workload can sit on a surprisingly large business process.

The evidence a buyer should require

The diligence request for Spidernet can be concise because the public gaps are clear.

First, identify the contract. The order should name the legal counterparty, tax details, governing terms, service location, facility operator, network origin provider and any cloud or hardware supplier. It should resolve the Surchi Infotech references and say which privacy and liability terms actually apply.

Second, identify the asset. The provider should state whether the customer receives shared hosting, a virtual machine, a managed cloud instance, a dedicated server or colocation. It should list processor, memory, storage class, network commitment, address allocation and oversubscription policy. For dedicated equipment, it should give replacement-part targets. For virtual service, it should state evacuation capacity.

Third, identify the failure domains. The buyer should receive the city and facility for the primary service and recovery copy, plus an explanation of power, cooling, storage and network separation. A statement that two sites exist is limited public evidence if both rely on one origin arrangement or if replication has never been tested.

Fourth, define recovery. The contract should include recovery-point and recovery-time objectives, backup frequency, retention, immutability, encryption, restore testing and customer export. Credits are useful only after the provider has explained how service returns; a small credit does not recover lost accounts or transactions.

Fifth, define operations. The schedule should give support hours, severity levels, acknowledgement and intervention targets, escalation contacts, maintenance notice, emergency maintenance rights, incident reporting and post-incident review. It should distinguish Spidernet's actions from those performed by a facility or upstream supplier.

Sixth, prove the network. If Spidernet intends AS154632 to provide autonomy, it should show when the ASN will originate routes, which upstreams will serve it and how failover will be tested. If provider-originated routing is the permanent model, it should document the transfer and emergency-origin procedure for its portable /23. IPv6 availability should be stated rather than assumed.

Finally, test exit. Before production use, the customer should export data and restore it to an independent environment. It should move a test DNS name, validate user access, measure the transfer time and record the credentials required. The exercise is the clearest way to discover hidden dependence while there is still time to fix it.

A live prefix is a start, not a resilience certificate

Spidernet Cloud Solutions has more operating evidence than its dated website alone would suggest. APNIC has issued it an organisation record, an autonomous system and portable IPv4 space. Half of that space was globally visible within hours of allocation and remained fully visible in the 12 July routing snapshot with valid route-origin authorisation. These are real steps toward a network service.

But the visible design is narrow. AS154632 was not active. One /24 was announced through Go2Cloud's AS151988, whose only observed immediate neighbour was CtrlS's AS18229. The other /24 was not routed. No public evidence established a second site, a second origin, IPv6, active hosted domains on the new block, facility-level resilience, spare hardware or tested recovery.

The commercial pages widen the claim without closing those gaps. They advertise several consequential business workloads yet provide old, cross-branded descriptions and no current service schedule. Their silence on location, hardware, support, backup and exit is not evidence that those capabilities do not exist. It is evidence that customers cannot rely on them until they appear in a signed specification and are tested.

Spidernet may be building out a new network, using a provider-originated model deliberately, or serving customers whose infrastructure is not publicly measurable. The fair evidence grade is Weak, with a positive note for the new portable resources and valid live route. The upgrade path is straightforward: publish or disclose the operating boundary, activate or explain the ASN strategy, prove a second fault domain, and show that a customer can restore and leave. Until then, the cloud offer remains dependent on unnamed racks, one visible transit chain and repair windows controlled partly beyond Spidernet's public boundary.