Sovy Cloud Services sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Sovy Cloud Services is tied to AS401110, registered in ARIN as AS-SOVYCLOUD, with Sovy Cloud Services as the registrant at 25 First Ave. SW STE A, Watertown, South Dakota, according to the ARIN RDAP autonomous-system record and the ARIN entity record for SCSL-51.
• The active-network test is negative. RIPEstat's AS overview marks AS401110 as not announced, its announced-prefixes view returns no current prefixes, and its routing-status view shows zero IPv4 and IPv6 visibility as of 2026-07-12.
• The historic footprint was real but short-lived. RIPEstat's routing-history view shows AS401110 originating a handful of IPv4 /24s and one IPv6 /48 between late May 2024 and mid-February 2025; those routes do not support a current customer-capacity claim.
• Sovy's own public service surface has weakened. The PeeringDB network record lists zero IPv4 prefixes, zero IPv6 prefixes, zero exchange LAN entries and five facilities, while the sovy.cloud domain RDAP record shows expiration on 2026-05-03 and status values including server hold, redemption period and pending delete.

The cloud promise is a physical promise

The central question for Sovy Cloud Services is not whether a company name can be found in an internet registry. It can. The question is whether a customer who buys hosted capacity from that name is buying something that still has functioning racks, route authority, address continuity, support coverage, power, spare parts and a workable exit path.

Cloud language makes the service feel abstract, but small-provider hosting usually fails in concrete places: an address block is withdrawn, a router session goes away, a facility access request waits in a queue, a domain expires, a support mailbox stops answering, or a customer finds that the backup they assumed was included was actually their own responsibility.

That distinction matters more here because Sovy has two public faces that do not line up cleanly. The identity face is visible. ARIN lists AS401110 with the name AS-SOVYCLOUD, status active, registration on 2024-05-29 and a last-changed date of 2024-05-30. The same ARIN record nests the registrant entity SCSL-51, whose name is Sovy Cloud Services and whose address is in Watertown, South Dakota. The operational face is much thinner. Public route observation shows no current announcement by AS401110. The Sovy domain is not in ordinary serving condition. PeeringDB lists no current prefixes and no exchange LAN entries. The public contact layer in ARIN includes unvalidated point-of-contact remarks. A customer should read that combination as a warning about operating continuity, not as a mere paperwork detail.

The safe starting point is therefore narrow. Sovy Cloud Services should be treated as a registered network name with historical BGP activity and self-reported data-centre presence, not as a proven live cloud platform. That is not the same as saying no service exists anywhere under the brand. A small provider can sell by private agreement, through resellers, through a customer portal on another name, or from infrastructure that is not obvious in public routing tables at one point in time. But a public article has to follow public evidence.

The public evidence on 2026-07-12 does not support confidence that Sovy has live customer-facing hosted capacity available from AS401110.

The company identity is visible, but it is not enough

The strongest identity evidence comes from ARIN. The AS401110 RDAP record says the autonomous system is active, names it AS-SOVYCLOUD, and associates it with Sovy Cloud Services. The SCSL-51 entity record names Sovy Cloud Services as an organization and gives the Watertown, South Dakota address. It also links administrative, technical and abuse contacts that use [email protected] and [email protected]. On paper, this is a normal minimum identity package for a small network operator.

The weakness is that identity records are not capacity records. They do not show how many servers are installed, where they are installed, whether the company owns the equipment, whether the racks are paid through a colo contract or a reseller, whether a customer can reach a support person during a fault, or whether a workload can be restored to a second site. An active ARIN ASN is a right or assignment for routing, not evidence that the route is being used today. In the same way, an address on a registry record is a contact surface, not a data-centre floor.

ARIN's contact remarks deepen the caution. In the AS record, the administrative, technical and abuse contacts are each marked with an ARIN note saying the registry attempted to validate the contact data but received no response from that contact since 2025-05-07. The phrasing should not be inflated. It does not prove that the mailbox is dead, that the phone is abandoned, or that nobody operates the network. It does prove that the ordinary public contact-validation signal is weak.

For a cloud or hosting customer, that matters because the same contact layer is where abuse reports, routing notices, peer requests, incident escalations and emergency coordination usually begin.

The PeeringDB side uses a more commercial-facing name. The PeeringDB network entry for AS401110 lists the network name as sovy.cloud, the alternate name as Sovy Cloud Services, and the long name as Sovy Cloud Services LLC. It labels the network type as NSP and the scope as global. It also lists the website as https://sovy.cloud. Those are meaningful claims, but PeeringDB is a public operator-maintained directory. It is useful for peering intent and facility discovery; it is not a warranty that a rack is still powered, a route is still active, or a support contract is still staffed.

This difference between identity and operation is the first lesson of Sovy's footprint. A buyer might see a company name, an ASN and a global scope and infer a small but functioning cloud network. The harder evidence does not support that inference without qualifications. The current public record needs to be read as a set of traces: the company registered a network identity in May 2024, it had visible routes for a period, it listed facilities, and by July 2026 the visible network and domain surfaces had deteriorated.

The current route test is negative

The cleanest operating test is whether AS401110 is visible in BGP now. On that test, the answer is negative. RIPEstat's AS overview for AS401110 shows the holder as AS-SOVYCLOUD - Sovy Cloud Services but marks the ASN as not announced at the 2026-07-12 query time. The announced-prefixes call returns an empty prefixes list for the latest two-week window, with the usual note that routes with very low RIS full-feed visibility are excluded. The routing-status call is even more direct: it shows zero IPv4 prefixes, zero IPv6 /48s, zero observed neighbours, zero IPv4 peers seeing the ASN out of 327, and zero IPv6 peers seeing it out of 322.

For a hosting company, that result is not a small detail. Customer-facing cloud, VPS, bare-metal or managed-service capacity usually needs one of several live network arrangements. The provider can originate its own address space. It can originate delegated customer or provider space. It can use upstream-addressed infrastructure while keeping the customer-facing brand separate from the route. It can sell through another platform. What it cannot do, at least not under a direct AS401110 network claim, is prove current internet-facing capacity while its own ASN has no visible current routes.

The route test also changes how to read the facility list. PeeringDB reports five facilities for the network, but no current route observation means those facilities cannot be treated as current production sites merely because they are listed. A PeeringDB facility entry can mean a real presence. It can also remain after an arrangement changes. It can represent planned service, remote interconnection, a partner handoff, a former footprint or a listing that was not later maintained.

Without current BGP visibility, current exchange LAN entries, a live website, a status page or customer-facing service pages, the facility list is not enough to lift the confidence grade.

The negative route test should not be overread either. It does not prove that every Sovy-branded service is gone. If a provider moved customers to another ASN, stopped using its own number, shifted to pure resale, or kept private services on another provider's addressing, RIPEstat would not necessarily show AS401110 as active. But that possibility does not help a buyer who is evaluating Sovy as an infrastructure dependency. It simply moves the burden to the company to disclose where the service actually runs and who controls the route, support and exit path.

The historic routes look like leased or movable capacity

Sovy's routing history is not empty. RIPEstat's routing history for AS401110 shows a burst of activity after the ASN was registered. The earliest visible items include 166.88.177.0/24 and 2a12:8fc6:4011::/48 from late May 2024. Later windows include 81.161.230.0/24 and 109.206.237.0/24 from August 2024 into February 2025, 136.0.121.0/24 from late November 2024 into January 2025, and 23.27.222.0/24 from December 2024 into January 2025. RIPEstat's routing-status view lists the last AS401110 observation as 109.206.237.0/24 on 2025-02-14.

Those historical routes are important because they show that AS401110 was not merely a dormant allocation. It did originate addresses that were widely visible for a time. But the pattern does not look like a stable cloud provider holding a durable, branded address estate. The current prefix overview for 23.27.222.0/24 shows it announced by AS49468, not AS401110. The current overview for 81.161.230.0/24 shows AS151612. The current overview for 109.206.237.0/24 shows AS16045. The current overview for 136.0.121.0/24 shows AS203545. The current overview for 166.88.177.0/24 shows AS213823. The IPv6 2a12:8fc6:4011::/48 is not currently announced in RIPEstat's prefix overview.

That churn is consistent with rented, reassigned or otherwise movable address capacity. Many small hosting providers use such arrangements legitimately. IPv4 space is scarce, and a young provider may lease blocks, use customer-provided ranges, obtain delegated space through partners, or move among suppliers as economics change. The operational risk is not that this is unusual. The risk is that customers can become locked to addresses that the provider does not durably control.

A customer who builds mail reputation, allow lists, reverse DNS, API access rules or security policies around an address can discover that a commercial or routing change upstream forces a renumbering exercise.

The historical route pattern also limits claims about installed capacity. A handful of /24s can support a meaningful small VPS or proxy-style business for a period. It cannot by itself prove how many servers were behind those addresses, whether they were owned by Sovy, whether they sat in any listed facility, or whether customers had a clean migration path when routes stopped. A route being visible for months is evidence of a network edge. It is not evidence of deep hardware inventory, off-site backup, 24/7 support or multi-site recovery.

The right way to read the history is balanced: Sovy did have a period of live route origination, and that makes the company more than a name-only artefact. But the routes were no longer visible from AS401110 by July 2026, and the addresses that remain visible in the wider internet are now associated with other origins or, for the IPv6 range, not visible. For any current customer claim, that is a material downgrade.

The facility list is a claim to be verified, not a recovery plan

PeeringDB's network-facility view lists five facilities for AS401110: Equinix SG1 in Singapore, Equinix SG3 in Singapore, Equinix HK2 in Kwai Chung, Linxdatacenter in Moscow, and NewTelco Kiev in Kyiv. At first glance, that looks like a global footprint. It spans Southeast Asia, Hong Kong, Russia and Ukraine. It fits the PeeringDB network record's global scope field. It could describe a real multi-site network presence.

But facilities in a peering directory are not the same as customer-ready cloud zones. The listing does not state rack count, committed power, cross-connect ownership, transit contracts, router hardware, remote-hands terms, spare equipment, backup placement or customer failover capacity. It does not say whether the company has owned servers in each building, a virtual port, a reseller arrangement, a former footprint, or a pending interconnect. PeeringDB also lists zero exchange LAN entries for Sovy in the netixlan view, so the facility list is not paired with visible exchange-port detail in that public record.

This distinction is especially important for redundancy. A customer might see five listed facilities and assume workloads can be moved among five sites. Nothing in the public record proves that. A real recovery plan needs more than city names. It needs a statement about where customer data is stored, whether compute capacity is duplicated, whether backups are off-site, whether images can be restored in another city, whether the provider has spare address space, whether DNS can be changed quickly, and whether staff or remote hands can act during a local incident.

Without those details, a multi-city list can be a sales hint rather than a resilience promise.

The locations also raise locality questions. A customer buying from a South Dakota-listed entity using a .cloud domain may not expect a footprint that publicly names Singapore, Hong Kong, Moscow and Kyiv. That mismatch is not automatically a problem. Network services are often global, and customers may want capacity near specific markets. It becomes a problem when the service page, contract or support materials do not make locality clear. If a workload has data-protection, sanctions, latency, content or customer-notification obligations, the customer needs a precise statement of where data is processed and which parties can touch it.

The facility list therefore belongs in diligence, not in marketing shorthand. It is a place to ask questions: Which of these facilities still carry Sovy service in 2026? Which have customer servers? Which are only interconnection sites? Which are no longer active? Which have independent transit? Which can take a restored workload if another site fails? Which contractual party controls remote hands? Which location is used for backups? Until those answers are visible, the list supports a possible historical or planned footprint, not a proven current recovery architecture.

The domain state weakens the customer surface

The sovy.cloud domain is central to Sovy's public identity. ARIN contact mailboxes use it, PeeringDB lists it as the website, and the network name itself is sovy.cloud. The domain RDAP record therefore matters. As of the current lookup, it shows registration on 2024-05-03, expiration on 2026-05-03, a last-changed date of 2026-06-13, and status values including server hold, redemption period and pending delete. It also shows Cloudflare nameservers, but the hold and redemption state explains why ordinary public resolution did not produce a working site during this review.

For a customer-facing cloud provider, that is a serious signal. A live website is not the service itself, but it is often where customers find terms, invoices, support links, status pages, abuse contacts, service locations, maintenance notices and export instructions. If the public identity domain is expired, held or pending deletion, the customer cannot assume ordinary support continuity. The risk is not just that a marketing page is down. The risk is that mailboxes on the same domain, password resets, control panels, billing notices or incident messages may also be affected if they depend on that domain.

The domain state also changes how to read ARIN contacts. A registry contact using [email protected] may have been valid when created. If the domain later enters hold or redemption, the practical reachability of that contact becomes doubtful unless the company has preserved mail handling elsewhere or moved contacts to another domain. Public records do not show such a move. Again, that does not prove nobody is reachable by phone or private channels. It does mean a customer should not rely on the public email layer without testing it.

The business lesson is simple: in hosting, domain hygiene is part of operational hygiene. A provider that sells remote infrastructure needs stable names for support, DNS, status, contracts and notices. Losing or letting lapse the brand domain can turn an otherwise manageable incident into a trust incident. Customers may not know whether the outage is limited to the website, whether the company is still operating, whether invoices are legitimate, or whether future notices will arrive. A weak domain state therefore belongs in the same risk bucket as weak BGP visibility and unvalidated contacts.

The main failure path is not one broken server

For Sovy Cloud Services, the most likely severe failure path is not simply a disk failing in a rack. A disk can be replaced if someone has access, parts and a procedure. The larger risk is a layered dependency failure: address rights change, transit or provider arrangements end, the public domain stops resolving, contact mail fails, and customers have no tested way to export or move workloads. That combination can make even intact servers feel unreachable.

The first layer is address continuity. Sovy's historical routes suggest a changing set of IPv4 /24s and one IPv6 /48 rather than a stable, current origin. If a customer once used those addresses, the exit problem would depend on how much notice Sovy provided and whether the customer could run old and new addresses in parallel. Mail senders, VPN endpoints, allow-listed APIs, payment callbacks, game servers and managed client sites can all become sticky to an address. A sudden route withdrawal can force a customer to update many outside parties under pressure.

The second layer is upstream and contract continuity. With no current AS401110 neighbours visible in RIPEstat's ASN-neighbours view, the present upstream state cannot be confirmed publicly. Historical address use does not show who currently has contractual authority over any rack, router or delegated block. If Sovy moved customers behind another provider, then that provider's contract terms, route filters, abuse policies and remote-hands process may decide the real repair window. Customers need to know who can fix a fault at the moment it happens, not only which company name appears on the invoice.

The third layer is site concentration. PeeringDB lists five facilities, but public route evidence does not prove live use of any of them. If all active workloads, if any, sit in one provider environment, then the multi-city list gives little protection. If workloads are spread across sites, the public record still does not say whether backups and control systems are separated. Recovery depends on the placement of data and credentials, not just servers. A provider can have ports or machines in several buildings and still have a single point of failure in billing, DNS, support access or address space.

The fourth layer is support depth. ARIN has contact records, but the unvalidated POC remarks and the domain condition both reduce confidence in public escalation. A small provider can be excellent if a small team is responsive and transparent. It can also be fragile if the same person handles routing, billing, abuse, hardware replacement and customer tickets. The public record does not let customers distinguish between those cases. The correct response is to test support before placing production workloads, not after a route or facility problem has already arrived.

Who is affected if Sovy capacity fails

The affected users are not abstract. They are anyone who treats a low-visibility provider as durable infrastructure. A developer using a Sovy-hosted VPS for a lab can recover by rebuilding elsewhere if they keep independent backups. A small business using the same environment for a customer portal may face lost orders and confused support calls. A reseller may discover that its own brand takes the reputational hit even if the root dependency sits several layers upstream. A mail sender may lose reputation or allow-list status when addresses change.

A gaming, proxy or VPN customer may care less about contract formality but still care deeply about route stability and abuse handling.

The geography can also change who is exposed. If a customer assumed the service was in the United States because the ARIN entity address is in South Dakota, the PeeringDB facility list complicates that assumption. If a customer assumed data was in Asia because a server had low latency from Singapore or Hong Kong, that still does not prove where backups, control panels or support access are located. If a customer must avoid certain jurisdictions or must notify users about processing location, the public record is not enough. The service must specify locality in writing.

The abuse-handling layer matters for all customers, including clean ones. Small hosting networks with short-lived address blocks can attract noisy workloads because setup is fast and identity signals are thin. A single abusive customer can damage a /24's reputation, create complaints, trigger route filtering, or lead upstreams to demand action. The public Sovy record includes an abuse contact, but the domain and validation signals weaken confidence that public abuse handling is robust today. Clean customers on the same capacity can suffer collateral effects if reputation management fails.

Billing and control-panel continuity are another affected area. If the brand domain is in redemption or pending deletion, customers may not know which payment notice, account recovery email or support channel to trust. That uncertainty can turn ordinary service management into security risk. A provider can reduce this risk by publishing verified alternate contacts, maintaining a status page on a stable domain, and giving customers signed notices of any migration. No such current public channel is visible from the records reviewed here.

What a responsible buyer would ask before using it

A buyer considering Sovy Cloud Services should start with present-tense proof. Which services are available today? Which ASN or upstream originates customer traffic today? Which prefixes are assigned to customers today? If AS401110 is not used, why is it not used, and what replaces it? Which facilities are active, and which are historical or planned? Can the company show a looking-glass, route monitor, status page or customer terms that match the current service?

The second question is locality. Where will the customer's virtual machines, bare-metal servers, backups and management systems reside? Are Singapore, Hong Kong, Moscow and Kyiv still relevant to current service, and if so, how? Does a customer choose a region, or does the provider place workloads at its discretion? Are backups copied across borders? Who are the facility and remote-hands parties? What happens if one jurisdiction becomes unavailable because of sanctions, conflict, local regulation or facility access constraints?

The third question is address and route control. Are customer addresses leased, assigned, bring-your-own, or upstream-provided? How much notice is given before renumbering? Can reverse DNS be changed quickly? Are Route Origin Authorizations current for the actual origins? Can the provider maintain a route during a billing dispute long enough for the customer to export data? Does the customer have any right to a temporary overlap period during migration? These details matter more than the advertised number of cores or RAM because address movement is what can trap customers during exit.

The fourth question is recovery. Are backups included by default, or must customers buy and configure them separately? Are backups stored in a different rack, facility and provider account? How often are restores tested? Can a customer export a disk image without opening a support ticket? What is the guaranteed response for a failed host, a failed router, a domain outage or an upstream withdrawal? If the answer is informal, the customer should treat the service as experimental or secondary.

The fifth question is contact continuity. Which support domain is active now that sovy.cloud is in a hold and redemption state? Are ARIN contacts being updated? Is there a status page, phone number, ticket portal or signed customer-notice channel that does not depend on the expired domain? A serious provider can answer those questions plainly. If it cannot, the buyer should not place production dependencies there without independent backup and a fast rebuild plan.

Installed capacity is different from usable capacity

Sovy's public evidence also shows why buyers should separate installed capacity from usable capacity. A provider can have a server in a facility, a router port, a delegated address block or a customer account at an upstream and still lack the capacity that matters during an incident. Usable capacity is the part of the system that can be sold, supported, restored and exited without improvisation. It is the difference between a machine that is powered on and a service that can survive a fault without trapping the customer.

The distinction starts with addresses. During its active period, AS401110 originated several /24s and one IPv6 /48. Those are enough to make services reachable. They are not enough to prove how many customers can be safely hosted, how many addresses are reserved for management, whether reverse DNS is under direct control, or whether addresses can remain with customers during migration. A single /24 can feel like a large asset to a small hoster, but it can vanish quickly once public IPv4 addresses are assigned to virtual machines, bare-metal servers, mail systems, customer firewalls, monitoring nodes and spare capacity.

If the provider does not control the address supply durably, installed capacity can become unusable when the address arrangement ends.

Compute capacity has the same problem. A provider can advertise virtual machines from leased dedicated servers, owned hardware in a colo rack, a reseller account, or a mix of all three. The customer may see only CPU, RAM and storage numbers. The repair reality depends on who can touch the host, who owns the spares, who can reinstall a failed machine, who controls the hypervisor, and who has authority to migrate a disk image. If Sovy is active through a different arrangement than AS401110, those details become even more important because the visible ASN no longer tells the customer where the control point is.

Power and facility access are also part of usable capacity. The PeeringDB facility list names impressive locations, but usable service depends on the exact presence inside those locations. A virtual port is not the same as a rack. A single server is not the same as a cluster. A rack without spare parts is not the same as recoverable capacity. A facility entry without a remote-hands agreement can become a waiting room during a hardware fault. Customers should ask whether Sovy has installed equipment, leased equipment, virtual interconnection, or a third-party hosting account in each listed city. Each answer has a different failure path.

Support labour is the last capacity limit. Small providers can be technically strong but operationally narrow. One or two capable operators may keep costs low and fix ordinary issues quickly. The same structure can break down when several customers need migration help, abuse reports arrive, a route changes, and a facility issue demands coordination at the same time. Without a public support page, current contact validation or a working brand domain, buyers cannot estimate support depth from the outside. That uncertainty should be reflected in contract scope, workload choice and backup design.

Migration is the customer-side recovery plan

When provider evidence is weak, migration becomes the customer's own recovery plan. This is not a criticism of every small provider. Many customers choose small networks precisely because they are flexible, inexpensive or willing to host workloads larger providers reject. The tradeoff is that the customer must be ready to leave. Sovy's public record makes that tradeoff explicit: the ASN once originated routes and now does not, the domain once supported a brand and now appears to be in a hold and redemption state, and the listed facilities do not prove present service.

A customer who cannot migrate should not treat that uncertainty as acceptable background noise.

A practical migration plan begins with backups outside the provider. A snapshot stored on the same host, in the same account, or behind the same expired domain is not enough. The customer needs a copy that can be restored on another provider without Sovy's cooperation if the public contact surface fails. For a simple website, that may mean source files, a recent content export and a separate DNS account. For a virtual machine, it may mean an image, configuration management, structured data exports and secrets stored elsewhere. For bare metal, it may mean documented rebuild steps and a tested replacement environment.

DNS control is just as important. Customers should keep domain registration, authoritative DNS and email recovery outside the provider whenever possible. If a provider's own domain is in trouble, placing the customer's domain under the same support and billing surface increases risk. A customer who controls DNS independently can move web, mail or API traffic faster when a host disappears. A customer who must ask the provider to change DNS during an outage may discover that the provider's own support identity is part of the same incident.

Address-sensitive services need a stronger plan. Mail systems, VPN endpoints, payment integrations, security allow lists, game servers and partner APIs can all be hard to renumber. If those workloads used Sovy-provided addresses, the customer would need a staged exit: new addresses, parallel service, updated reverse DNS, partner notices, monitoring, reputation warming and final cutover. Without a written overlap period, the provider can unintentionally turn migration into an outage. The historical Sovy prefix churn is exactly the sort of record that should push customers to negotiate address-change terms before deployment.

The migration question also helps classify acceptable use. A stateless test node, short-lived crawler, development box or temporary relay can tolerate weak provider evidence if the customer assumes it may vanish. A production application with customer data should not. A managed-service provider reselling capacity should be even more cautious because it takes responsibility for customers who may not understand the upstream dependency. If the reseller cannot explain where Sovy service runs now and how it can be replaced, the reseller is taking on risk it may not be able to control.

What would change the grade

The evidence grade could improve, but the necessary proof would have to be current. The most direct improvement would be a live route surface: AS401110 visible with stable prefixes, current Route Origin Authorizations for the actual origins, and observed upstream neighbours that match a published network page. If Sovy no longer uses AS401110, the company could still improve confidence by explaining the replacement network path, naming the operating domain, and showing how customers reach support and export data under the new arrangement.

The second improvement would be domain and contact repair. A restored sovy.cloud domain, working website, current support address, updated ARIN contacts, and a simple public status or notice page would answer many of the immediate continuity questions. The page would not need marketing gloss. It would need present-tense facts: active services, service locations, support hours, emergency contact, maintenance notices, abuse handling, and what customers should do if they need to migrate.

The third improvement would be facility clarification. The PeeringDB facility list could be turned from a clue into useful evidence if Sovy stated which facilities are active, what kind of presence exists in each, and which ones can host customer workloads. It would be enough to say, for example, that one site hosts compute, another provides transit, another is historical, and backups are stored in a named region. Customers do not need rack numbers. They need to know the failure domains.

The fourth improvement would be exit rights. A small cloud provider earns trust when it tells customers how to leave. That means export formats, notice periods, IP renumbering rules, reverse-DNS process, backup availability after cancellation, and emergency access during billing disputes. These are plain operational terms, but they turn an opaque dependency into a manageable one. In Sovy's case, exit rights would matter because the historical record already shows routes moving out of AS401110.

Until those proofs appear, the grade should stay weak. The public record is not empty, but current operation is not visible enough for production trust. The company name, ASN and facility entries explain why Sovy belongs in the infrastructure map. The absence of current routes, the domain condition and the thin contact surface explain why the map should mark the item as high-uncertainty rather than active cloud capacity.

The operating-status call

The operating-status call is weak, with historical network evidence but no current public route proof. Sovy Cloud Services has a real public identity in ARIN. It had visible historical routes. It has a PeeringDB record with a global scope and five facility listings. Those facts prevent a purely negative reading. They show that something more concrete than a name existed in 2024 and early 2025.

The current facts are more severe. AS401110 is not announced in RIPEstat. There are no current prefixes in the announced-prefixes view. There are no observed neighbours. The historical prefixes either now originate from other ASNs or are not visible. PeeringDB lists zero prefixes, zero exchange LAN entries and no public POC rows. The public brand domain is expired and in hold, redemption and pending-delete states. ARIN contact records carry unvalidated remarks. None of those facts alone proves that every private service has stopped. Together, they make a strong case against treating Sovy as a currently evidenced cloud provider.

For low-risk experiments, a buyer could still engage if Sovy can produce fresh, direct proof of service, live contacts and export rights. For production workloads, regulated data, customer-facing managed hosting, mail, VPN endpoints or anything address-sensitive, the evidence is not enough. The buyer should require current route proof, active service documentation, facility confirmation, support validation, backup terms, locality terms and a migration plan before putting material workloads behind the name.

The final reading is deliberately sober. Sovy Cloud Services once had the visible pieces of a small network-service operator: an ASN, contact records, routes, facilities and a brand domain. By 2026-07-12, the public record no longer shows the operating surface that a cloud customer should expect. The racks, transit, power, support and repair windows may exist privately, or they may have moved elsewhere, but they are not proven by the public evidence available now. Hosted capacity without those proofs is not resilient cloud. It is an unresolved dependency.