Summary
- WIX CLOUD COMPANY LIMITED can be tied to Vietnamese tax identifier
0317290315, a May 2022 company date, a Ho Chi Minh City address and legal representative Dau Khac Nam. APNIC records from August 2023 repeat the exact English company name, the same address and Dau Khac Nam as the administrative contact for AS150879 and103.15.88.0/23. - The company's own AS150879 had no IPv4 or IPv6 announcements visible to RIPEstat on July 15, 2026. Its allocated
/23was nevertheless visible to 325 of 326 IPv4 observation peers, originated by AS150698 rather than AS150879. Using another origin can be legitimate, but the reviewed public record does not explain the authority, control or commercial relationship behind this arrangement. - The current APNIC entry for AS150698 names Chandpur Online Systems in Bangladesh and dates that registration to June 2026, while other network indexes still label the ASN as the Vietnamese VCORE network. That mismatch is evidence of changing or lagging registry context, not evidence of wrongdoing. It makes a current letter of authorisation, route inventory and responsibility schedule important.
- The route has no validating Route Origin Authorisation, and the public service surface is thin. The contact string
[email protected]is a Gmail address;wixvz.comhad no active DNS or.comregistration at review. No operator site, product schedule, SLA, backup policy, data-location statement or accountable support queue was established from the reviewed material.
A company record is the start of assurance, not the end
Cloud services are bought through a stack of promises that the word "cloud" tends to compress into one reassuring label. A buyer is asked to assume that a legal company will take the order, that an operating team controls the advertised infrastructure, that addresses and routes will remain usable, that customer data will stay where the contract says, and that somebody with authority will respond when the service fails. Each of those propositions can be true. None follows automatically from the company name.
WIX CLOUD COMPANY LIMITED illustrates the distinction unusually clearly. There is a real identity trail. Vietnamese company-information indexes connect the domestic name Cong ty TNHH Wix Cloud to the English name WIX CLOUD COMPANY LIMITED and tax identifier 0317290315. They give May 13, 2022 as the company date, Dau Khac Nam as legal representative and an address on the first floor of Block B at Flora Novia, 1061 Pham Van Dong, in Ho Chi Minh City. The registered activities include computer programming, computer consultancy and systems administration, information-technology services, data processing and hosting-related activity. Those details are consistent with a technology company rather than a random name match.
Internet-number records add a second layer. In August 2023, APNIC registered AS150879 under the name WIXCLOUD-VN and allocated the portable IPv4 block 103.15.88.0/23 under the same label. Both records repeat the company name and Flora Novia address. The ASN names Dau Khac Nam as the administrative contact and Dau Khac Trung as the technical contact. The alignment of name, address and personnel makes it reasonable to connect the legal company to the number resources.
The difficulty begins after that connection. A cloud buyer does not consume a company registration or an ASN entry. It consumes a working service. At the review date, the company's ASN was not visible as an origin for any route. The company's address block was active, but under another ASN. The registry contact did not lead to an active branded domain, and the reviewed public material did not supply the commercial and operating documents that would connect a route to a customer obligation.
That does not make the records worthless. It makes them precise. They prove that a company identity acquired identifiable internet resources. They show that the IPv4 block is reachable today. They do not prove who provisions systems on the block, who contracts with customers, where the machines sit, what is backed up, or who owes a remedy after an outage. Operating assurance begins by refusing to make one kind of record answer a different kind of question.
The legal identity is specific, but its current status needs direct confirmation
The company indexes provide enough detail for a counterparty check. Tax identifier 0317290315 is more useful than a stylised brand because it can be placed on a quotation, invoice and contract. The legal representative and registered address can be compared with signed documents. The listed activities are broad enough to encompass software, systems work, data processing and hosting. A procurement team can therefore ask a concrete question: is this exact legal company the party selling and supporting the proposed service?
The same indexes also introduce a caution. Recent third-party presentations mark the company as not operating at its registered address. That wording is an administrative status reported by an index; it is not the same thing as a court finding, a liquidation notice or proof that no business is conducted elsewhere. The reviewed sources did not include a fresh certified enterprise-registration extract or a direct tax-authority confirmation. It would be irresponsible to turn the index flag into a claim that the company has ceased to exist.
It would be equally unwise to ignore it. A registered-office discrepancy matters because notices, invoices, compliance requests and litigation all depend on a reachable legal party. A provider can settle the issue with ordinary documents: a current company extract, current tax status, the operating address, the name of the authorised signatory and an explanation of any relocation or address correction. If another company now supplies the service, the order should name that company and explain its authority to use the WIX Cloud resources.
The distinction between an address and an operating site is also important. The Flora Novia address appears in the legal and APNIC records, but nothing reviewed identifies it as a datacentre. An administrative address can be perfectly valid without housing routers or servers. Conversely, infrastructure can be operated in a carrier facility while the legal company uses an office elsewhere. Buyers should not infer server location, physical security, power resilience or support staffing from a registration address.
The legal record therefore earns WIX CLOUD COMPANY LIMITED a place in a diligence file, not a presumption of current delivery. It tells a buyer which identity to verify. It also supplies the fields against which the quote, beneficiary account, tax invoice and service contract should be matched. If those documents use a different legal name, different address or different contact, the variation should be documented before payment rather than explained only after a dispute.
This may sound formal for a small virtual server. It is not. The legal provider decides who receives an abuse notice, who can restore an account, who can disclose customer data, who refunds unused fees and who authorises a route change. A cloud name is operationally useful only when these powers lead to an accountable counterparty.
The 2023 number-resource records are the strongest identity anchor
AS150879 and 103.15.88.0/23 were registered within minutes of each other on August 23, 2023. Their descriptions match the company name and address. The administrative contact in APNIC, Dau Khac Nam, matches the legal representative in the company indexes. The technical contact is Dau Khac Trung, with a separate telephone number and Gmail address. This is a stronger identity chain than a scraped logo or a generic social-media profile because it joins legal, technical and resource-administration details.
An autonomous-system number is an identifier used by a network to express routing policy. A portable /23 is a block of 512 IPv4 addresses that is not merely an address borrowed from a consumer broadband line. Receiving these resources usually requires an administrative process through the relevant internet-number system. The active status of the APNIC records means the identifiers remain present in the registry at the review date.
Those facts deserve weight. They indicate that WIX CLOUD COMPANY LIMITED was not simply using "cloud" as decorative language in 2023. It established a recognisable number-resource surface, named people to administer it and supplied a contact for spam and abuse reports. For a hosting or infrastructure company, that is meaningful evidence of intent and capability.
Yet registry responsibility has a defined boundary. Allocation does not show how many addresses are assigned, what applications run on them, whether customers control them, or whether every use is authorised by the company. An ASN can remain active in a registry while announcing no routes. A block can be originated by a transit partner, a related operator, a managed-network supplier or a customer under a letter of authorisation. The internet routing system permits arrangements that do not place the resource holder's own ASN at the end of the path.
The records also contain an accountability wrinkle. The remark asks for spam and abuse reports at [email protected], while the formal abuse role attached to the record belongs to VNNIC and uses a VNNIC address. The first is an individual Gmail mailbox whose username resembles a brand; it is not an address at a company-controlled domain. The second is a national internet-resource contact rather than an obvious customer-service desk. Neither entry publishes a ticket number, response target, escalation chain or named company function.
That distinction matters because network abuse and customer support are different jobs. An abuse mailbox deals with unwanted traffic, compromised systems and complaints from other networks. A support desk handles provisioning, billing, authentication, backup and recovery. A technical registry contact may be able to modify resource data without having authority to fix a virtual machine. The public record identifies people around the resource, but it does not describe a support organisation around the service.
The appropriate conclusion is balanced. The APNIC entries materially strengthen WIX Cloud's identity. They also expose the exact questions the public record leaves open: who currently controls the resource credentials, who authorises routing, who provisions services, and which legal entity is responsible when those functions fail.
AS150879 is active in the registry but absent from the live routing view
The company's own network identifier presents a simple snapshot. RIPEstat's routing-status view for July 15, 2026 found no IPv4 observation peer and no IPv6 observation peer seeing AS150879. It counted no announced IPv4 space, no announced IPv6 space and no observed neighbour. The announced-prefix view likewise returned an empty list for the first half of July.
This does not mean that the company has no network activity. It means AS150879 was not visible as a Border Gateway Protocol origin in the collectors used for that observation. A private ASN use, a dormant configuration, a route seen only in a limited environment or an operation conducted entirely through another ASN would not appear as a global announcement from AS150879. Registry status and routing visibility measure different things.
For a buyer, however, the gap limits what the ASN can prove. A visible origin would show that other networks accept a route ending at the company's identifier. It could then be examined for prefixes, neighbours, routing history and origin validation. An unannounced ASN supplies none of that operating evidence. It remains an administrative resource that may be reserved, dormant or used outside the globally visible view.
The gap is especially notable because the accompanying IPv4 block is not dormant. 103.15.88.0/23 was visible to 325 of RIPEstat's 326 IPv4 observation peers at the same snapshot. Its latest observation was on July 15, and the route had been seen with the current origin number from August 24, 2023, the day after the APNIC allocation. The block therefore has a continuous-looking public routing presence even though AS150879 itself does not.
The origin at review was AS150698. The immediate network before it in the observed paths was commonly AS18403, whose APNIC description names FPT Telecom Company. A third-party traceroute taken from Ho Chi Minh City also passed through FPT addresses before reaching an address in the WIX Cloud block. The public route is not merely a stale registry entry; packets can reach at least parts of the range through a Vietnamese network path.
But the route does not say why AS150698 is authorised to originate the block. Border Gateway Protocol carries reachability, not corporate contracts. An observed path cannot reveal whether WIX Cloud operates AS150698, buys a managed BGP service from it, leases the addresses, has delegated the block, or participates in some other arrangement. Nor can it show which company controls the routers at the edge.
That is why the mismatch should become a documentation request rather than an accusation. The provider should be able to identify the current origin ASN, supply the letter or agreement authorising it, name the upstream and explain what happens if that relationship ends. If the service depends on 103.15.88.0/23, this is not esoteric network trivia. It is the chain that keeps customer systems reachable.
The current origin record introduces a second identity problem
AS150698 has its own changing public context. At the article date, APNIC's current record named it COS-AS-AP, registered to Chandpur Online Systems in Bangladesh, with a registration event dated June 4, 2026. Other network-information services still described the same ASN as VCORE, a Vietnamese hosting network, and associated it with a collection of Vietnamese company allocations. Those presentations are not consistent with each other.
The inconsistency may have an ordinary explanation. An ASN can be transferred or returned and reissued. Registry records can change more quickly than commercial network indexes. Third-party services can preserve an old display name after the authoritative record has been updated. Historical routing datasets can also attach a current name to observations made under an earlier registration. The fact that RIPEstat dates the WIX Cloud prefix's origin through AS150698 to August 2023, while the current APNIC registration event is in June 2026, is a warning against reading today's holder name backwards into the whole history.
It would therefore be wrong to say that a Bangladesh company has necessarily controlled WIX Cloud's prefix since 2023. It would also be wrong to keep treating AS150698 as unquestionably VCORE after the APNIC record changed. The evidence supports a narrower statement: the same numeric origin has carried the route since the day after allocation, and the current public identity attached to that origin differs from both WIX CLOUD COMPANY LIMITED and the older VCORE label shown by some indexes.
That is a meaningful present-day risk for accountability. When an origin ASN changes registration context, the resource holder should review route authorisations, contacts, Internet Routing Registry entities, monitoring and termination rights. A customer should know whether the change affected the network that actually forwards traffic or only the public registration attached to an unchanged operating arrangement.
The current route view offers one helpful detail and one limit. It shows the WIX Cloud /23 with a single origin, AS150698, rather than a confusing set of simultaneous origins. RIPEstat reported no route objects for the prefix in its routing-status response, however, and the Route Origin Authorisation check returned unknown. The route is globally accepted, but the reviewed mechanisms do not publish a cryptographically validated statement that AS150698 is the authorised origin.
None of this proves a hijack. A route can be legitimate without a Route Origin Authorisation, and many operators rely on contractual letters, filter lists and manual coordination. Public registry transitions can be messy without affecting customers. The correct response is to ask for the missing bridge: a current origin-authorisation document, an explanation of the AS150698 identity change, and evidence that the upstream filters the route according to the resource holder's instruction.
For WIX Cloud, this bridge is more important than the existence of AS150879. The ASN bearing the company's name is not carrying the public route. The operational assurance therefore lives in the relationship between the company, its /23, AS150698 and FPT, not in any one record viewed alone.
RPKI status is unknown, which is different from invalid
Route Origin Authorisation allows the holder of an address block to publish a signed statement naming the autonomous system allowed to originate it and the maximum prefix length permitted. Networks that perform origin validation can then classify a route as valid, invalid or not found. It is a narrow control, but a useful one: it makes some route leaks and unauthorised origin announcements easier to reject.
The WIX Cloud prefix returned unknown in RIPEstat's RPKI validation for both AS150698 and AS150879. No validating ROA was listed. In common operational language, the route is not found in the relevant RPKI data. It is not labelled invalid because there is no conflicting authorisation. The global routing system can and does carry such routes.
That distinction prevents two opposite errors. One is to describe the current announcement as RPKI-invalid, which the evidence does not support. The other is to treat broad route visibility as equivalent to authenticated authority. A route accepted by 325 observation peers is highly reachable; without a ROA, that reachability is not backed by this particular cryptographic origin control.
For a small operator, creating and maintaining a ROA is not a complete security programme. The holder must choose the correct origin and prefix length, update the authorisation before changing providers, protect registry credentials and monitor for unexpected announcements. A badly managed ROA can cause an otherwise legitimate route to become invalid. The value comes from governance around the record, not from the existence of a signed entity alone.
In this case, RPKI would also force a useful decision. Is AS150698 the intended continuing origin, or should AS150879 become active? If AS150698 is intended, the resource holder can authorise it and document the provider relationship. If AS150879 is intended, the operator must establish routing, upstream acceptance and a migration plan before changing the ROA. Either choice would make the public control surface clearer than the present unannounced-own-ASN and unsigned-other-ASN arrangement.
A buyer cannot make that change, but it can make route governance a condition of service. The provider can state which prefix will contain the assigned address, which ASN will originate it, whether a ROA covers it, how route changes are approved, and how customers will be notified. An external monitor can alert when the origin or validation state changes. This converts a static due-diligence finding into a repeatable operating control.
RPKI still would not certify a server, a company or an SLA. A valid route can lead to an insecure host, and a failed virtual machine can sit behind a perfectly authorised prefix. The point is smaller and more practical: when the public origin and the named company ASN diverge, signed origin intent is one economical way to reduce ambiguity.
Reachable addresses are service clues, not a product catalogue
Third-party scanning provides another concrete clue. IPinfo associated the full 103.15.88.0/23 with AS150698 and reported that 504 of the 512 addresses replied to a recent ICMP scan. It showed sub-millisecond responses from its Ho Chi Minh City probe for sampled addresses and a March 2026 traceroute reaching the block through FPT. At the same time, it found no hosted domains on the range and no reverse-DNS entries in the reviewed /24 presentation.
The high response count is unusual enough to notice, but it must be interpreted conservatively. An ICMP reply does not mean that 504 customer servers exist. A router, firewall, virtual network appliance or address-management system can answer for many addresses. Hosts can reply to ping while exposing no customer service, and production servers can intentionally ignore ping while functioning normally. One scan is not an inventory and says nothing about ownership, utilisation or revenue.
The low measured latency is similarly bounded. It is consistent with a network endpoint near the Ho Chi Minh City probe and with the visible path through a Vietnamese operator. It does not identify the building, rack, virtualisation host or storage location. It does not prove that every address in the block terminates in Vietnam, or that customer backups remain there. Routing and anycast techniques can also complicate geographic inference, though the reviewed record did not establish that either was in use here.
The absence of discovered domains does not prove the absence of services. Virtual servers may host private applications, use domains hidden behind another network, serve non-web protocols or have no public DNS. Reverse DNS is optional for many workloads. Yet the absence means public scanning cannot supply the missing commercial bridge. There is no independently visible set of branded service hostnames, nameservers, mail systems or customer-facing endpoints that would turn the range into a recognisable WIX Cloud product surface.
This is where many infrastructure assessments go wrong. A reachable prefix is treated as evidence of a datacentre, and a datacentre is treated as evidence of a resilient cloud. The steps are not interchangeable. A cloud service needs compute allocation, storage, isolation, control access, billing, monitoring, backup and support. The network block is one dependency among several.
For a prospective customer, the route can still support a practical test. The provider can assign a trial system in the stated prefix, provide a looking-glass or test address, identify the virtualisation and storage boundaries, and allow monitoring from the customer's important locations. The customer can measure latency, loss, throughput, reboot behaviour and console access. It can record the origin ASN and compare it with the promised network. Those tests establish far more than a scan, while remaining cheaper than discovering the boundary during a production incident.
The public record does not establish a current cloud product
The most consequential absence is commercial rather than technical. The reviewed material did not establish an active WIX Cloud operator website, service catalogue, order path, customer portal, terms of service or service-level agreement. The string wixvz.com appears inside the Gmail username used in the APNIC contact, but the domain itself had no active DNS record and the .com registry returned no domain entry at the review date. An HTTPS request could not establish a site.
That finding should not be exaggerated into a claim that no service is sold. Small providers can sell through direct messages, resellers or private portals. A company can use a different brand from its legal name. A domain can expire while existing customers remain online. The routed address block is evidence that something is operating on the network. The issue is that a public buyer cannot derive the product boundary from the company name or contact string.
Without a product schedule, basic terms remain unknown. The record does not say whether the offer is shared hosting, a virtual private server, dedicated hardware, address rental, managed routing or some combination. It does not identify a hypervisor, storage model, CPU allocation rule, bandwidth commit, traffic cap, DDoS boundary, operating-system responsibility or software-licence treatment. It does not say whether provisioning is automatic or manual, whether the customer receives console access, or whether a failed host triggers restart elsewhere.
These details change the meaning of "cloud". A virtual machine on one physical host with local storage has a different failure mode from a replicated instance on a cluster. A monthly VPS with customer-managed backup has a different recovery promise from a managed service with tested restore targets. A network-resource arrangement may provide addresses without compute at all. The label cannot decide which service exists.
The absence of public terms also removes the easiest accountability check. There is no reviewed uptime target, maintenance exclusion, credit formula, support-response objective or termination process to compare against a quote. There is no public privacy notice or data-processing statement tying the company identity to customer information. There is no acceptable-use policy connecting abuse contacts to suspension powers. A buyer would have to obtain these documents directly and make them part of the order.
That need not disqualify a provider. Private commercial documentation can be stronger than a polished website. But it raises the burden of verification. The documents should use the exact legal name and tax identifier, identify the service location and origin network, define included labour, and state which promises survive a domain or brand change. A cloud name can open the conversation; the signed schedule must carry the assurance.
Data locality cannot be read from a Vietnamese registry address
The records contain several Vietnamese signals. The legal company is registered in Ho Chi Minh City. APNIC assigns the ASN and prefix a Vietnam country code. The route commonly reaches AS150698 through FPT, and third-party probes measured very low latency from Ho Chi Minh City. These observations support a reasonable hypothesis that the block has an operating presence in Vietnam.
They do not establish data sovereignty. The APNIC country field describes the resource registration context, not the location of every server or copy of customer data. A routing path identifies autonomous systems, not disks. The company address identifies a legal or administrative location, not a datacentre. Even a server physically located in Vietnam may send backups, telemetry, authentication data or support logs to another jurisdiction.
For customers with locality obligations, the important unit is the data lifecycle. Where is the primary virtual disk stored? Where are snapshots and backups copied? Where does the management plane run? Which staff can access the console, and from which jurisdictions? Where are billing records, support attachments and monitoring logs held? What happens to deleted volumes and expired accounts? None of those questions is answered by a low-latency ping.
The AS150698 identity change adds another reason to document this lifecycle. A network origin registered to a Bangladesh company does not prove traffic or data moves to Bangladesh. BGP registration and packet geography are different. But if an external network operator has administrative control, the customer should know what access or processing that role entails. Transit normally carries encrypted packets without controlling the hosted data; a managed platform relationship may involve much more. The contract should distinguish them.
A credible locality schedule can be short. It can name the primary facility country and city, the backup region, the management and support locations, the subcontractors that can access customer data, and the process for approving a location change. It can separate customer content from account data and operational logs. It can state whether the customer can select or verify a region. The provider should also explain which evidence is available after an incident, such as access logs, backup records and change history.
The customer has responsibilities too. Application-level replication, third-party monitoring and off-provider backups can reduce dependence on a thin public assurance surface. Encryption with customer-controlled keys can reduce exposure to infrastructure operators, though it does not solve availability. A tested export process can make migration possible if the legal or network arrangement changes.
The conclusion is not that WIX Cloud's data is outside Vietnam. The evidence does not support that. It is that Vietnam-linked identity and routing clues are limited public evidence to promise locality. Data sovereignty belongs in the service design and contract, not in an inference from an ASN country code.
Support accountability is visible only at the contact level
Public records name two people around the network. Dau Khac Nam is the legal representative in the company index and administrative contact in APNIC. Dau Khac Trung is the technical contact. Telephone numbers and Gmail addresses are supplied. The resource remarks also identify an address for spam and abuse reports. Compared with an anonymous network record, this is useful accountability.
It is not yet a support model. A named administrative contact may manage registrations rather than customer incidents. A technical contact may be an engineer, consultant or resource maintainer without responsibility for billing or backups. Personal mailboxes do not publish opening hours, priority levels, handover arrangements or retention of ticket history. The record does not say who responds when either person is unavailable.
Cloud operations create labour even when provisioning is automated. Somebody must validate an account, review abuse, replace failed hardware, investigate packet loss, reset access, restore backups and explain an invoice. Automation changes the shape of that work; it does not remove it. A low-cost service can remain viable by making customers responsible for more of the stack, but that boundary must be stated before an incident.
The current public record supplies no response or resolution target. It does not separate a security incident from a routine question, identify an emergency channel, or promise escalation to a person authorised to change a route. There is no status page or incident archive to show how outages are communicated. There is no evidence of a ticket system that preserves a shared chronology. An email address can start a conversation, but it cannot by itself establish support capacity.
For a buyer, the remedy is operational testing rather than hopeful interpretation. Before moving a workload, submit a technical question, a billing question and a simulated urgent incident through the proposed channels. Record the time to acknowledgement, the accuracy of the answer and whether the issue can be escalated. Ask who has authority over the hypervisor, storage and route. Confirm how identity is verified before a reset or console action. Require an out-of-band contact if the normal portal depends on the affected network.
The provider should define included and excluded labour. Does it monitor only the host, or also the guest? Will it patch the operating system? Is backup configuration the customer's job? Does DDoS response include filtering, null routing or migration? Is data recovery charged separately? Which work is available outside local business hours? A service that answers these questions modestly is more dependable than one that uses "24/7" without a queue, target or escalation path.
Local support can be a genuine advantage for a Vietnamese customer: language, time zone, payment and physical proximity can reduce coordination cost. The public evidence does not measure that advantage here. It identifies local people and a local company. The organisation and service commitment behind them remain to be shown.
Continuity and recovery need records of their own
The route arrangement creates a continuity dependency that a normal VPS specification might miss. Customer reachability for the WIX Cloud block currently depends on AS150698 and its observed connection through AS18403. If the authority to announce the prefix is withdrawn, the origin registration changes again, or the upstream stops accepting the route, an otherwise healthy server can disappear from the internet. The remedy is not only redundant hardware; it is documented route governance and a tested migration path.
The public view does not establish physical or provider diversity. AS150698 had one observed neighbour in RIPEstat's snapshot. That is evidence of one visible routing relationship, not proof of one cable or one router. The operator could have multiple circuits to the same upstream, hidden arrangements or internal redundancy. Equally, several logical sessions could share one physical path. A customer should ask for the design relevant to its service rather than convert a neighbour count into an architectural verdict.
Storage recovery is even less visible. No reviewed policy states whether backups exist, who configures them, how often they run, where they are stored, how long they remain, or how a restore is requested. A snapshot on the same host is not protection from host loss. A backup in the same account may not survive account compromise. Replication is not a substitute for a historical backup when corruption is copied immediately.
A credible service schedule should therefore separate availability from recovery. Availability asks how often the instance and network can be used. Recovery asks how much data may be lost and how long restoration may take. The first is expressed through an uptime or service target; the second through recovery-point and recovery-time objectives. Both need exclusions, measurement rules and a remedy. Neither can be inferred from the word "cloud".
The customer should also plan for provider failure, not merely server failure. Can virtual disks be exported in a documented format? Can address-dependent applications move to new addresses? Who controls DNS? Are licences portable? How quickly can backups be restored elsewhere? If the provider's contact domain is unavailable, does the customer retain a working communication channel? These questions turn switching cost into a design variable rather than a surprise.
For a small workload, the answer may be deliberately simple: customer-managed backup to another provider, external DNS, infrastructure documentation and an image that can be recreated. For a critical workload, the design may require a secondary region, independent monitoring, tested failover and a named incident manager. The right level depends on the cost of downtime, not on the size of the provider.
WIX Cloud's current records do not show that recovery is weak. They show that it is unproven. The distinction matters. A buyer should neither assume failure nor finance an unknown promise. It should ask for the evidence, run a restore and price the remaining uncertainty.
A staged proof is more useful than a broad claim
The evidence gaps can be tested in a practical sequence. First comes identity. Obtain a current company extract and tax-status confirmation for 0317290315. Match the legal name, signatory, invoice, beneficiary account and address. If the contracting party differs from WIX CLOUD COMPANY LIMITED, require a clear explanation of the relationship and its authority to use the brand and resources.
Second comes network authority. Record the assigned prefix and current origin. Ask for the authorisation permitting AS150698, or any replacement ASN, to announce 103.15.88.0/23. Ask who controls route changes and registry credentials, whether a ROA is planned, and how customers will be told of an origin or upstream change. Verify the answer with external route monitoring throughout the trial.
Third comes the actual product. The order should state whether the service is a virtual machine, dedicated server, hosted application, address service or managed network. It should enumerate CPU, memory, storage, bandwidth, traffic, addresses, virtualisation, console access and software responsibility. If resources are shared, the provider should explain the allocation and contention policy. If "cloud" implies host recovery, the schedule should say how it works and how long it takes.
Fourth comes locality and security. Identify primary storage, backups, management systems and support access by country. Confirm encryption responsibilities, administrator access, logging, vulnerability handling and notification after an incident. The customer should avoid placing sensitive data on the trial until these controls are understood. Identity-reset procedures deserve a direct test because personal email support can create a social-engineering risk if verification is informal.
Fifth comes support and recovery. Use the real channels before launch. Measure acknowledgement and resolution for several kinds of request. Create a backup, delete a test file and restore it. Reboot through the customer console. Simulate loss of the primary credential. Confirm who can escalate a network event to the route operator. Keep the evidence with the contract rather than in one employee's chat history.
Finally, test exit. Export the workload, move a copy to another provider and replace its address in DNS or application configuration. Record the time and manual work required. A trial that is easy to leave is safer to enter. If migration depends on the provider releasing data or changing a route, that dependency should have a contractual time limit.
This sequence is not designed to burden a small supplier with enterprise theatre. Most steps can be completed with documents and one modest test instance. The aim is to align the depth of proof with the impact of failure. A personal development server may justify a light check. A customer database, public API or security system demands much more.
The provider benefits as well. A concise identity pack, network-authority statement, product schedule and support matrix can answer repeated buyer questions at low cost. Publishing a valid route-origin policy and a durable support domain would reduce uncertainty that no amount of branding can remove. Assurance is often less about adding infrastructure than about making existing control visible.
The economic question is supervision, migration and failure cost
A cloud offer can look inexpensive because the monthly line item excludes the work required to supervise it. When public documentation is thin, the customer absorbs more of that work: checking identity, monitoring routes, maintaining backups, testing support, recording changes and planning an exit. The service may still be economical, but the comparison must include this labour.
Network ambiguity creates a specific switching risk. If a workload is built around addresses from 103.15.88.0/23, moving away may require DNS changes, allow-list updates, certificate work, customer notices and propagation time. If the address remains with the provider, the customer's portability depends on how cleanly applications separate identity from IP. A low server price can be outweighed by a difficult migration.
Support opacity creates another cost. When every incident begins by discovering who is responsible, recovery slows and senior staff become coordinators. A well-defined unmanaged service can be cheaper because the customer knows exactly which tasks remain internal. A vaguely managed service can be expensive even when the provider is responsive, because neither side has agreed where the work changes hands.
The absence of published automation evidence also matters. The record does not show a self-service control plane, API, infrastructure templates, usage metering or audit trail. These may exist privately, but they cannot be assumed. Manual provisioning can suit a small stable deployment; it becomes costly when a customer expects repeated creation, scaling, access changes or recovery. Automation should be evaluated by observed workflow, not by the cloud label.
A sensible commercial comparison therefore includes the provider fee, customer administration, monitoring, off-site backup, security review, support escalation, downtime exposure and exit work. It also assigns a value to locality and human responsiveness if those are demonstrated. The cheapest acceptable option is the one that meets the workload's failure budget after all these costs, not necessarily the one with the lowest advertised compute price.
For WIX Cloud, the current public evidence supports a cautious trial more readily than an unqualified critical-workload commitment. The legal and resource anchors make a trial investigable. The route, contract, support and recovery gaps make supervision necessary. A buyer that cannot afford that supervision should not treat the name as a substitute for it.
The name has substance, but assurance must be assembled
WIX CLOUD COMPANY LIMITED is not an empty phrase. The company can be identified through a tax number, date, representative and Ho Chi Minh City address. APNIC records tie the same identity to AS150879 and a portable IPv4 /23. The address block is currently reachable across nearly all of RIPEstat's IPv4 observation peers. These are specific, useful facts.
They also reveal a fragmented operating surface. AS150879 itself is not publicly routing. The company's /23 is originated by AS150698, whose current APNIC identity differs from the older Vietnamese VCORE label still shown by other network services. The route has no validating ROA. The company-branded contact domain is not active, and the reviewed record does not connect the legal identity and network resources to a defined product, data location, SLA, recovery policy or support queue.
Each gap has more than one possible explanation. The company may use a legitimate managed origin. Third-party indexes may lag a registry transition. Services may be sold privately. Support may be effective through direct contacts. Backups and contractual terms may exist but remain available only to customers. The public record cannot choose among those possibilities.
That uncertainty is the central finding. It should not be converted into either endorsement or suspicion. It should be converted into evidence requests and tests: current company documents, origin authority, a route and RPKI plan, a signed product schedule, a locality statement, a support matrix, a restore test and an exit exercise. A provider that controls the service should be able to answer these questions in operational language.
The discipline matters beyond this one company. Internet-number records are excellent at identifying resources and current reachability. They are poor substitutes for a contract. Company indexes are useful for locating a counterparty. They do not measure uptime. A fast ping can show proximity. It cannot locate a backup. A named engineer can establish a human connection. It cannot prove a staffed escalation process.
WIX CLOUD COMPANY LIMITED has enough public substance to merit verification. It does not have enough public service proof to let the cloud name carry operating assurance on its own. The prudent buyer starts with the records, tests the service that sits behind them and makes responsibility explicit before the workload becomes difficult to move.