VIVID-HOSTING LLC sells hosted capacity that still depends on racks, transit and repair windows

Summary

• VIVID-HOSTING LLC has a verifiable network footprint. ARIN records AS64200 to VIVID-HOSTING LLC, RIPE NCC saw the ASN announced on 12 July 2026, and RIPE's routing-status view counted 60 visible IPv4 prefixes with 24,064 IPv4 addresses.
• Vivid's own site frames the business around managed network attribution, IP transit and security-sensitive customers, while PeeringDB lists the company as a regional network service provider with Any2West presence and facilities at CoreSite Los Angeles sites, I2B SAN02 and Omnis Network Phoenix.
• The public evidence supports active routing and a real support surface, but it does not prove how many servers are installed, who owns every rack, which listed network locations hold customer workloads, what spare hardware exists, or how quickly a customer can recover after a facility, upstream, support, billing or migration failure.
• The strongest buyer diligence is therefore physical and operational: identify the facility and failure domains, separate marketing locations from active capacity, verify transit and RPKI coverage, test backup restoration, and keep a provider-independent migration path for public addresses, data and control settings.

Vivid sells an unusual network product, not just a commodity server

Vivid's public description starts with a different promise from the usual virtual-server catalogue. The Vivid-Hosting homepage presents "safe and secure digital access" for government, law-enforcement and cybersecurity firms. Its first listed service, "Network as a Service", says customers can manage their network footprint and attribution through a secure global network infrastructure. The second listed service is IP transit, described as using Internap as the primary internet transit provider. Those claims are more specific than a simple offer of web hosting or rented virtual machines, because the buyer is not only asking whether a server boots. The buyer is asking whether a network identity, route path and operational support chain behave predictably when the work is sensitive.

The company's history also points to infrastructure rather than only resale. Vivid says its roots go back to 2005 in the gaming industry as a high-performance game-server and network provider for other game-server providers. It says that background pushed the company toward secure, high-throughput and low-latency networks. Its careers page repeats the staff emphasis: network engineering, mobile-telecommunications core networks, RF engineering, penetration testing and cybersecurity research. Those are not proof of a particular rack, but they do make the network service framing plausible.

That framing matters because hosted attribution is a physically demanding product. A customer can see an address, a hostname, a latency result or a managed service account. Behind that are ports, routers, filters, cross-connects, carrier relationships, billing records, abuse queues, remote hands and servers that must be repaired by a person or by automation built by people. The public service language implies customers who may care about separation, reputation, location, attribution consistency and confidentiality. For those customers, capacity failure is not only downtime.

It can break an investigation environment, expose an operational pattern, strand a research appliance, or make a customer's own downstream users unreachable.

The website also gives a first warning about evidence limits. It lists network locations in Los Angeles, San Diego, Phoenix, Chattanooga, Vancouver, Mexico City and Sao Paulo. It displays logos for CenturyLink, INAP and Spectrum Enterprise under a "backed by top tier providers" banner. PeeringDB and routing data support parts of this geography and carrier story, especially in Los Angeles and other transit-adjacent paths, but the public record does not show a live inventory for each city.

A city on a network page can mean owned racks, colocated equipment, leased capacity, transit availability, a partner site, a router-only location, or a past footprint still present in marketing copy. A customer should not convert the list into guaranteed workload placement without a current service order and a failure-domain map.

Vivid's public policy page creates a real commercial surface. The privacy and policy page refers to orders, support tickets, customer accounts, account suspension, a full 30-day satisfaction guarantee for many products, repair or replacement where products are not in working condition, and no refund term for services related to cellular infrastructure once licences or credentials are assigned. It also gives a La Jolla contact address, support email and phone number. Those details show that Vivid is not only a BGP label. They do not state uptime objectives, backup retention, restore targets, spare-hardware commitments, maintenance notice windows or data-export rights.

That is the shape of the diligence problem. Vivid has enough public evidence to be studied as an active network service provider. It does not publish enough to let a buyer infer that any given virtual server, attribution node or hosted service sits in a specific rack with a specific recovery commitment. The article therefore treats the service as a real network footprint with a bounded public operating record, not as a fully transparent cloud region.

AS64200 is active, but routes are not server inventory

The clearest durable asset is the autonomous-system record. ARIN's AS64200 RDAP reference, also visible through ARIN Whois, names VIVIDHOSTING, records a 20 August 2015 registration date and ties the AS to VIVID-HOSTING LLC. The organization record at ARIN entity VL-426 gives a La Jolla, California address, a 24 August 2021 organization registration date, and support, abuse, routing, DNS and network-operations contacts at Vivid's domain. Two direct IPv4 allocations are especially visible: 199.188.88.0/21, registered in 2012, and 192.154.192.0/21, registered in 2013 and updated in 2024.

Current routing evidence is also strong at the control-plane layer. RIPE NCC's AS overview for AS64200 identified the holder as "VIVIDHOSTING - VIVID-HOSTING LLC" and showed the ASN announced on 12 July 2026. RIPE's routing-status view counted 60 visible IPv4 prefixes containing 24,064 IPv4 addresses, with full IPv4 collector visibility at the query time and no visible IPv6 prefixes. RIPE's announced-prefixes view included the direct Vivid block 199.188.88.0/21, more-specific routes such as 199.188.94.0/24 and 199.188.95.0/24, and a mix of other IPv4 ranges.

Those numbers are useful, but they are not a server count. Twenty-four thousand visible IPv4 addresses do not say how many are assigned to customers, how many sit on routers or infrastructure, how many are held for reputation separation, how many are leased from other holders, or how many correspond to active machines. A single server can hold many public addresses. A single public address can front many services. A route can be visible while the host behind one address is down. Conversely, a server can be working while a public route or firewall rule breaks reachability.

The distinction is especially important for Vivid because the product language is about network identity and attribution. Address space may be used as part of a managed network surface rather than a simple one-address-per-virtual-machine plan. That can be legitimate and valuable, but it makes installed capacity harder to infer from the routing table. A customer needs to know how much compute, storage, port capacity and address inventory is actually reserved for the ordered service, not merely how much address space appears under AS64200.

RIPE's routing history for 199.188.88.0/21 saw the prefix with AS64200 from September 2015 through 12 July 2026 in the queried history. The direct Vivid block is therefore not a one-day route. RIPE's history for the 192.154.192.0/22 more-specific route saw that route under AS64200 from July 2021 through the same end date. Long-lived visibility supports the view that AS64200 is an operating network, not a dormant registration.

But long-lived visibility still leaves the physical estate open. It does not reveal whether a new customer instance can be placed today, whether a particular node is backed by local SSDs or shared storage, whether spare servers are on site, whether Vivid owns or leases the equipment, or whether an address pool is allocated to a research product rather than general hosting. NIST's cloud-computing definition describes pooled networks, servers, storage, applications and services; the pool is the point. Vivid's public route table proves that some network resources are active. It does not describe the pool behind an order.

Capacity should therefore be divided into three layers. The first is advertised route capacity: which prefixes are visible, which origins are valid and which upstreams carry them. Vivid does well on basic visibility for IPv4. The second is installed infrastructure: servers, storage, switches, power feeds and facility space. Public evidence is partial. The third is usable customer capacity: what remains free, tested and contractually available after redundancy, maintenance and other tenants are considered. Public evidence does not answer that layer.

This is where a serious buyer's question should get concrete. How many active customer failure domains exist for the product being ordered? Can a customer buy anti-affinity across hosts, racks or sites? Is the service delivered from AS64200-owned addresses, assigned customer addresses, partner space or another upstream's address plan? What happens if the customer needs additional addresses? Does Vivid support native IPv6 for the service, given that PeeringDB says the network supports IPv6 while RIPE's current view saw no visible IPv6 prefixes? These are operational questions, not procurement formalities.

The safest conclusion is balanced. AS64200 gives Vivid a real and visible internet edge. The size and history of that edge make the company materially more observable than a host with only a domain and a payment form. The route table, however, is still a map of reachability, not an inventory of racks or recovery capacity.

Facility evidence is strongest in Los Angeles, but rack control remains a separate question

The facility trail begins with PeeringDB. The PeeringDB network profile for AS64200 lists Vivid-Hosting, LLC as a network service provider with regional scope, heavy outbound traffic, 10-20Gbps traffic, 115 IPv4 prefixes, one IPv6 prefix in the profile metadata, one exchange point and four facilities. Its facility records list CoreSite LA1 One Wilshire, CoreSite LA2, I2B SAN02 in San Diego and Omnis Network Phoenix in Tempe. Its exchange record lists a 10Gbps Any2West entry at IPv4 address 206.72.211.42.

That is meaningful infrastructure context. PeeringDB is a community-maintained database rather than a facility lease, but network operators use it to publish peering and interconnection details. The listed Los Angeles sites also fit Vivid's own network-location list. CoreSite's Los Angeles data-center page describes a downtown Los Angeles campus that includes LA1 at One Wilshire and LA2, with access to more than 325 networks, global carriers, subsea cables and public-cloud connectivity. That makes Los Angeles a plausible hub for Vivid's interconnection story.

The site-level evidence still needs careful wording. A PeeringDB facility record says Vivid has listed a presence at a facility; it does not show the cabinet count, power density, cross-connect count, contract status, remote-hands entitlement or which customer workloads sit there. A CoreSite market page describes CoreSite's facilities; it does not prove the details of Vivid's racks inside them. A customer needs a current statement from Vivid about where the ordered service runs, which facility is primary, which facility is backup, and whether customer workloads can be pinned to or excluded from a site.

The other listed facilities broaden the same question. Omnis describes itself as a Tempe, Arizona provider of colocation, dedicated servers, virtual servers, cloud shared hosting and domain services on its public homepage, and PeeringDB lists Vivid at "Omnis Network Phoenix" with a Tempe city field. That could indicate a real Phoenix-region infrastructure dependency. It could also indicate peering, colocation, legacy presence or another arrangement that does not host the service a particular customer buys. The public record does not separate those cases.

The San Diego entry is similar. Vivid's own network page lists San Diego, and PeeringDB lists I2B SAN02. The public evidence establishes a declared facility presence; it does not establish that every San Diego-listed service is available, that there is spare capacity, or that Vivid has independent recovery from Los Angeles to San Diego. A buyer should ask whether San Diego is a production service site, a network node, a transit point, a historical record or an available paid option.

Physical dependency also includes power and maintenance. A virtual service does not fail only because a virtual machine fails. A rack power strip can trip. A top-of-rack switch can crash. A building can schedule electrical work. A carrier can move a cross-connect. A remote-hands queue can lengthen during a shared incident. If Vivid colocates in another operator's facility, the first repair step may be a ticket to that facility operator. The customer sees one service provider; the repair path may include Vivid staff, facility staff, carrier staff and a hardware vendor.

This matters most for "network attribution" customers because the service may depend on continuity of identity. If a site outage forces a replacement address or a move to another geography, the customer's research environment, access list, account reputation or latency pattern can change. If the service is being used by a cybersecurity team, law-enforcement unit or government contractor, a surprise change in location or path may be more than a performance issue. It can affect the evidence chain around how a system was accessed, which logs apply, and which parties had operational control.

The article therefore treats Los Angeles as the strongest publicly evidenced facility market for Vivid, not as proof of customer workload placement. PeeringDB and CoreSite identify a credible interconnection footprint. The actual rack, power, hardware and recovery commitments still need to be confirmed for the specific service.

Transit diversity is visible in BGP, but it is not the same as independent repair

Vivid's public site names Internap as the primary internet transit provider for IP transit. The RIPE view of AS64200 shows a wider set of observed neighbours. RIPE's ASN-neighbours result listed 18 unique observed neighbours on 12 July 2026, including Cogent AS174, CenturyLink/Qwest AS209, Transtelco AS32098, Level 3 AS3549, Hurricane Electric AS6939, AT&T AS7018, GSL Networks AS137409, EdgeUno AS7195, AARNet AS7575, Angola Cables AS37468 and Convergenze AS39120. RIPE also recorded one right-side neighbour entry for AT&T and several uncertain entries.

That is a richer route environment than a single-homed small host. It means public route collectors see AS64200 reached through several large and regional networks. RIPE's looking-glass result for 199.188.88.0/21 showed sample paths ending directly in AS64200 through multiple upstream tails, including paths through Cogent, CenturyLink and AT&T. A similar looking-glass result for 192.154.192.0/22 showed comparable variety. This supports the conclusion that AS64200 has multiple public routes into the global table.

But a list of observed BGP neighbours is not a resilience guarantee. BGP shows route advertisements and AS paths. It does not show whether two circuits enter the same building through different ducts, whether two upstream sessions terminate on the same router, whether a cross-connect is protected, whether a commercial contract is current, whether all prefixes are accepted by all upstreams, or whether failover has been tested during a real maintenance window. The BGP specification, RFC 4271, defines how autonomous systems exchange route information; it does not certify the underlying fibre, power or support arrangement.

It is also possible for a network to have many upstream paths while a particular service remains concentrated. A route may fail over, but the server can still sit in one rack. A rack may have redundant power, but the cross-connect can be single. A facility may have many carriers, but the customer service may be pinned to one upstream for policy, cost or attribution reasons. A BGP map is strongest for reachability, weaker for service placement and weak for hardware recovery.

The direction of the route matters as well. The public control-plane may show how outside networks reach AS64200, while customer traffic behaviour depends on Vivid's outbound policy, packet filters, source-address controls and upstream acceptance. PeeringDB reports a heavy-outbound traffic ratio for Vivid. That is consistent with a network that sends substantial traffic from hosted or managed nodes, but it does not describe the product mix, packet-loss budget, port commitment or rate-limit policy.

Transit diversity can also be uneven by prefix. RIPE's visible route list includes both Vivid's direct ARIN allocations and other originated prefixes that require separate ownership and authorization checks. RPKI coverage is not uniform across representative routes. Some direct Vivid blocks validate cleanly for AS64200; other visible routes returned unknown in RIPE's validation result. That does not make those routes illegitimate. It does mean a customer cannot assume every prefix under the ASN has the same routing-security posture.

The repair implication is simple. If Cogent has a regional issue but AT&T and another upstream carry the route, reachability may survive. If the top-of-rack switch, cross-connect or facility power feeding the Vivid router fails, upstream diversity may not help. If a route filter removes a single prefix, some services may fail while the ASN stays broadly healthy. If an address used for managed attribution is blackholed due to abuse handling, the network can remain online while that customer's identity surface changes.

A buyer should therefore request route and facility diversity in the same document. The useful evidence is not "we have multiple carriers" alone. It is which carriers are available for the ordered prefix, which facility and router each session uses, whether automatic failover is configured, which prefixes have valid ROAs, which route filters rely on IRR objects, how blackhole requests are handled, and what happens during scheduled carrier work. Vivid's public routing record suggests the company can have that conversation. It does not publish the answers for an individual service.

Routing-security evidence is good for direct blocks and incomplete for the whole edge

For Vivid's two direct ARIN blocks, the route-origin evidence is helpful. RIPE's RPKI validation for 199.188.88.0/21 returned valid, with a validating ROA for 199.188.88.0/21 and maximum length /24. RIPE's RPKI validation for 192.154.192.0/22 also returned valid, using a ROA for the broader 192.154.192.0/21 with maximum length /24. That matters because Vivid announces both aggregate and more-specific routes from those allocations.

ARIN's RPKI service page explains the role of Route Origin Authorizations: a holder can make a cryptographically verifiable statement that an AS is authorized to originate a prefix. The RPKI architecture, RFC 6480, describes the resource certificate system behind that model. Valid origin data reduces one class of routing error and hijack risk. It is a real positive signal for the direct Vivid space.

The limit is equally important. RPKI origin validity answers a narrow question: is this AS authorized to originate this prefix at this length? It does not authenticate the entire AS path, guarantee availability, prove that a server is in a named facility, or prevent a route from being withdrawn by mistake. A valid route can lead to a powered-off host. A valid route can disappear during a router outage. A valid route can still carry traffic through a congested upstream.

Internet Routing Registry data adds another layer. ARIN's IRR page describes IRRs as repositories containing information about ASNs and routing prefixes that can be used by providers to build route filters. RIPE's AS routing-consistency view showed many AS64200 routes appearing both in BGP and route registries, and also showed registry-listed prefixes not visible in BGP. That is normal enough for a network with changing customer, leased or historical routes. It is also why registry entities alone should not be treated as current capacity.

RPKI and IRR together are route hygiene, not business continuity. They can help stop an unauthorized origin or make filters more predictable. They do not settle who pays for transit, who can enter the rack, who responds to a failed disk, or how a suspended customer recovers data. A buyer should still ask for a prefix-specific routing statement: origin ASN, authorized maximum length, upstream acceptance, blackhole policy, IRR objects, reverse-DNS process and emergency route-change contacts.

Reverse DNS belongs in that operational bundle. ARIN's reverse-DNS guidance explains that reverse mapping is a resource-management function. For customers using Vivid addresses, reverse DNS can affect mail deliverability, security tooling, telemetry and reputation. If Vivid controls reverse zones, a migration or emergency address change may require Vivid staff. If a customer controls them through delegation, exit is easier. The public article cannot determine the customer-level arrangement.

Public DNS for Vivid's own site is straightforward at the moment of observation. A DNS query for vivid-hosting.net returned A address 199.188.88.149, and www.vivid-hosting.net resolved to the same address, while no AAAA answer was returned in local queries. Certificate Transparency entries for vivid-hosting.net on crt.sh show current and recent certificates from Let's Encrypt and Cloudflare-related issuance. These are modest continuity signals for the corporate web presence. They do not prove product availability, customer count or the health of any hosted node.

The operational takeaway is not that Vivid is weak. It is that route hygiene and service recovery live on different layers. Vivid's direct address space has visible origin validation. The wider AS edge contains a mixture of route sources, customer or partner-looking ranges and changing public records. A risk-sensitive customer should require both routing-security evidence and non-routing recovery evidence before relying on the service.

Support and policy records show contact points, not restoration targets

Vivid publishes more customer-policy material than many small infrastructure providers. The policy page names support tickets, customer accounts, account suspension, abuse restrictions, payment processing, order delivery, repair or replacement, refunds for many products within 30 days, and immediate termination for unauthorized chargebacks. It also says cellular-infrastructure services have no refund term due to the nature of the product and are considered delivered when licences or user credentials are provided. The same page gives [email protected], [email protected] appears in ARIN Whois, and the published phone number matches ARIN's support and abuse contact number.

Those contact points matter. They show where customers and complainants can start when a service is unreachable, abusive traffic appears, an account is locked, or credentials do not arrive. ARIN's AS and organization records also publish separate roles for support, abuse, routing, DNS and network operations. Role separation is useful because a routing incident, abuse complaint and billing lockout require different authority.

The policies do not disclose restoration targets. There is no public service-level objective for virtual servers, network attribution nodes, transit ports, DNS changes, support acknowledgement, host replacement, cross-connect repair, route restoration or data recovery. There is no public status archive showing past incidents and repair times. There is no public maintenance calendar. The policy says Vivid may suspend or terminate accounts for prohibited activity, but it does not state how a legitimate customer preserves data during a dispute or how false-positive abuse reports are handled.

That missing detail changes how a customer should read "repair/replace". A defective delivered product can be repaired or replaced in many ways. For a physical server, repair could mean swapping a drive, replacing a power supply, rebuilding on another machine or issuing new credentials. For a network attribution product, replacement could mean a new endpoint, a new address, a new subnet or a new route. Each replacement has a different operational effect. If a research team has built allowlists, reputation, monitoring or chain-of-custody notes around an address, a simple replacement may be disruptive.

Abuse handling is another failure path. Vivid's acceptable-use terms prohibit spam, denial-of-service activity, unauthorized access and other harmful behaviour. That is standard and necessary for a network with hosted customers or managed access. But abuse reports can be noisy, stale or malicious, and security research can be misread by third parties. A provider serving cybersecurity and law-enforcement customers needs a well-defined process for preserving legitimate work while stopping harm. Public policy language does not show that process.

Billing and account access are also infrastructure dependencies. If a chargeback, fraud hold or payment-system issue triggers suspension, customer workloads can become unreachable even though every router and server is healthy. If the only management portal or support path fails, a customer may be unable to reboot, export or migrate. Vivid's policy page references account login and support tickets; it does not state whether emergency support remains available during account disputes or outages.

The human layer is especially exposed during regional incidents. A facility or transit event in Los Angeles could create simultaneous tickets from many customers. If Vivid relies on a small engineering team, an upstream network and remote hands, the customer wait depends on queue order and authority boundaries. A published escalation matrix would help: which number handles routing, which handles abuse, which handles facility access, which handles billing, and which has 24-hour authority to approve a replacement or route change.

For customers, the diligence question is practical. Ask for acknowledgement and restoration targets by failure type. Ask whether support can reach the facility at all hours. Ask whether Vivid keeps spare hardware in each active service location. Ask what information a customer receives during an outage. Ask whether a customer can export data while an account problem is being resolved. Public contacts are necessary. They are not enough to price recovery.

Failure can cross route, rack, address reputation and customer data at once

The visible route is only one layer of a Vivid service. A customer-facing outage can begin in the guest system, a hypervisor, storage, a switch, a router, a carrier, DNS, billing, abuse handling or facility power. The symptom may be the same: a managed endpoint or hosted server stops responding. The remedy depends on which boundary failed.

At the smallest layer, one guest operating system can crash while the host and route remain healthy. A reboot, console action or replacement image may be enough. A host failure affects all services on that physical machine and requires spare compute, shared storage or hands-on repair. A storage failure can corrupt or slow many machines. A rack power or switching problem expands the blast radius again. A facility event can remove an entire site from service.

The route layer can fail while the server remains healthy. A prefix can be withdrawn, filtered, blackholed, de-preferenced or misannounced. An upstream can accept one Vivid prefix and reject another. An RPKI-valid origin can still disappear because a router is down or a policy was changed. A public BGP view can show AS64200 as healthy while one customer address is unreachable due to a route, firewall or abuse mitigation action.

Address reputation is a special concern for Vivid's published market. Managed attribution and cybersecurity research can depend on how an address is perceived by remote systems. An address may be technically reachable but blocked by a third-party firewall, fraud engine or reputation list. Public reputation services can be wrong or stale; they should not be used as proof of customer behaviour. Still, they can affect whether a customer's work succeeds. The operational question is how Vivid assigns addresses, rotates them, investigates complaints and protects uninvolved customers from a neighbour's conduct.

Data can be trapped by any of those failures. A hosted virtual machine can be reachable only through Vivid's network. A snapshot can live in the same facility as the failed host. A backup can be attached to the same customer account that has a billing or abuse issue. A public IP address from Vivid's allocation cannot normally move with the customer to another provider. If the customer built allowlists, certificates, partner integrations or telemetry around that address, a sudden move requires coordination beyond copying files.

NIST's storage-security guidance separates replication, backups, snapshots, immutability and restoration assurance. That separation is useful here. Replication can copy corruption. A snapshot can sit inside the same failure domain. A backup can be complete but unusable if keys or credentials are lost. A restoration test is the evidence that the copy can rebuild service. CISA's ransomware guide recommends encrypted offline backups and regular restoration tests because reachable backups are often attacked or lost with production systems.

For Vivid customers, the backup question should be phrased in failure-domain terms. Where is the copy stored? Does it leave the primary rack and facility? Who controls the encryption keys? Can the customer retrieve a full disk image without a working Vivid server? How long does Vivid keep cancelled or suspended data? What changes if the primary address is unavailable? Is restore bandwidth limited? Which staff can perform the restore during a regional incident?

NIST's contingency-planning guidance emphasizes alternate equipment and alternate locations. Applied to Vivid, the minimum useful test is not a diagram. It is a timed rebuild of a representative service from a copy outside the primary failure domain, with new or recovered addresses, DNS updates, credentials, logs and customer validation. If the product is managed attribution rather than a conventional server, the test should also verify whether the restored environment preserves the expected identity, geography and route characteristics.

The failure path also affects innocent third parties. A government or security customer may lose a research environment. A hosted application may be unavailable to end users. A remote network may continue to receive traffic that it considers suspicious. An abuse desk may need to identify a responsible customer without exposing unrelated tenants. A facility operator may need to approve remote hands before Vivid can repair a machine. These parties are connected by the service, even if the customer contract names only Vivid.

That is why the most useful continuity evidence is operational, not rhetorical. Vivid can show active routing, published contacts and declared facility presence. Customers still need tested backups, clear data-export terms, site separation, address-change procedures, abuse escalation and account-continuity rules before treating the service as resilient.

Geography and locality require more than a US address and a city list

The assignment labels the service area as US, and Vivid's ARIN organization address is in La Jolla, California. Vivid's own network list, however, is broader: Los Angeles, San Diego, Phoenix, Chattanooga, Vancouver, Mexico City and Sao Paulo. PeeringDB facility entries support Los Angeles, San Diego and Phoenix-region claims more directly than the other cities. RIPE route collectors show a globally visible AS, not a workload-location registry.

That difference matters for data sovereignty and locality. A customer may care whether compute runs in California, Arizona, Tennessee, Canada, Mexico, Brazil or somewhere else. A registry country code, company address or network map cannot answer that. A router can sit in one city while servers sit in another. A backup can be copied to a different jurisdiction. Remote support can access systems from another country. Logs, billing records and monitoring data can follow separate systems from the customer workload.

The same caution applies inside the United States. A workload in Los Angeles and a backup in Phoenix may meet one customer's locality needs and fail another's. A Los Angeles peering point can improve latency to Pacific routes but does not prove the data is stored there. A city list may describe network reach rather than storage geography. A customer handling regulated data, sensitive research or government work needs a written statement of primary compute location, backup location, support access and subcontractors.

The IPv6 mismatch is another locality and access issue. PeeringDB's profile says Vivid has IPv6 capability and one IPv6 prefix in profile metadata, but RIPE's 12 July 2026 routing-status view saw zero visible IPv6 prefixes for AS64200. RIPE's older history includes historical IPv6 visibility for 2607:6b80::/32, but current public visibility in the checked routing-status result was absent. A customer should not infer native IPv6 availability from an old or profile-level entry. If IPv6 is required, it should be ordered, tested and documented for the specific service.

DNS evidence points to the corporate web property rather than customer locality. Local DNS queries returned 199.188.88.149 for vivid-hosting.net and www.vivid-hosting.net, an address inside Vivid's direct 199.188.88.0/21 allocation. That shows the company uses its own address space for its public site at the query time. It does not prove where the server sits, whether it shares infrastructure with customer products, or whether the same controls apply to managed network attribution nodes.

Locality also includes legal and operational authority. If Vivid colocates in CoreSite LA1 or LA2, CoreSite's facility rules, access procedures and maintenance windows become part of the practical operating surface. If a service uses Omnis Network Phoenix or another partner location, that operator's procedures matter as well. If Vivid buys transit or remote-hands service from a supplier, the supplier's incident process can affect the customer without being visible on the invoice.

For a customer, the right request is not a slogan about US service. It is a location schedule: primary facility, secondary facility, country and state, facility operator, whether Vivid owns or leases hardware, whether backups leave the state or country, whether support access crosses borders, and what happens during failover. Vivid's public materials give enough locations to raise the question. They do not provide enough detail to settle it.

That does not make the service unsuitable. A distributed network provider can legitimately offer multiple locations and specialized routing. It does mean data-sovereignty claims should be service-specific. The public evidence supports a US-based legal and ARIN resource holder with declared Americas locations and strong Los Angeles interconnection evidence. It does not support a blanket claim about where every customer byte, log or backup remains.

The economics favour a shared network edge, but customers need to price the hidden layers

Vivid's public footprint fits the economics of a specialized network provider. The company runs an AS with many visible IPv4 routes, declares a small number of facilities and one public exchange presence, and sells network identity and transit-oriented services to customers that may value performance and attribution more than raw virtual-core pricing. That model can create real value. It can also make the cost boundary harder to see.

A shared edge spreads router, transit, monitoring and engineering costs across customers and products. Vivid's PeeringDB profile lists 10-20Gbps traffic and heavy outbound ratio; RIPE sees many upstream paths. If those records reflect current operations, Vivid can amortize border routing across more than a handful of machines. That is why a specialized provider can offer managed network services without building a hyperscale cloud.

But aggregation also concentrates some risks. A route-policy mistake at AS64200 can affect many prefixes. A facility problem at a key Los Angeles site can affect customers who believed they had geographically diverse network identities if those identities actually share a rack, switch or power path. A limited support team can become a bottleneck during a multi-customer incident. A provider contract or payment problem can affect service even when customer equipment is healthy.

The pricing question is therefore not only "How many cores and how much memory?" It is "Which failures are included in the service, and which are left for the customer to absorb?" A low monthly price can be rational for disposable research nodes or non-critical workloads. It is not enough for systems that need proven recovery, stable address reputation, jurisdictional assurance or fast replacement. The customer should compare the full recovery package, not only the advertised network feature.

Hidden layers include spare hardware, remote hands, backup storage, route engineering, abuse response, customer migration, DNS changes and account continuity. If those are included, Vivid should be able to describe them. If they are excluded, customers can still buy the service for the right workload, but they must maintain independent copies and a tested exit plan. Ambiguity is the expensive state because it moves the cost into the outage.

The address market adds another economic pressure. Vivid's direct IPv4 allocations are valuable and finite. The current AS route set includes direct space, more-specific routes and other originated prefixes. A customer that needs dedicated addresses, clean reputation separation or long-term address continuity should ask how Vivid allocates and reclaims addresses, whether addresses are shared among products, how reverse DNS is managed, and what happens when a customer leaves. Public IPv4 addresses rarely travel with a normal hosting customer.

Hardware capacity is similarly finite. If Vivid offers high-performance, low-latency or attribution-specific nodes, the limiting part may be not the route table but a particular server family, network card, storage tier, facility port, or location-specific rack. Installed equipment can be full even when address space remains. A spare address is not a spare server. A spare server is not necessarily a spare low-latency node in the correct city.

This is where Vivid's public record is strong enough to invite specific procurement questions. AS64200 is live. Direct blocks are origin-valid. PeeringDB lists credible facilities. The site describes network-oriented products and support channels. A buyer can therefore ask for precise commercial terms rather than wondering whether the network exists. The unresolved issue is what the published network footprint buys under stress.

What would turn the footprint into a fully verifiable service

Vivid's strongest public evidence is network evidence: an active AS64200, direct ARIN allocations, long-lived RIPE visibility for key prefixes, valid RPKI origin authorization on representative direct blocks, multiple observed upstream paths, PeeringDB facility records and an Any2West entry. Its own website adds an unusual and specific product story around managed network attribution, IP transit and security-sensitive customers. This is enough to treat Vivid as a real infrastructure company with an operating edge.

The weaker evidence concerns the product behind the edge. Public pages do not identify the rack count, installed server inventory, power design, storage architecture, backup-retention policy, restore testing, status history, support-service levels, customer migration rights or current availability in each listed city. PeeringDB facility entries are useful but not a customer placement guarantee. RIPE routes are useful but not spare capacity. Policy pages are useful but not recovery commitments.

The most valuable next disclosures would be practical. A facility statement could name active service locations, distinguish router-only sites from compute sites, identify facility operators and state whether customers can buy anti-affinity across hosts, racks or cities. A network statement could list active upstreams by location, route-filter policy, RPKI coverage, blackhole procedure, IPv6 availability and maintenance notice practice. A capacity statement could describe server families, storage tiers, port commitments and spare-hardware targets without revealing customer identities.

Recovery evidence should be measured rather than promised. Vivid could publish or provide a sample restore result: a representative server rebuilt from backup outside the primary failure domain, with elapsed time, data-loss interval, address changes and manual steps. It could state whether snapshots are exportable, whether full disk images are available, how long cancelled data is retained, and whether emergency data export remains possible during billing or abuse disputes. For attribution services, it could also explain what aspects of network identity survive a recovery.

Locality evidence should be service-specific. The useful answer is not simply that Vivid is a US company. It is where compute runs, where backups sit, who can access systems remotely, which subcontractors touch the service, and what changes during failover. If a customer needs Canada, Mexico, Brazil or a US-only service, the location list needs to become an orderable and testable placement statement.

Customers can act before such public disclosures exist. They should run their own portability test, maintain independent backups, keep DNS time-to-live values low where appropriate, document firewall and allowlist dependencies, export configuration, test address change procedures and treat Vivid-provided public addresses as non-portable unless a contract says otherwise. They should also request outage communications that name the affected layer: host, rack, facility, upstream, route, DNS, account, abuse or billing.

The fair operating judgement is therefore positive but qualified. Vivid has a visible network, a long-running AS and a clearly differentiated service story. The visible edge makes it more concrete than many small hosting names. The public record does not yet show enough about racks, power, usable compute, backup restoration and support escalation to treat hosted capacity as automatically resilient. When a Vivid service works, the customer sees a controlled network surface. When it fails, the repair still has to pass through physical sites, route policy, supplier obligations and human response.

That is the hidden infrastructure inside the hosted promise.