Summary
- Web Hosting, Inc. has a concrete public network identity. ARIN's AS63258 record lists the active autonomous system name as L7GUARD and the registrant as Web Hosting, Inc.; ARIN's 104.244.164.0/22 record lists a direct HOSTLR IPv4 allocation to the same organisation.
- The visible routing footprint is narrow but current. RIPEstat's AS overview marks AS63258 as announced, RIPEstat routing status reports five visible IPv4 announcements and no IPv6 on 2026-07-12, and RIPEstat announced prefixes shows the covering /22 plus four /24s.
- The customer-facing service identity is ValueHost rather than a large modern cloud portal. The ValueHost about page says the company has provided web-hosting services since 2000, offers site hosting, internet applications, CMS hosting, colocation, dedicated server rental, domain registration and email, and says its servers are placed across two Saint Petersburg areas, one Moscow area and one San Jose area.
- The resilience claim is not fully testable from public evidence. RIPEstat neighbours sees AS3216 and AS40966 beside AS63258; RIPEstat RPKI validation reports unknown validation status for the /22 because it found no validating ROAs; and the public service pages do not publish rack inventory, power topology, restore targets, hardware stock levels or data-portability commitments.
The Web Hosting, Inc. Story Starts With A Split Identity
Web Hosting, Inc. is easiest to misread if it is treated as a blank company label. The name is generic, but the public record around it is not. ARIN's AS63258 record gives the AS name as L7GUARD, shows the AS as active, and ties it to Web Hosting, Inc. at a Dover, Delaware address. ARIN's organisation record for WH-63 gives the same registrant name and includes a public note saying the organisation is a web-hosting provider with many websites in its network. The wording is plain, but it matters: this is not only a dormant company shell in the routing registry.
The second identity is ValueHost. The ValueHost about page describes a hosting business that has operated since 2000 and that supplies corporate clients and individuals with tools for placing websites, internet applications, CMS systems and information on the internet. The same page says ValueHost provides colocation, dedicated-server rental, domain registration and email services. It also names a physical footprint that is not simply "cloud" in the abstract: two technical areas in Saint Petersburg, one in Moscow and one in San Jose, United States.
Those two identities create the central reading problem for Web Hosting, Inc. The US registry record points to Web Hosting, Inc. and the HOSTLR IPv4 block. The ValueHost service page points to a Russia-centered hosting brand with a San Jose point in the declared footprint. The same page says hosting services in Russia are provided with the assistance of ZAO Web Hosting, a company registered in Saint Petersburg. RIPEstat's AS overview for AS40966 names that AS as L7GUARD-AS ZAO Web Hosting, and RIPE RDAP for AS40966 lists ZAO Web Hosting in Saint Petersburg.
That does not make the public story false. It makes the boundary important. A buyer does not contract with a route table; a buyer depends on the people, legal entity, facility access, supplier permissions and support channels behind the route table. When the advertised service identity, the US AS holder and the Russian operating references are spread across different registry systems, the due-diligence question becomes sharper: which entity contracts with the customer, which entity controls the rack, which entity holds the address space, and which team is responsible when an upstream path, hardware device or billing account fails?
The available evidence is enough to say Web Hosting, Inc. has a real hosting footprint. It is not enough to say the whole platform is independently resilient. Public records show a live AS, a direct IPv4 allocation, a ValueHost service surface, Russian and US location claims, and current routes. Public records do not show a modern status history, a facility-by-facility capacity table, an RPKI-covered route-origin setup, a published data export method, or a documented hardware replacement objective.
That distinction is the article's core. Web Hosting, Inc. can be assessed as hosted capacity with visible public infrastructure, but its risk profile is the old hosting risk profile: address scarcity, rack power, upstream reachability, storage backups, support coverage, billing continuity and customer exit. If those parts work, a small provider can deliver a practical service. If one layer fails and the recovery path is opaque, the customer's workload may have fewer options than it would have on a multi-region hyperscale cloud.
What The Registry Records Prove
The strongest public evidence is the registry trail. ARIN's AS63258 record says the AS was registered in October 2014, last changed in June 2025 and remains active. It lists Web Hosting, Inc. as the registrant and attaches technical, administrative and abuse contact roles. The AS name, L7GUARD, is important because it connects the US ARIN number to the ValueHost and L7Guard labels visible elsewhere in the public record.
The address block is similarly concrete. ARIN's 104.244.164.0/22 RDAP record lists a direct HOSTLR allocation from 104.244.164.0 through 104.244.167.255. The net was registered in November 2014 and updated in February 2022. The same record ties it to Web Hosting, Inc. and includes the same hosting-provider comment. In practical terms, that block is the public IPv4 capacity that can be inspected from outside: 1,024 addresses before any internal reservation, customer allocation, management use, blacklisting, routing policy or spare-address practice is considered.
RIPEstat's AS overview independently sees AS63258 as "L7GUARD - Web Hosting, Inc." and says it was announced at the 2026-07-12 observation time. CAIDA ASRank's AS63258 record is consistent with a small network: one ASN, five prefixes, 1,024 addresses, two provider-degree links and no customer or peer degree in its model. CAIDA's organisation record maps the same single-AS footprint to Web Hosting, Inc.
The AS and allocation records therefore settle a few basic questions. There is a named registrant. There is a direct IPv4 allocation. There is a current route. There is an abuse and technical contact trail. There is enough history to rule out a one-week throwaway network. Those are meaningful positives for a small hosting provider.
They do not settle service quality. ARIN does not say how many physical servers are installed, whether the San Jose area is still active, how much space is leased or owned, whether the Russian areas and the US area are connected by private backbone, whether customers can choose where data resides, or whether the same operational team controls all sites. CAIDA's topology view does not reveal billing processes, support staffing, backup restore tests or hardware stock. A route can be live while a customer still lacks a quick repair path.
The registry trail also raises one caution that is easy to miss. The direct allocation's public comment points to [email protected], while several ARIN contact records use hostlr.com or a similar variant for contact roles. That may simply reflect brand, mail and holding-company history. It is not, by itself, a failure signal. But for a customer, contact clarity matters. If an abuse report, urgent ticket or network escalation must cross brand names and domains, customers should verify which channel is live before production traffic depends on it.
The Route Table Is Current, Small And IPv4-Only
The network evidence on 2026-07-12 is live but compact. RIPEstat routing status for AS63258 reports five visible IPv4 prefixes, 1,024 IPv4 addresses, no visible IPv6 prefixes and two observed neighbours. RIPEstat announced-prefixes lists the covering 104.244.164.0/22 plus the four component /24s: 104.244.164.0/24, 104.244.165.0/24, 104.244.166.0/24 and 104.244.167.0/24. RIPEstat prefix overview for 104.244.164.0/22 says the prefix is announced by AS63258 and points to the same four related /24s.
This is a different public shape from a broad cloud provider. There is no visible IPv6 service under AS63258 in the reviewed routing status. There is no large count of separately routed customer prefixes. There is no public PeeringDB network profile for AS63258; PeeringDB's API lookup returns no network entity. None of those points proves poor service. Many competent small networks run with a small BGP surface and no PeeringDB profile. But the public table leaves little room to infer hidden scale.
The current route design also has a route-origin-security gap. RIPEstat RPKI validation for 104.244.164.0/22 reports unknown status with no validating ROAs. The same result appears for sampled more-specific routes such as 104.244.164.0/24, 104.244.165.0/24, 104.244.166.0/24 and 104.244.167.0/24. Unknown is not invalid. It means public route-origin validation did not find a ROA authorizing the origin. For customers, that is a route-hygiene question rather than an outage finding.
RIPEstat AS routing consistency gives a useful cross-check: the /22 and four /24s are in BGP and in Whois/IRR under ARIN, while the observed imports and exports with AS3216 and AS40966 appear in BGP but not in the same Whois import/export data. That is common enough in the internet routing world, yet it reinforces the point that public registry data does not completely describe the operational routing policy.
The small IPv4-only table changes the customer risk calculation. IPv4 addresses are scarce and portable only under defined arrangements. If a customer is assigned addresses from the HOSTLR /22 and later needs to move, it may not be able to take those addresses. DNS can move, but allowlists, reverse DNS, mail reputation, payment-fraud systems, customer firewalls and partner VPNs can be slow to adjust. If a block is filtered, reputation-damaged or temporarily withdrawn, the customer impact can outlast the BGP event.
For hosted websites, this may be tolerable. A small business site can often move with DNS and a backup. For a private application, mail system, licensed software endpoint, security sensor or customer API, address continuity can be harder. Web Hosting, Inc.'s public record does not publish a portability policy, an IP-renumbering playbook or a customer migration window. That absence is not unusual for a legacy hosting provider, but it is a practical limit on the "cloud" story.
The Upstream Path Has Two Public Neighbours, But Only One Is Clearly Outside The Hosting Group
The most important operational question in the route table is not the prefix count. It is how those prefixes reach the rest of the internet. RIPEstat ASN neighbours for AS63258 reports two observed neighbouring ASNs on 2026-07-12: AS3216 and AS40966. RIPEstat's looking-glass view for 104.244.164.0/22 shows many collector paths ending through one of those paths before AS63258.
AS3216 is the larger outside transit signal. RIPEstat's AS3216 overview names it as SOVAM-AS PJSC "Vimpelcom." RIPE RDAP for AS3216 lists PJSC Vimpelcom as the registrant and includes extensive public routing-community notes for a large carrier network. CAIDA ASRank's AS3216 record models it as a large Russian network with thousands of prefixes and many customer and peer links. For Web Hosting, Inc. customers, the presence of AS3216 suggests an established carrier path into the public internet.
AS40966 is a different kind of signal. RIPEstat's AS40966 overview identifies it as L7GUARD-AS ZAO Web Hosting, and RIPE RDAP for AS40966 lists ZAO Web Hosting in Saint Petersburg. CAIDA's AS40966 record models that AS as smaller than AS3216 but broader than AS63258, with three ASNs in its organisation cone and 15 prefixes. If AS40966 is part of the same operating family as the ValueHost service, it may provide internal or affiliated transit diversity, but it is not the same assurance as two independent external upstreams from a customer-risk perspective.
Two neighbours are still better public evidence than one. They suggest there is at least some BGP path choice. The caveat is that the public evidence does not prove separate fibre entrances, separate routers, separate data halls, separate power feeds or tested failover. BGP path diversity can collapse if both paths terminate in the same room, depend on the same access loop, share the same top-of-rack device, or require manual intervention to shift traffic.
The ValueHost about page's own language makes that question concrete. It says the interregional network and data-center infrastructure are built with Juniper routers and Cisco switches and with automatic backup of data channels using BGP technology. It also says sites are supported by backed-up equipment and channels, daily backup copies, uninterruptible power supply and high-speed optical lines through several large operators. Those are positive claims, and they are more specific than a vague uptime slogan. They still require verification because public BGP observations do not disclose the physical wiring or the recovery test history.
The customer question should therefore be framed as an evidence gap, not an accusation. Does Web Hosting, Inc. have two physically diverse transit paths for the customer block, or does the public two-neighbour table reflect a more limited operational design? Are both upstream routes active for all four /24s and the covering /22? Are the /24s announced deliberately for traffic engineering, DDoS handling or geolocation, or are they operational leftovers? Is there a documented path to withdraw only one customer /24 during an abuse or DDoS event without affecting others? Public data cannot answer those questions.
The ValueHost Service Promise Is Physical, Not Just Virtual
The ValueHost site is not selling only generic web pages. Its about page describes web hosting, internet applications, CMS hosting, colocation, dedicated-server rental, domain registration and email. The service navigation visible on the same site includes hosting, domains, VDS, colocation, SSL, support and help pages. The public text places the service in the older hosting tradition: shared hosting and domain services on one side, physical server placement and dedicated capacity on the other.
That matters because each service type fails differently. Shared hosting fails through web server load, storage corruption, control-panel faults, account suspension, DNS mistakes and backup restore delays. VDS hosting fails through hypervisor capacity, noisy neighbours, image storage, snapshot policy and control-plane access. Dedicated server rental fails through single-machine hardware faults, replacement stock, remote console reachability and operating-system reinstall paths. Colocation fails through customer hardware, facility access, remote hands, power, cross-connects and support handoffs.
The ValueHost public story includes physical location claims: two Saint Petersburg technical areas, one Moscow area and one San Jose area. It also claims daily backups, backed-up equipment and channels, uninterruptible power supply and several large operators. Those are important statements for a buyer, but they are not the same as a current site list with power design, rack count, maintenance windows, replication topology and customer restore objectives.
The San Jose claim deserves special attention. The directory assignment classifies this slot as US, and AS63258 is an ARIN AS registered to a Delaware organisation. The ValueHost page says one technical area is in San Jose, United States. Yet the public website valuehost.ru resolved during review to 185.67.167.2, and RIPE RDAP for that address places the website IP in a Russian L7Guard 185.67.167.0/24 assignment. That does not disprove a San Jose deployment; it only shows the public website itself is not proof that the Web Hosting, Inc. 104.244.164.0/22 block is used for the main marketing site.
The same DNS check found valuehost.ru and www.valuehost.ru resolving to 185.67.167.2, with nameservers under ns1.valuehost.ru, ns2.valuehost.ru and ns3.valuehost.ru, and MX records pointing to mxs.valuehost.ru, relay.valuehost.ru and mxs2.valuehost.ru. The TCI Whois output for valuehost.ru also shows a long domain history, with a creation date in September 2000 and RU-CENTER as registrar. For resilience, that means the customer-facing domain and mail surface sit in the ValueHost/L7Guard environment rather than on a separate global mail platform.
That choice has pros and cons. Keeping domain, mail and support surfaces within the provider's own environment can simplify control and branding. It can also create a dependency loop: if the provider's own DNS, mail or website path is impaired during an infrastructure incident, customers may lose the very channel they need to ask for help. The public record does not show an externally hosted status page or an out-of-band emergency contact method with current proof of use.
Installed Capacity Is Not The Same As Recoverable Capacity
The visible AS63258 footprint is 1,024 IPv4 addresses. That does not tell us how many servers are installed. A single address may host one website, many virtual hosts, one dedicated server, one NAT gateway, a control service, a mail relay, a nameserver or no customer workload at all. Conversely, a provider can run many internal workloads behind fewer public addresses. Address count is a poor proxy for compute count.
It is still an excellent constraint signal. A provider with only a /22 in the visible AS has to manage public IPv4 capacity carefully. Shared-hosting customers can be packed densely behind a smaller number of addresses. Dedicated-server and colocation customers often expect one or more public IPv4 addresses per server, and sometimes need more for mail, SSL isolation, VPN endpoints or customer segmentation. If addresses are scarce, provisioning and migration policies matter.
Physical recovery is also not visible in the count. A rack may have spare space but no power headroom. A server may be present but not usable because a disk controller is failed. A VDS cluster may have total CPU but not enough safe headroom to evacuate a host. A colocation cabinet may have cross-connect capacity but no remote hands available on a holiday. These constraints separate installed capacity from recoverable capacity.
The ValueHost page's daily-backup claim is useful, but it needs a customer-specific reading. Daily backups can mean file-level copies for shared hosting, image snapshots for virtual servers, configuration backups for control systems, customer-initiated backups, provider-side copies or something narrower. The public page does not state retention, restore time, customer restore rights, backup location, encryption, exclusion rules, failed-backup alerts or whether dedicated and colocated customers are included. A customer should therefore ask exactly what is backed up and how a restore is requested.
The same goes for facility geography. A provider can have several technical areas and still run a given customer in only one. A customer may hear "Moscow, Saint Petersburg and San Jose" and assume multi-site recovery. The public text does not prove that a customer's website, database, mail, VDS or dedicated server is replicated across those places. If a buyer needs regional failover, it should require a design that names primary site, secondary site, replication interval, DNS or routing failover method, testing cadence and restore authority.
For Web Hosting, Inc., the sensible reading is that public evidence supports live hosted capacity, not automatic multi-site resilience. The route table shows current reachability. The service page states physical areas and redundancy claims. The registries show the responsible names. The missing evidence is the conversion layer: how those ingredients become a recovery path for a specific customer at a specific hour.
That conversion layer is where small hosting risk becomes visible. A customer does not buy a route table, a WHOIS record or a broad hosting brand in isolation. It buys a working stack: authoritative DNS that can be changed during an incident, mail routing that does not collapse into the same impaired path, storage that can be restored without negotiating a custom exception, remote access that survives a control-panel fault, and staff who know which cabinet, server and uplink carry the account.
Public records can prove that a provider has ingredients, but they do not prove that the ingredients are assembled into a recoverable service for every plan.
The useful test is therefore account-specific. A shared-hosting customer should ask whether backups include both files and databases, whether restores are self-service or ticket-based, whether restore requests are handled outside business hours, and whether mailboxes are restored with the website or through a separate process. A VDS customer should ask whether snapshots live on the same storage platform as the virtual machine, whether snapshots can be exported, whether rescue access is available if the control panel fails, and whether a failed host can be evacuated without changing IP addresses.
A dedicated-server customer should ask whether spare drives, power supplies and remote console access are on site, and how quickly a full rebuild can be done if the hardware is lost. A colocation customer should ask who can touch the machine, who can ship or receive parts, how cross-connects are ordered, and whether a customer can retrieve equipment during a dispute or long outage.
The same discipline applies to network claims. Two observed neighbours give more surface than one, but the customer still needs to know whether both are active for the assigned prefix, whether traffic is engineered through both paths, whether maintenance on one neighbour has been tested, and whether route-origin validation will improve from an unknown state. A backup route that exists only as a registry possibility is not the same as a live failover path. A carrier relationship that protects the provider's internal network may not protect every customer prefix in the same way.
A provider can be honest about redundancy while still giving a particular customer a single practical failure path.
Billing and account controls deserve the same attention because they often decide whether a technical recovery is usable. If a customer cannot log in, cannot prove account ownership, cannot pay during a bank-card problem, or cannot reach support during a DNS outage, technically healthy servers can still become unreachable to the business. ValueHost's public service mix includes domains, mail, hosting, VDS, dedicated servers and colocation, so a single customer may depend on the same account system for several critical services.
That concentration can be convenient in normal operation and painful during a disputed suspension, expired invoice, compromised account or emergency migration.
The strongest version of Web Hosting, Inc.'s case would be a published or contractually available operating map: which legal entity contracts the customer, which facility or city hosts the workload, which AS and prefix are assigned, which carriers are active, where backups live, what restore times are offered, how incident notices are delivered, and how a customer leaves with data and configuration intact. The public record reviewed here does not supply that map. Until it does, the evidence is enough to justify attention, but not enough to treat the service as self-evidently resilient.
Data Locality Is A Real Question, Not A Marketing Label
The assignment's region field is US because the directory entity is Web Hosting, Inc. and ARIN's public registrant address is in Delaware. The operating picture is wider. ValueHost's public page describes Russian technical areas and a San Jose area. AS40966 is registered in the RIPE region to ZAO Web Hosting in Saint Petersburg. The public valuehost.ru website resolves into a Russian L7Guard address assignment. AS63258 and the HOSTLR /22 sit in ARIN under Web Hosting, Inc.
For regulated or latency-sensitive customers, those distinctions matter. Physical locality asks where the server is powered, cooled and repaired. Network locality asks where the route enters and leaves the provider. Account locality asks which company bills the customer and which law governs the contract. Data locality asks where website files, mailboxes, backups, control-panel records, logs and support attachments are stored. Address locality asks how reputation and geolocation systems classify the assigned IP.
Public records do not let a customer infer all of that from one field. A Web Hosting, Inc. address in ARIN does not prove the server is in the United States. A ValueHost page in English does not prove a US billing entity. A San Jose area claim does not prove a given customer's data is in San Jose. A Russian website IP does not prove the HOSTLR /22 is only used in Russia. The public record points to a transregional operating surface; the customer has to ask for placement commitments in writing.
This is especially important for backup and support access. If a website is hosted in one location but backups are stored in another, data locality changes. If support staff in another jurisdiction can access customer content, data locality changes again. If mailboxes, logs and control-panel records are stored separately from website content, a customer may need a fuller data map than the hosting plan page provides. The reviewed public pages do not publish that map.
Latency-sensitive customers face a separate issue. San Jose may be useful for US West Coast traffic and some Asia-Pacific routes. Saint Petersburg and Moscow may be useful for Russian and nearby regional traffic. But BGP path origin and facility city are not the same thing. Looking-glass paths can show how routes traverse global networks, but they do not prove where the server is located. Customers who care about latency should test from their user regions and should ask which address block and facility will be assigned before committing.
Data sovereignty and locality therefore remain live risks, not automatic negatives. Web Hosting, Inc. may be a reasonable fit for customers who want a particular ValueHost/L7Guard footprint. It is a poor fit for buyers who assume "US" in a directory entry automatically means US-only processing, US-only backups and US-only support access. The public evidence does not support that assumption.
The Main Failure Paths
The first failure path is rack or facility interruption. ValueHost's public text refers to technical areas, power protection and high-speed optical lines. That is a positive baseline, but public pages do not name the facilities, the power topology, the remote-hands provider, the spare-parts arrangement or the maintenance notice practice. If a rack loses power, if a cabinet PDU fails, if cooling is constrained or if a facility limits physical access, customers need to know who can act and how quickly.
The second path is upstream or BGP failure. AS63258 has two observed neighbours, AS3216 and AS40966. If AS3216 has a routing incident, if AS40966 has an internal fault, if the BGP sessions are misconfigured, or if the /24s are filtered, customer workloads can be unreachable even while servers are healthy. The RPKI status being unknown for the visible prefixes is not a downtime signal, but it removes one layer of route-origin assurance that many networks increasingly use for filtering decisions.
The third path is address exhaustion or reputation damage. The HOSTLR /22 is compact. If customers require extra IPv4 addresses, if abuse pressure damages a block, or if a provider needs to renumber a set of servers, options may be limited. A hosting company can mitigate this through careful abuse handling, customer segmentation, clean reverse DNS, and clear address-use policies. The public evidence does not show those policies in detail.
The fourth path is hardware stock. Dedicated servers and colocation depend on parts. A failed disk, power supply, NIC, RAID controller, memory module or motherboard becomes an operational test. Does the provider have compatible spares on site? Can remote staff replace the part outside business hours? Can a customer boot from a rescue image? Is there a tested bare-metal rebuild procedure? Public ValueHost pages say dedicated servers and colocation are offered, but they do not publish hardware replacement targets.
The fifth path is backup and restore. A daily-backup statement is useful only when paired with restore rules. Shared hosting customers need file and database restore. Mail customers need mailbox restore. VDS customers need image or volume restore. Dedicated customers may need separate backup products because provider-level file backups may not cover full-machine state. Colocation customers usually retain more responsibility for their own hardware and backups. The public page does not settle which category receives which protection.
The sixth path is support reachability. If the website, DNS, mail or ticket system is degraded during an outage, a customer needs an alternative channel. The public site exposes support navigation and ValueHost mail/DNS infrastructure, but public evidence reviewed here does not show an independent status page, incident archive or emergency bridge. For a customer running production systems, that is a pre-sales test: open a technical ticket, ask for escalation rules, and verify the response path before there is an incident.
The seventh path is migration. Moving away from a small hosting provider can be harder than moving in. Customers may need content exports, database dumps, mailbox migrations, DNS changes, reverse-DNS updates, application secrets, TLS certificate movement, IP allowlist changes and downtime planning. If the customer uses a dedicated server, it may need a full rebuild elsewhere. If it uses colocation, it may need physical equipment retrieval. Public Web Hosting, Inc. and ValueHost materials do not publish a data-portability commitment.
Who Is Affected When The System Fails
The affected customers are not only generic website owners. ValueHost's own service surface points to corporate clients, individuals, CMS users, domain customers, email users, colocation customers and dedicated-server renters. Each group absorbs failure differently.
A simple website owner may mainly suffer downtime, lost forms, broken checkout or reputational damage. A CMS customer may also face database corruption or plugin-driven restore complexity. A domain customer may lose control if account access, DNS management or billing breaks. An email customer may face delivery failures, lost messages or reputation damage. A dedicated-server customer may lose an entire application stack if a single machine or disk fails. A colocation customer may own the hardware but still depend on facility access, power, remote hands and upstream routing.
The small AS63258 footprint means concentration risk can show up in unexpected places. If the /22 is filtered or damaged, multiple customers can be affected at once. If the provider's own domain or mail path has trouble, support communication can be impaired at the same time as the hosted service. If AS40966 is both an upstream path and part of the wider hosting family, an internal issue there may affect more than one surface. If AS3216 is the main large-carrier path, a carrier-side change can affect reachability outside the provider's racks.
Customers with regulatory constraints face additional exposure. If they assume a US-only deployment because Web Hosting, Inc. is an ARIN registrant, they may be surprised by the public ValueHost footprint. If they assume Russia-only deployment because the site is valuehost.ru, they may overlook the San Jose and ARIN elements. Either assumption can be wrong. The only safe path is to document where service, data, backup, support and billing live.
Customers with low tolerance for downtime should also pay attention to the difference between provider promise and testable proof. A provider can honestly claim backups and redundant channels while still leaving a specific customer with a single-site website, a single database, one server image, one public IP range and manual support recovery. Resilience is not a label on the home page. It is the tested path from failure detection to restored service.
The Best Reading Of The Evidence
Web Hosting, Inc. has enough public evidence to be treated as an active hosting infrastructure company. AS63258 is live. The HOSTLR /22 is directly allocated to Web Hosting, Inc. The visible prefixes are in BGP and in ARIN/IRR consistency views. ValueHost provides a long-running customer-facing service identity with web hosting, colocation, dedicated-server, domain and email claims. Public records connect the L7GUARD name across ARIN and RIPE-region routing records.
The evidence also imposes real limits. The public AS63258 surface is small, IPv4-only in the reviewed routing status and unknown under RPKI validation. Two observed neighbours are visible, but one is the larger outside carrier AS3216 and one is AS40966, a ZAO Web Hosting/L7GUARD AS. The public ValueHost page names Russia and San Jose technical areas but does not publish current rack inventory, facility contracts, power design, physical diversity, hardware stock, restore objectives, status history or migration commitments.
That combination supports a Medium network evidence grade. Stronger grades require proof that the public service claims map to current, tested, customer-recoverable infrastructure. Negative grades would require evidence that the service is inactive, misrepresented or unreachable. The current record sits between those extremes: real infrastructure, real routing, real public service identity, but incomplete operational disclosure.
For buyers, the proper posture is verification. Ask which legal entity contracts the service. Ask where the workload and backups will be placed. Ask whether AS63258 prefixes are covered by ROAs or whether route-origin validation is planned. Ask whether both upstream paths are active for the assigned space. Ask how hardware replacement works for dedicated servers. Ask how backups differ across shared hosting, VDS, dedicated servers and colocation. Ask for an exit path before production data arrives.
In one sentence: Web Hosting, Inc. is a real small hosting network wrapped in the ValueHost/L7GUARD operating surface, but the capacity it sells is still made of racks, power, IPv4 addresses, upstream sessions, backup jobs and human repair windows. The public record proves that the network exists; it does not prove that every customer can recover quickly when one of those layers breaks.