Hivelocity and the operating discipline behind bare-metal cloud dependency

Hivelocity and the operating discipline behind bare-metal cloud dependency

Hivelocity's bare-metal service is also a network-identity dependency. AS29802, registry contacts, peering records, facility-bound subnets, routing controls, and conditional contract mobility determine what can keep running when a server or location changes.

Summary

• ARIN records AS29802 as HVC-AS and identifies HIVELOCITY, Inc. as the registrant; PeeringDB and Hivelocity publish the interconnection and support surfaces around that network.
• Hivelocity documents subnet mobility inside a client account, but subnets remain facility-specific and a deleted subnet is not guaranteed to return.
• The Heng.lu Doctrine test is to preserve accurate network identity and running continuity across server, facility, routing, support, and contract changes without confusing provider-controlled assignments with customer ownership.

The hosting provider has a registry-visible network identity

Hivelocity should not be covered only as a rack, server, or cloud brand. ARIN's RDAP record identifies AS29802 as HVC-AS and links it to registrant handle HVC-3. The entity record names HIVELOCITY, Inc. and exposes administrative, technical, network-operations, and abuse roles. PeeringDB separately publishes Hivelocity LLC's AS29802 interconnection record, including its IRR set, global scope, public exchanges, facilities, and open peering policy.

Those records are not service-quality ratings. They are the public identity layer that helps other operators understand who announces a network, where it interconnects, and which contacts exist when routing or abuse work requires coordination. For a hosted workload, that layer matters because a server is reachable through network identifiers and routing relationships, not through the provider logo.

Provider pages describe the routing surface, not the outcome

Hivelocity's network page publishes a looking-glass and location-based tests, names transit providers by region, and describes direct peering. PeeringDB adds exchange and facility records for AS29802. Together they establish that network operation is central to the service. They do not prove that every customer path takes the lowest-latency route, that capacity is always available, or that a private topology matches the public inventory.

The operational use of these sources is narrower and stronger. A customer can record the expected facility, public addresses, provider ASN, upstream path, peering context, abuse contact, support route, and external probes. During a failure, that record helps separate an application fault from a host, subnet, facility, routing, or provider-control problem.

Subnet identity is portable only inside documented boundaries

Hivelocity's developer documentation says public IPv4 subnets are used for management and hosting, and that subnets in a client account can be moved between servers. The same page defines the limit: subnets are facility-specific, cross-facility movement requires provider involvement, and deleting a subnet does not guarantee that the same subnet will be available later.

This is the article's clearest continuity boundary. Moving a workload to replacement hardware may preserve its address inside the account and facility. Moving to another facility may require coordination. Deleting the assignment may make the old identity unrecoverable. The portal and API can expose which ports, bonds, VLAN interfaces, or other IPs hold the assignment, but the operator still needs a current record before changing it.

Contract portability is not number-resource portability

Hivelocity also publishes a Solution Portability program. It can allow a qualifying customer to carry remaining contract terms into a new Hivelocity service agreement, subject to minimum term, recurring-charge, service-eligibility, migration-cost, financial-review, and approval conditions. That may reduce the commercial friction of changing platforms inside the provider's portfolio.

The wording must remain exact. The program does not grant a right to move Hivelocity-assigned addresses to another provider, and it does not establish customer ownership of those addresses. Contract continuity, server-to-server subnet movement, cross-facility routing, and external provider portability are separate questions. Calling all four portability would hide the control boundary that an operator must manage.

Running-code primacy becomes a change checklist

Before replacing a server, moving a service, or changing its contract, the operator should record the workload hostname, public and private addresses, subnet assignment, facility code, ASN path, DNS dependencies, firewall state, routing configuration, monitoring probes, support contacts, backup location, and rollback target. It should then test what remains stable and what must change.

The key negative tests are concrete. Can a replacement server receive the required subnet without deleting it first? Does a facility move require new addresses or provider routing work? Will DNS time-to-live and certificates tolerate that change? Can external monitoring distinguish a route failure from a host failure? If the account or contract changes, do the support and assignment records remain accessible? These are the running-code facts behind bare-metal dependency.

What the public record does not prove

The cited sources do not establish any customer's workload, private topology, measured latency, outage history, capacity, security outcome, support response time, contract approval, or right to take provider-issued addresses elsewhere. Hivelocity's descriptions of network quality, redundancy, protection, and support remain provider claims unless independent measurements or customer records are added.

The defensible conclusion is still operationally useful. Hivelocity exposes a real hosting and network-identity surface through AS29802, registry roles, peering and facility records, network tests, subnet controls, and contract-change rules. A buyer should judge the service by whether those records stay accurate and whether a tested change plan preserves reachability, support, and rollback when hardware or location changes.

Claims To Exclude

• Hivelocity customers own provider-issued IPv4 subnets
• Hivelocity-assigned subnets are portable to any provider
• Solution Portability is an RIR transfer or external provider portability program
• PeeringDB independently verifies Hivelocity performance, uptime, or capacity
• published transit and peering lists prove every customer route
• ARIN registration proves facility ownership or customer service quality
• a deleted subnet can always be recovered
• the initial BTW 502 proves a Hivelocity infrastructure outage
• Hivelocity contracts or subnets are equivalent to ownership of Internet number resources

Source Register

• RDAP autonomous system record for AS29802: https://rdap.arin.net/registry/autnum/29802 (AS29802 is registered as HVC-AS; the autonomous-system record points to registrant handle HVC-3; the record exposes NOC and registrant roles as operational registry metadata)
• RDAP entity record for HVC-3: https://rdap.arin.net/registry/entity/HVC-3 (the HVC-3 registrant entity is HIVELOCITY, Inc.; the record exposes administrative, technical, NOC, and abuse-role handles; the registry record ties the legal-operational entity to network identity metadata)
• AS29802 - Hivelocity LLC: https://www.peeringdb.com/asn/29802 (Hivelocity LLC identifies ASN 29802 and IRR set AS-29802; the record identifies global IPv4 and IPv6 network scope and an open peering policy; the record lists public exchange points, facilities, abuse contact, and RIR status)
• An intelligent network: https://www.hivelocity.net/about/network/ (Hivelocity publishes a looking-glass and location-based network test surface; the company identifies transit partners by region and describes direct peering; the company exposes network, developer documentation, support, data-center, and service-status paths)
• IPs and Subnets: https://developers.hivelocity.net/docs/ips-and-subnets (servers receive public IPv4 subnets used for management and hosting; subnets can move between servers inside the same client account; subnets are facility-specific and cross-facility moves require provider involvement)
• Solution Portability Program: https://www.hivelocity.net/solution-portability-program/ (qualifying customers may transfer existing Hivelocity contract terms to a new Hivelocity agreement; the new service must meet term and recurring-charge conditions; portability is subject to Hivelocity financial review, approval, service eligibility, and possible migration charges)