Summary

  • PANSTAR CLOUD LIMITED now has several public proof points: a PanstarCloud cloud-server storefront, a BTW directory profile, AS197196 in public ASN records, and third-party routing views that associate the ASN with Hong Kong and a small set of advertised network resources.
  • The same evidence also shows why the company should be assessed cautiously. Public legal pages expose policy headings but limited operating detail, support accountability is still thin in the visible record, and route-resource data should be treated as evidence of network activity rather than proof of service quality.

PANSTAR CLOUD LIMITED is the kind of infrastructure name that can look more settled than it is. The public record contains a legal name, a cloud retail brand, network-resource identifiers, product pages, and traffic/routing traces. Those are meaningful signals. They are also not interchangeable with operational assurance.

The company appears publicly under the PanstarCloud brand, whose homepage positions the service around "High-Bandwidth Cloud Servers" for websites, self-hosted services, media-content access and AI tooling. The same page says the delivery path joins servers, images, domains and certificates, and it presents cloud-server purchasing as a matter of comparing region, route, configuration, stock and monthly price. Its cloud-server page goes further, describing resources for high-traffic sites, API services, content distribution and long-running workloads, with same-region private communication between cloud and light cloud servers.

That is a coherent public identity for a small cloud service. It suggests a buyer-facing product layer rather than only a passive company registration. It also places Panstar in a market where the public promise is easy to state and hard to prove: high-bandwidth cloud servers are judged by routing stability, abuse handling, stock accuracy, payment reliability, data locality, and support response under stress.

The directory evidence starts with identity. BTW's public directory profile identifies PANSTAR CLOUD LIMITED as a private company and a network operator associated with ASN/IP network resources. The profile links the company with AS197196 and lists one autonomous system number under network resources. It also records the legal name, display name and company category with high confidence, while not stating a specific geography scope and treating the ASN/IP resource scope as global.

That split matters. A directory record can confirm that the entity is visible in public network-resource evidence, but it cannot by itself prove the quality of the service behind the network. In Panstar's case, the more useful conclusion is narrower: the entity has enough public infrastructure evidence to be monitored as a cloud-service operator, while its operating footprint still needs to be judged from route data, product behavior and support disclosure.

The strongest external proof is the ASN record. The CIDR Report page for AS197196 names the network as "PANSTAR-AS - PANSTAR CLOUD LIMITED, HK" and shows the ASN originating route advertisements. Its embedded whois text from the RIPE Database identifies the aut-num as AS197196, the AS name as PANSTAR-AS, the organisation as ORG-PCL54-RIPE, the organisation name as PANSTAR CLOUD LIMITED, and the country as Hong Kong. It also records an address in Tsim Sha Tsui, Kowloon, Hong Kong, a registration number of 80290097, an abuse mailbox at panstar.ai, and creation dates in late May 2026 for the organisation and the ASN record.

BigDataCloud's ASN lookup independently describes AS197196 as PANSTAR CLOUD LIMITED, with registry RIPE, registered country Hong Kong, five IPv4 prefixes, four IPv6 prefixes and 1,280 total IPv4 addresses. It also lists no downstream peers in that view. Cloudflare Radar, meanwhile, has a traffic page for AS197196 PANSTAR CLOUD LIMITED under the Hong Kong location path. These sources do not prove customer satisfaction or uptime, but they do show that AS197196 is visible to multiple public infrastructure observability systems.

The route relationship picture is still modest. The CIDR Report view shows two upstream adjacent ASNs in its current table: PoloNetwork Limited and Nearoute Limited. BigDataCloud's "receiving from" list includes PoloNetwork, Nearoute, Aiyun (HK) Network and another PoloNetwork entry. Those are observations from third-party routing datasets, not contractual proof of supplier relationships. They are still useful because they show where Panstar's public routing identity intersects with other Hong Kong-linked networks.

For a buyer, this is where the first assurance test should begin. A cloud provider's name is less important than whether the route shown on a purchase page is the route that behaves predictably after deployment. Panstar's own homepage says actual routes follow the purchase page, which is a sensible caveat. It means prospective users should treat public partner logos and route labels as pre-sales signals, then verify the actual node, upstream path, latency and packet-loss behavior on the specific product they buy.

The service catalogue has more substance than a bare parking page. PanstarCloud presents light cloud servers, elastic cloud servers, physical servers, a marketplace, billing and order views, technical support, account security, referrals and coupons. The homepage says light cloud servers include built-in app images with access URLs, domains and SSL delivered together. The marketplace section describes idle-instance transfer, public coupons and referral commission. The console page exposes product, marketplace, account and support categories.

That breadth suggests the company is trying to build a self-service operating surface rather than merely reselling a single virtual server plan. But breadth also raises accountability questions. A marketplace introduces transfer risk and resource provenance questions. App images create software maintenance and security expectations. Domain and SSL bundling creates lifecycle obligations beyond compute. Referral commissions and coupon flows require clear dispute handling. The more PanstarCloud becomes a platform, the more its public policies need to do real work.

That is the weakest visible area. The legal section includes terms of service, privacy, delivery, refund, acceptable-use, risk/fraud/dispute and about pages, but the rendered pages available during this review carry sparse policy detail. Each of those pages shows a contact section stating that no public contact is available yet. For an emerging infrastructure provider, that is not a fatal absence, but it is a visible gap.

A cloud host that sells bandwidth-heavy workloads, content access and API services needs clear abuse intake, customer support escalation, refund mechanics, delivery timing and dispute procedure before the policy layer can be treated as mature.

The RIPE record does include an abuse mailbox, which is important. Network-abuse contactability is a minimum control surface for an ASN operator, especially one selling public cloud access. But abuse contact and customer support are not the same thing. Abuse mailboxes help other networks and rights holders reach the operator when traffic causes harm. Customers still need a separate route for provisioning failures, outages, billing mistakes, marketplace disputes and data-access concerns.

Panstar's visible storefront points to a technical support area in the customer center, but the public policy pages do not yet provide enough detail to judge support accountability from outside.

The data-sovereignty question is also open. PanstarCloud markets regions and routes, and third-party ASN records tie AS197196 to Hong Kong. That does not automatically tell a customer where workloads are hosted, where logs are processed, where support staff can access systems, or which law governs a billing or abuse dispute. Region labels are commercial shorthand; data locality is an operating claim. Buyers with regulated or sensitive workloads should ask for the exact location of compute, storage, backups, support access and legal contracting before treating a region selector as a sovereignty answer.

There is a second subtlety in the network evidence. AS197196 is newly visible in the public records reviewed here, with RIPE record dates in May 2026. Young network-resource records are not suspicious by default. New cloud providers, resellers and regional platforms appear continually. But age affects confidence. A mature provider usually leaves a longer trail: historical route stability, published incident practice, recognizable support channels, maintained policy language, customer documentation, security posture and third-party references. Panstar's record currently has the early pieces, not the whole trail.

That early state should shape how the company is watched. The directory profile is useful because it anchors the entity to AS197196 and prevents the cloud name from floating without a network-resource reference. The PanstarCloud site is useful because it describes what the company says it sells. Routing datasets are useful because they expose the outside-world network shape. None of these should be over-read. A logo list is not a peering contract. An ASN is not uptime. A policy heading is not a support process. A Hong Kong registration cue is not a full data-sovereignty statement.

The fair assessment is therefore neither promotional nor dismissive. PANSTAR CLOUD LIMITED has enough public infrastructure surface to be real in the cloud-service monitoring sense: a cloud storefront, a named ASN, public route observations, an abuse contact, and a directory profile linking the entity to network resources. It does not yet have enough public operating disclosure to make the name itself a trust signal.

For customers, the practical checklist is simple. Confirm the specific plan, region, upstream path and IP resource before production use. Test the actual route after purchase rather than relying on partner labels. Check whether IPv4 and IPv6 resources match the advertised location and route. Ask how delivery, refund, marketplace transfer and abuse escalation work in writing. Separate data-location claims from network-location clues. Treat the public ASN record as a starting point for diligence, not the end of it.

For the wider infrastructure market, Panstar is a reminder of how cloud assurance is built now. The visible record is assembled across storefronts, RIR data, BGP views, traffic observability, policy pages and support behavior. A company can enter that record quickly. Trust takes longer. PANSTAR CLOUD LIMITED has put enough pieces in public view to be assessed; the next test is whether its service proof becomes as specific as its cloud name.