Summary
- SVRHOUSE LLC is visible in public internet number and routing records as the organisation associated with AS210416 and the IPv4 prefix 193.9.22.0/24. RIPE and RIPEstat records show the ASN is assigned, announced, and visible through Route Information Service peers, with import and export policy referencing AS12714 and AS47438.
- The stronger conclusion stops there. Public records support a network-resource operating footprint and a dependency map, not a verified customer service account. The available evidence does not prove current hosting quality, support capacity, access customers, uptime, commercial scale, or a cloud-service subscription product.
The point is the gap between routing evidence and customer proof
SVRHOUSE LLC is a useful case because the public internet leaves two different kinds of evidence, and they should not be collapsed into one. The first kind is routing evidence. It says whether an autonomous system exists, whether a prefix is being announced, whether other networks see it, and which neighbouring systems appear in registry policy or BGP paths. On that record, SVRHOUSE is not a dead name in a registry. The company name appears in RIPE organisation data, AS210416 appears in aut-num data, the IPv4 prefix 193.9.22.0/24 appears as assigned provider-independent address space, and live routing views show the prefix being announced by AS210416.
The second kind is customer proof. It asks a different set of questions. Is there a public service catalogue? Are there terms for hosting, virtual servers, managed support, connectivity, domains, mail, backup, security, or colocation? Are customers named or indirectly visible through credible references? Are there support procedures, fault windows, service-level terms, abuse handling practices, maintenance notices, public status pages, invoice-facing plan descriptions, or developer documentation? Those are the sorts of facts that can justify a service-account thesis. On the sources available for SVRHOUSE, those facts are either missing, inaccessible, or too indirect to carry the claim.
The distinction matters because internet-resource records are operationally meaningful even when the business layer is opaque. A routed ASN can affect reachability. A /24 can host public endpoints. Upstream choices can expose dependencies. Lack of RPKI route-origin authorisation can create a routing-security watchpoint. Passive DNS and hosted-domain databases can suggest that addresses inside the prefix have been used for web hosting. But none of these facts, alone, says that the company sells reliable hosting, that it maintains a customer support operation, that it serves small businesses, or that any given hosted domain is a paying customer of SVRHOUSE rather than a reseller, a managed account, a legacy placement, a shared platform artefact, or an unrelated data-quality artifact.
The paid unit, therefore, is not a polished cloud account. It is the operating footprint of a small network-resource holder: an ASN, a single visible IPv4 /24, public routing policy, upstream dependence, and a modest set of domain-hosting signals. That footprint can still be worth tracking. IPv4 scarcity makes small routed blocks economically relevant. Route visibility makes them reachable from global networks. The use of upstream providers gives the footprint a supplier map. The absence of a rich public service layer makes the judgment more cautious, not less interesting.
What is known from registry records
The most concrete institutional evidence is in the RIPE Database. The RIPE organisation record for ORG-SA4870-RIPE identifies the organisation name as SVRHOUSE LLC, lists country code RU, provides registration number 1216000005022, and gives a Pskov address on ul. Paromenskaya. The same organisation record is connected to the maintainer SVRHOUSE-MNT, and it was created in November 2021, with a later modification recorded in May 2026. This is strong evidence that the company name is not merely a label invented by a third-party traffic database. It is present in the registry system that records internet number resources in the RIPE NCC service region.
The aut-num record for AS210416 is equally important. It gives the AS name SVRHOUSE, references ORG-SA4870-RIPE, marks the autonomous system as assigned, and records import and export policy for AS12714 and AS47438. The record was created on November 29, 2021 and was last modified on December 29, 2025. Registry records should not be read as performance claims. They say that a resource has a recorded holder, administrative contacts, maintainers, and routing-policy declarations. They do not certify that a business is active in the ordinary commercial sense, that its staff can be reached, or that customers are satisfied. But for network-resource evidence, the aut-num record is a primary record.
The IPv4 resource record narrows the operating surface. RIPE's inetnum record for 193.9.22.0 through 193.9.22.255 lists netname ORG-SA4870-RIPE, country RU, organisation ORG-SA4870-RIPE, sponsoring organisation ORG-AL433-RIPE, status ASSIGNED PI, and maintainers including SVRHOUSE-MNT and RIPE-NCC-END-MNT. The corresponding route record lists 193.9.22.0/24 with origin AS210416 and maintainer SVRHOUSE-MNT. Together, the inetnum and route records turn the company from a name into a network-resource footprint: one /24, 256 IPv4 addresses, and a routing record that allows the prefix to be associated with AS210416 in routing filters and public analysis.
The status "ASSIGNED PI" is especially relevant to the economics. Provider-independent address space is useful because it can, in principle, be routed through different upstream networks without forcing all services to renumber into a provider's address space. That does not mean the holder has multiple robust providers in practice, or that it can switch easily under commercial pressure. It means the address block has a structural value separate from one access provider's aggregate pool. In a market where IPv4 addresses remain scarce and leased or transferred address space has become a real cost item, even a single /24 can be a meaningful asset. It is large enough for DNS, web hosting, VPN endpoints, mail infrastructure, control panels, monitoring nodes, or private customer allocations. It is also small enough that a serious outage, abuse complaint, RPKI mistake, upstream dispute, or route filter could affect a large share of the holder's visible footprint at once.
There is no evidence here of a large network estate. RIPEstat's current AS overview identifies AS210416 as announced, but the announced-prefix data shows one IPv4 prefix, 193.9.22.0/24, and no IPv6 prefix in the returned data. RIPEstat's routing-status view reports 256 announced IPv4 addresses, zero IPv6 /48s, one IPv4 prefix, two observed neighbours, and full visibility among the RIS IPv4 full-feed peers in that query. CAIDA's ASRank data is consistent with a narrow footprint: one ASN, one prefix, 256 addresses, no customer cone beyond itself, and two providers in the AS-degree view. The company is visible, but it is not visible as a carrier-scale operator.
Routing visibility is real, but it is not a service guarantee
The best evidence that SVRHOUSE is operationally present on the internet is that multiple public routing views see AS210416 announcing 193.9.22.0/24. RIPEstat's routing-status response places the first seen route for origin AS210416 and prefix 193.9.22.0/24 in February 2022 and the last seen route at the July 9, 2026 query time. The same response shows all reported RIS IPv4 peers in that query seeing the route. The announced-prefixes response covers the period from June 25, 2026 to July 9, 2026 and returns the same /24. RIPEstat's prefix-overview endpoint also marks 193.9.22.0/24 as announced and associates it with AS210416, holder SVRHOUSE SVRHOUSE LLC.
That makes the evidence stronger than a stale allocation. A dormant aut-num record can remain in a registry long after a business changes direction. A contact domain can expire. A historical address assignment can sit unused. SVRHOUSE's case is different because the prefix appears in live BGP data. The route can be seen by collectors. Upstream paths exist. Third-party ASN pages such as bgp.tools and IPinfo also list the ASN as active or hosting-related, and they report the same small IPv4 footprint.
Still, routing visibility is not uptime. A route announcement tells the internet where to send traffic for a prefix. It does not say that every service inside the prefix is healthy, that customer workloads are backed up, that support responds during faults, or that the underlying servers are owned, leased, managed, or resold by SVRHOUSE. A small ASN can announce a /24 for internal services, for a reseller, for a handful of websites, for VPN endpoints, for mail, for a legacy hosting platform, for private infrastructure, or for a customer that uses the resource holder as a routing wrapper. The public route by itself does not disclose the commercial arrangement behind the traffic.
The same restraint applies to the two observed upstreams. The RIPE aut-num record declares import and export policy with AS12714 and AS47438. RIPEstat's routing-consistency view says the imports and exports for those peers are present in both BGP and WHOIS at the query time. bgp.tools and IPinfo identify the same two networks as upstreams or peers, with AS12714 corresponding to PJSC MegaFon and AS47438 to Pskovline Ltd. This creates a credible dependency map: SVRHOUSE's announced prefix reaches the global internet through routes involving those neighbouring networks. But the public record does not reveal contract terms, capacity, redundancy, price, support priority, physical handoff, or whether either path is primary, backup, reseller-provided, or administratively retained.
That is why the article title says active routing, not a proven customer service account. The resource is not invisible. The operating surface is not imaginary. But the commercially important part of the business remains thin in public.
The cost base is probably dominated by resource, upstream, and operating overhead
For a small network-resource holder, the cost base is different from a hyperscale cloud platform. The visible resource base is only 256 IPv4 addresses and one ASN. That can still require real spending and operational attention: registry or sponsorship costs, upstream connectivity, routing configuration, abuse handling, monitoring, server or virtualisation costs, DNS and mail operations, and staff or contractor time. If the prefix supports customer-facing websites, the cost base would also include hosting hardware or leased servers, storage, backups, power, facility dependence, security controls, customer support, billing, and incident response.
The public record does not let us allocate those costs with precision. RIPE records show a sponsoring organisation. Upstream routing data points to two neighbouring networks. Host.io and IPinfo show hosted-domain signals across selected IP addresses inside the /24. Those signals suggest that the address space may be used for shared web hosting or web-service infrastructure, but they do not show whether SVRHOUSE itself bills end customers, whether another provider uses its network resources, or whether the domains are legacy placements.
The economics of a single /24 are also unusually concentrated. If a business runs on one announced prefix, the address block is both the asset and the constraint. There is limited room for segmentation by customer type, product tier, geography, or redundancy class. Abuse on one cluster of addresses can affect reputation for the whole block. A spam listing, malware report, route leak, DDoS incident, payment dispute, upstream filtering decision, or misconfigured routing record can have disproportionate effect. Conversely, a small block can be easier to monitor and cheaper to operate if the use case is narrow. The right economic conclusion is not that SVRHOUSE is weak, but that the public evidence points to a compact operating unit whose resilience depends heavily on a few infrastructure choices.
Supplier dependence is therefore a central issue. AS210416's visible neighbour set is small. CAIDA's ASRank records two providers and no downstream customers. RIPEstat records two observed neighbours. The route policy names AS12714 and AS47438. A small operator can use a limited provider set effectively, especially if the services it supports are regional or low-volume. But fewer upstream options reduce bargaining leverage and make operational incidents easier to trace to a narrow set of external dependencies. If one provider changes filters, experiences congestion, reconfigures communities, faces regulatory pressure, or suffers an outage, the smaller network's recovery options may be constrained unless the second path is genuinely diverse in contract, geography, physical route, and upstream hierarchy.
This is where the role of Pskovline matters as context. RIPEstat identifies AS47438 as Pskovline Ltd., and CAIDA shows it as a much larger routing neighbour than SVRHOUSE, with a wider cone and more total AS degree. RIPEstat identifies AS12714 as PJSC MegaFon, a national-scale Russian network. That combination can make sense for a small RU-linked resource holder: a regional provider and a larger carrier path. It may improve reachability, but it also means the public dependency picture is Russia-centered, not globally neutral. For international counterparties, that is a commercial and compliance consideration even if no SVRHOUSE-specific sanction or violation appears in the sources reviewed.
Hosted-domain evidence is meaningful but limited
The strongest customer-adjacent signal comes from hosted-domain databases, not from a SVRHOUSE service page. IPinfo's ASN page lists SVRHOUSE LLC as the registered name for AS210416, identifies the ASN type as hosting, reports 256 IPv4 addresses and zero IPv6 addresses, and counts 272 hosted domains across 11 IP addresses. It also shows hosted-domain concentration on a few addresses: 193.9.22.4, 193.9.22.5, 193.9.22.3, 193.9.22.2 and 193.9.22.84 are among the addresses with domain counts. Host.io's reverse-IP pages give a more concrete sample. On July 9, 2026, Host.io reported 165 domains hosted on 193.9.22.4, 69 domains on 193.9.22.5, 14 domains on 193.9.22.3, and no domains on 193.9.22.70. The sample domains include many Russian-language or Russia-oriented names, several of which appear local or regional in character.
This evidence should not be dismissed. A single /24 with hundreds of domains mapped to a small set of addresses looks more like a shared web-hosting or hosted-web footprint than like a purely unused registration. It helps upgrade the network evidence from "a routed prefix exists" to "the routed prefix appears to support public domain endpoints." For a company research article, that is relevant because it suggests a live operational surface: DNS points domains toward addresses in the block, and third-party datasets see those domains as hosted there.
But the same evidence has clear limits. Passive hosted-domain counts are not invoices. They do not reveal who controls the server, whether the sites are active, whether they are customer sites, whether they are maintained, whether there is a reseller in between, or whether the domains use shared infrastructure only for a static landing page. A domain count can be inflated by parked domains, historical DNS, aliases, old records, redirects, or low-traffic websites. The data may also lag behind current DNS. Host.io's own page for svrhouse.com does not show a normal active web endpoint in the extracted web summary, and direct fetches to the domain did not resolve in the research environment. Host.io did show Yandex mail and name-server records for svrhouse.com, but not a public page that describes SVRHOUSE hosting plans, terms, support coverage, or customer onboarding.
This is why hosted-domain evidence is medium, not strong, for a customer-service thesis. It raises the probability that the prefix has hosted-web use. It does not prove the quality, scale, or commercial structure of that use. The conservative classification is "network-resource evidence" rather than "cloud service dependency." Cloud service dependency would require a clearer paid unit: customers buying hosted infrastructure, server rental, managed hosting, backup, security, migration, mail continuity, software subscription, or managed support from SVRHOUSE. The public evidence reviewed does not meet that threshold.
Customer dependence is possible, but not directly observable
If the hosted-domain counts are current, some external parties may depend on the 193.9.22.0/24 footprint for web reachability. That dependence could be small but real. A local business website, an institutional landing page, a small e-commerce site, a regional service provider, or a professional firm can experience economic harm if its hosting endpoint disappears, even if the provider is small. In that scenario, SVRHOUSE's relevance would be less about global scale and more about service continuity for a cluster of customers whose online presence is tied to a few shared IP addresses.
However, the customer dependence remains inferred from DNS and hosting signals. It is not directly proven. There is no public customer list in the sources reviewed. There is no service catalogue showing a target buyer. There is no support or status page showing how incidents are handled. There are no current public terms found that would explain refunds, uptime, acceptable use, data retention, backup responsibilities, abuse processing, or renewal mechanics. Without those facts, it would be misleading to describe SVRHOUSE as a proved small-business hosting provider or managed-service provider. The safer statement is that public datasets show domains hosted on addresses routed by AS210416, and that such hosting signals can create customer-dependence questions worth monitoring.
Switching cost also cannot be measured directly. For a simple static site, moving from one shared host to another may be cheap if the customer controls DNS, content, database backups, credentials, and domain registration. For a dynamic site with mail, databases, custom scripts, SSL certificates, forms, payment integrations, or Russian-language local support needs, migration can be harder. The public record does not tell us which case applies to domains on the SVRHOUSE-routed addresses. It does tell us that the address footprint is concentrated. If many domains sit on a handful of IPs, then migration risk is likely correlated: a server-level, routing-level, or abuse-level incident can touch many hosted names at once.
The most important customer-dependence question is not "how many domains are there?" but "who controls the operational switch?" If domain owners have direct access to DNS and hosting backups, they can leave quickly. If a reseller, web studio, or local integrator controls the stack, switching requires coordination. If the domains are legacy accounts maintained for nontechnical customers, inertia can be high even when the nominal hosting bill is small. None of that is visible in RIPE, Host.io, IPinfo, or bgp.tools. Those databases illuminate the infrastructure, not the contractual ties around it.
Competition is broad because the proved product is narrow
The substitutes for SVRHOUSE depend on what product one assumes. If the product is simply a routed /24 with a few hosted websites, the substitute set is broad. Customers or operators can use regional hosting providers, Russian shared-hosting companies, generic VPS platforms, transit resellers, managed web studios, carrier-managed connectivity, or international cloud providers where regulatory and payment conditions allow. If the product is regional support in Pskov or nearby markets, then local-language support, existing customer ties, and familiarity with Russian registrars or mail systems may matter more than raw compute price. If the product is merely resource holding and route origination, then the substitute might be another sponsored resource arrangement or transit provider rather than a hosting company.
Because the public product is not proved, the competitive analysis should focus on the parts that are visible. The /24 is small, so SVRHOUSE is unlikely to compete on scale against large hosting platforms or national carriers. Its possible advantages would be local, operational, or relational: existing sites already pointed at the block, a regional provider tie, a Russian legal and network presence, and the convenience of maintaining services where they already work. Its possible disadvantages are also clear: thin public documentation, no observed IPv6 footprint, no PeeringDB profile, no public status or support surface found, a small upstream set, and no public evidence of a diversified product portfolio.
The "no full service-account thesis" conclusion is important for competition. A company can be relevant in internet infrastructure without being a direct competitor to hyperscale cloud. A small network may host local websites, support a regional web agency, carry a few private endpoints, or provide address space and routing for a narrow set of services. In those markets, switching decisions are often driven less by benchmark performance and more by trust, language, payment method, support responsiveness, legacy compatibility, and the cost of touching old websites. The public sources do not show where SVRHOUSE sits in that chain.
The absence of a current service page also changes how substitutes should be tested. If a buyer cannot find public plans, support terms, pricing, or contact routes, the switching comparison shifts from "is SVRHOUSE cheaper or better?" to "is there enough visibility to rely on this footprint for a new workload?" For new customers, generic hosting and cloud services with public terms are easier to evaluate. For existing services already using the prefix, the relevant question is whether the operational risk of staying is lower than the migration risk of leaving.
Regulation, registry posture, and geopolitical risk
SVRHOUSE sits in the RIPE NCC service region and is recorded with country RU in RIPE data. That has several implications. First, the registry framework provides structured public records for the ASN, organisation, prefix, routing record, and maintainers. That is a positive institutional signal compared with a purely anonymous hosting footprint. Second, the country and upstream context create jurisdictional and geopolitical questions for counterparties outside Russia. Third, the company appears to operate through a sponsored-resource arrangement, visible through the sponsoring organisation references in RIPE records, which means resource administration and compliance obligations are not purely internal.
The public evidence does not support any SVRHOUSE-specific misconduct claim. It does not show sanctions, regulatory enforcement, litigation, or abuse findings tied to the company. A cautious article should not imply such findings. The risk is structural rather than accusatory. RU-linked internet infrastructure can be affected by payment constraints, sanctions compliance policies, cross-border procurement decisions, route filtering, upstream politics, domain and certificate practices, and customer concerns about data location or continuity. A small network with few visible upstreams has less public evidence of redundancy if such shocks occur.
The RPKI status is also a watchpoint. The RIPE RPKI validator returned "not-found" for AS210416 announcing 193.9.22.0/24, meaning no covering validated ROA was found for that route at the query time. That is not the same as "invalid." A not-found route is not rejected by RPKI validation because of a conflicting ROA; rather, it lacks a cryptographic route-origin authorisation. Many routes on the internet have historically been in not-found state, and networks may still accept them. But for a small operator, publishing a correct ROA can reduce route-origin ambiguity and help networks that prefer validated routes. In a world where more carriers and enterprises use RPKI origin validation in routing policy, remaining not-found is an avoidable weakness.
The absence of IPv6 is another operational signal. RIPEstat and IPinfo both showed no IPv6 footprint for AS210416 in the reviewed data. For a local shared-hosting footprint, that may not be immediately fatal; many legacy websites still rely on IPv4. But it limits the network's future posture. IPv6 support is not only a technical ideal. It can affect reachability, monitoring, procurement standards, public-sector requirements, and the ability to serve customers that expect dual-stack hosting. For a small operator, IPv6 deployment is not necessarily expensive in address terms, but it does require upstream support, DNS discipline, server configuration, firewalling, monitoring, and customer support knowledge.
What the absence of PeeringDB says
PeeringDB returned no network record for ASN 210416. That should be read carefully. Not every small network has or needs a PeeringDB profile. A company that buys transit from upstream providers and does not seek public peering may have little reason to maintain one. For a small regional hosting or infrastructure footprint, a missing PeeringDB record is not a failure by itself.
It does, however, reinforce the scale reading. PeeringDB is a common place to publish peering policy, traffic levels, exchange presence, NOC contacts, technical contacts, and facility or IX participation. If SVRHOUSE had a public strategy around internet exchange peering, multiple locations, open peering, or a transparent NOC surface, a PeeringDB record might be one place to expect it. Its absence is consistent with an operator whose public footprint is mainly registry and upstream-routed, not a network actively marketing interconnection.
This matters because network quality is often inferred from interconnection richness. A platform with multiple IX ports, diverse upstreams, public NOC contacts, and clear peering policy gives customers and partners more evidence about resilience. SVRHOUSE's public profile does not provide that. The route is visible, but the operating transparency is sparse.
Unofficial signals are thin, and that cuts both ways
Unofficial market evidence can sometimes sharpen a company profile: forum complaints, customer praise, network-operator discussions, uptime reports, spam-blocklist commentary, reseller listings, job postings, social-media support threads, procurement references, or local business reviews. For SVRHOUSE, the reviewed public evidence was thinner than that. Search results did not reveal a rich current service discussion around the company name. Registry mirrors for the Russian company registration number were blocked, paywalled, or not useful in automated review. The company's own listed domain did not provide a resolving public site in the direct checks, although Host.io retained DNS records for mail and name servers.
Thin unofficial evidence is ambiguous. It can mean the company is small, local, private, inactive commercially, using a reseller arrangement, or operating under a brand that is not obvious from the registry name. It can also mean the public web has simply not indexed the relevant Russian-language or customer-facing material. A responsible reading should not turn silence into a negative accusation. But silence does lower confidence in customer-facing claims. If a company has a substantial hosting business, one usually expects some public trace: plans, pricing, support pages, abuse policies, a control-panel brand, customer discussions, web-studio references, or at least a working corporate site.
The hosted-domain signal prevents the conclusion from being purely negative. It says the prefix likely has practical use. The lack of broader chatter prevents an upgrade to a mature-service thesis. For investors, suppliers, customers, or researchers, that means SVRHOUSE is a monitoring item rather than a fully characterised operating company.
What facts would change the judgement
Several facts would materially upgrade the assessment. The most direct would be a current SVRHOUSE service page with hosting, VPS, dedicated server, managed web, connectivity, mail, DNS, backup, SSL, cybersecurity, or support offerings. Pricing, terms, refund policy, uptime language, support hours, abuse process, and maintenance windows would give the public something commercial to evaluate. A public NOC or status page would add operational evidence. A PeeringDB record with facilities, exchanges, traffic levels, contacts, and peering policy would strengthen the network transparency. A valid RPKI ROA for 193.9.22.0/24 originated by AS210416 would improve the route-security posture.
Customer proof would be even stronger. Named customer references, web-studio partner pages, case studies, migration guides, public support knowledge bases, or credible forum discussions could show whether the domains on 193.9.22.4 and 193.9.22.5 are customer sites, internal sites, reseller accounts, or historical DNS residue. Public invoices or customer contracts are not expected, but there should be some trace if the paid unit is a commercial hosting account. Without it, the customer-dependence analysis remains probabilistic.
Network expansion would also change the thesis. Additional announced prefixes, IPv6 deployment, more upstreams, visible IX participation, downstream customers in CAIDA or RIPEstat, routing records for additional space, or a larger hosted-domain footprint spread across more addresses would all indicate a broader operating surface. Conversely, loss of the current /24 announcement, declining hosted-domain counts, unresolved maintainer contacts, a dead domain over time, or removal of routing records would downgrade the profile toward stale-resource risk.
Finally, regulator or abuse evidence would change the risk frame. None was found in the reviewed evidence, but if credible public records showed sanctions, enforcement actions, persistent abuse listings, unpaid registry issues, court disputes, or customer complaints, the article would need to shift from cautious footprint analysis to risk assessment. The current public record is not strong enough for that.
There is also a measurement lesson. The internet's public evidence stack is excellent at proving that a route exists, but poor at proving the human service wrapped around that route. Registry data identifies the resource holder. BGP collectors show reachability. Hosted-domain datasets show how names may land on addresses. AS-rank and peering databases help size the network. None of those sources can replace a working service page, support terms, customer references, or operational disclosures. For SVRHOUSE, that means the infrastructure record is more advanced than the commercial record. A reader can see the route, the /24, the upstream dependence, the hosted-domain concentration, and the absence of public interconnection detail. The reader cannot see the buyer, the contract, the migration rights, the support desk, or the service level. That asymmetry is the central finding, not a side note.
That asymmetry should control any future update. If SVRHOUSE later publishes a service catalogue, the article should not simply add a cloud label; it should test whether the catalogue describes who buys, where support sits, which data is backed up, how abuse is handled, how customers leave, and which upstream commitments protect the account. If instead the route stays active while the commercial surface remains dark, the profile should continue to treat the company as a routed watchpoint. The public route is evidence of reachability. The absent service page is evidence about the limits of what can be claimed.
The same discipline protects future comparisons with stronger operators. A company with PeeringDB records, IX ports, published support terms and visible service plans should receive a different category. SVRHOUSE has not yet supplied that evidence.
The evidence-grade conclusion
SVRHOUSE LLC earns a strong grade for current network-resource evidence. The ASN exists in RIPE records, the organisation record is named, the route record maps 193.9.22.0/24 to AS210416, RIPEstat sees the prefix announced, routing-status data shows broad RIS visibility, and third-party databases agree on a one-/24 footprint. That is enough to say the company has a real routed operating surface.
It earns a medium grade for hosted-web use. IPinfo and Host.io both show hosted-domain signals on IPs inside the prefix, with notable concentration on 193.9.22.4 and 193.9.22.5. That is meaningful, but it is not the same as verified customer ties, current service terms, or hosting quality. It supports watchpoints around website continuity and shared-infrastructure concentration, not a claim that SVRHOUSE is a proven cloud provider.
It earns a weak or negative grade for public customer-facing service proof. The listed domain did not resolve in direct fetches, Host.io's domain page did not show an active web endpoint or title, PeeringDB returned no network record, and no current public service catalogue was identified in the reviewed sources. That absence is the decisive reason to keep the category institutional and the topic network-resource oriented.
The bottom line is therefore deliberately narrow. SVRHOUSE shows active routing, one reachable IPv4 /24, two observed upstream dependencies, hosted-domain signals, and registry-backed institutional existence. It does not show enough public evidence to prove a live customer service account, a cloud-service paid unit, support quality, uptime, commercial scale, or customer dependence beyond what can be inferred from DNS and routing data. For BTW's purposes, the company is best tracked as a thin but active network-resource operator: small enough that every public signal matters, visible enough to affect reachability, and opaque enough that the next judgment should wait for better customer-facing evidence.