TEKNIX CLOUD TECHNOLOGY INFRASTRUCTURE JOINT STOCK COMPANY sells hosted capacity that still depends on racks, transit and repair windows

Summary

• TEKNIX CLOUD markets web and cloud hosting, WordPress hosting, VPS, CyberPanel hosting, cloud compute, bare metal and storage, plus a choice of 25 global locations. Its public page does not name those locations, the facility operators, the underlying server vendors or the commercial partners that would fulfil a worldwide order.
• The verifiable local network is AS149130. APNIC records associate the company with the portable block 103.234.150.0/23, while current route observations show two more-specific announcements, 103.234.150.0/24 and 103.234.151.0/24, a total of 512 IPv4 addresses, with no originated IPv6 prefix.
• Both /24 announcements have valid route-origin authorization. That is good routing hygiene, but public collectors show only one adjacent network, AS38733, CMC Telecom. One observed BGP neighbour does not prove one cable, one router or one data centre, but it does expose an undisclosed provider dependency and no visible inter-domain alternative.
• The website's five displayed VPS rows repeat the same 1 vCPU, 1 GB memory, 2 TB bandwidth and 25 GB storage offer at $6 a month. No public service-level promise, backup policy, status history, hardware inventory, recovery objective or data-export commitment accompanies that price on the page.
• The evidence grade is Weak. The company has a real, active and RPKI-valid network footprint, but the much broader hosted-service proposition cannot be mapped publicly to named racks, operating sites, support obligations or recovery capacity. Buyers should treat every location and resilience claim as a contractual question until it is demonstrated.

The cloud shopfront is broader than the network underneath it

TEKNIX CLOUD's public website makes a simple promise: customers can deploy cloud servers and storage worldwide, choose among 25 locations, scale up or down on demand and pay only for what they use. The service menu includes web hosting, cloud hosting, WordPress hosting, VPS hosting, CyberPanel hosting and cloud compute. A separate introduction says the business helps customers deploy cloud servers, bare-metal machines and storage. Taken together, this is a broad infrastructure catalogue, not merely a corporate website or software consultancy.

The page also offers an unusually clear starting price. Its visible VPS table shows a configuration of one virtual CPU, 1 GB of memory, 2 TB of bandwidth and 25 GB of storage for $6 per month or $0.009 per hour. But it shows that same configuration five times. The Hosting and Data Center selections do not provide equivalent visible product detail. There is no list of the 25 advertised locations, no processor generation, storage medium, port speed, address policy, virtualisation platform, backup allowance or stock indicator. A customer can see a price before seeing the physical and contractual boundaries of what the price buys.

That distinction is fundamental to hosting economics. A virtual machine may be ordered in seconds, but it still consumes a slot on a physical host, memory modules, storage devices, switch ports, IP addresses, power and cooling. Someone must procure the hardware, install it, monitor it and replace failed parts. Someone must contract for the rack and the network. Someone must decide whether a damaged host is repaired, rebuilt or left waiting for a supplier. The cloud invoice compresses all of those decisions into one line item; it does not make them disappear.

For a large hyperscale platform, a buyer can usually map a product to a published region, availability-zone design, service-level agreement and extensive operating documentation. TEKNIX CLOUD's page provides none of that detail. The absence does not mean those systems do not exist. It means a buyer cannot infer them from the public offer. A $6 server can be entirely appropriate for a disposable development task and entirely inappropriate for the only copy of a trading system. The same machine specification can carry radically different risk depending on the rack, route, support and recovery arrangement behind it.

This is where the company's small visible network becomes useful. It does not verify the whole catalogue, but it gives the marketing claim a physical edge that can be examined.

What the public records actually establish

The strongest identity link is AS149130. APNIC's autonomous-system record names TEKNIXCLOUD-VN, places the resource in Vietnam and records registration on 8 September 2022. The associated address record assigns the portable range from 103.234.150.0 through 103.234.151.255 to the same TEKNIXCLOUD-VN label. Vietnam's national internet registry, VNNIC, also includes Công ty Cổ phần Hạ tầng Công nghệ TEKNIX CLOUD in its IP and ASN member list, with the same 8 September 2022 date.

Those records establish control of internet number resources far more convincingly than a social profile would. They connect the assigned company to an ASN and a /23 allocation. They do not establish ownership of a building, a rack or a particular server. A portable address allocation can be announced from equipment housed in another company's facility, reached over another company's transmission network and supported by a third party. The resource holder controls an important part of the service surface; it does not necessarily own every layer carrying it.

The legal-company picture is somewhat more fluid. A Vietnamese tax-data listing associates tax code 0317327910 with the English name TEKNIX CLOUD TECHNOLOGY INFRASTRUCTURE JOINT STOCK COMPANY and an operating date of 8 June 2022. The older MaSoThue listing names 194C Pasteur in Ho Chi Minh City and Nguyễn Văn Quý as legal representative. A more recent Thư Viện Pháp Luật listing shows a different representative and an address at Sunwah Pearl. These are secondary reproductions of public business data, not definitive corporate filings, and their divergence should be treated as a reason for current contract verification rather than as evidence of wrongdoing.

The older Pasteur address also appears in the APNIC registration. It is an administrative contact address, not a server-location declaration. IP geolocation services may place the prefixes in Ho Chi Minh City, but geolocation is an inference built from routing and commercial databases. It cannot identify a floor, a cage or a power domain. The honest location statement is therefore narrow: the legal and numbering records are Vietnamese and point to Ho Chi Minh City administration, while the physical location of customer equipment is not disclosed in the public material examined here.

That limitation matters because the website promises service worldwide. The number records establish one Vietnamese operating edge. They do not establish the other 24 locations, or indeed prove that the Vietnamese address block is used for the products shown on the pricing page. A buyer needs the provider to map product, location, legal counterparty and network explicitly.

A second TekNix name sharpens the ownership question

The service page complicates the boundary in a revealing way. Its footer says “© 2022 TekNix Corporation,” and its contact address uses the teknixcloud.com domain. By contrast, the APNIC record for AS149130 uses contacts at teknix.cloud and names the assigned company in full. A separate TekNix corporate profile describes TekNix Corporation as an information-technology business and advertises server, hosting, VPS, domain, SSL, cloud and data-centre services. Those similarities suggest a commercial or branding connection, but the public pages reviewed do not spell out the legal relationship.

There is also a separate Vietnamese company record for Công ty Cổ phần Công nghệ TekNix, with a different tax code, and a separate network identity, AS140828, registered as Teknix Technology Joint Stock Company. It would be easy to collapse all of these names into one group. That would be a mistake without a shareholding record, contract disclosure or direct company statement. Common branding, contact people and service descriptions can indicate affiliation; they do not by themselves settle which company owns the servers, employs the support team, signs the customer agreement or receives the payment.

This analysis therefore keeps the boundary fixed around TEKNIX CLOUD TECHNOLOGY INFRASTRUCTURE JOINT STOCK COMPANY and AS149130. TekNix Corporation is relevant only because its name appears on the assigned company's service page and because it may sit somewhere in the delivery chain. It is not treated here as the same legal entity, a parent company or the owner of the infrastructure.

For a customer, the distinction is not academic. If the website operator, invoice issuer, ASN holder and data-centre customer are different organisations, an incident can cross several contracts. The support desk may answer under one brand while the facility account belongs to another company. A hardware order may require approval from a reseller. A billing dispute may be held by the invoice issuer even when the network remains technically healthy.

The customer needs one clear responsibility matrix: who supplies the compute, who controls the IP addresses, who holds the rack agreement, who has facility access, who is the data processor and who is obliged to return data at termination.

The most useful proof would be mundane. The order form and master service agreement should name the legal supplier and tax identifier. The service schedule should name the facility or upstream partners where disclosure is allowed. The support policy should say which team owns each failure domain. The privacy and data-processing terms should identify subcontractors and locations. None of those answers can be replaced by a common logo.

Two /24s are real capacity, but not a capacity statement

Current routing observations give AS149130 a visible and persistent footprint. RIPEstat's routing-status view showed two IPv4 prefixes, 512 addresses and no IPv6 /48s at the 12 July 2026 observation point. Its announced-prefix list identified 103.234.150.0/24 and 103.234.151.0/24. Hurricane Electric's BGP Toolkit and BGP.tools independently showed the same two IPv4 announcements and no IPv6 origin.

The history is also useful. RIPEstat's routing history first records the covering 103.234.150.0/23 in October 2022. The two /24s also appeared that month and remained visible at the article's observation date, while the covering /23 stopped appearing in early 2024. More-specific /24 announcements can be operationally ordinary. They may reflect routing policy, provider requirements, traffic engineering or how route filters are handled. The history establishes continuity of origin; it does not explain the policy.

Both current routes return a valid result from RIPEstat's route-origin validation service: 103.234.150.0/24 and 103.234.151.0/24 are covered by a route-origin authorisation for AS149130 with a maximum length of /24. Valid RPKI is a positive operational signal. It tells networks performing origin validation that the holder has authorised AS149130 to originate those routes. It reduces one class of accidental or malicious routing failure.

It does not tell us how many customer servers are online. A /23 allocation could serve a few internal systems, hundreds of virtual machines, network-address translation pools or services hosted elsewhere. Address count is not server count. Route visibility is not utilisation. A prefix can remain globally reachable while every customer machine behind one switch is down; it can also be withdrawn while a provider moves customers to addresses belonging to an upstream.

The absence of originated IPv6 is similarly specific. It shows no IPv6 prefix from AS149130 in the public routing table, not that TEKNIX CLOUD has no IPv6 capability anywhere. Customers in a global location could receive addresses from a partner. The public website does not say. For buyers that need dual-stack service, this is a product question: which locations support native IPv6, who originates it, and does the recovery design preserve it?

Installed capacity, sellable capacity and recoverable capacity are therefore three different quantities. The routing table proves an installed addressing and network control surface. It says nothing about the number of powered hosts available for sale, the storage remaining after replication, or the compute that survives a rack failure. Those are the quantities behind a reliable hosting offer.

The only visible neighbour is CMC Telecom

The clearest concentration in the public network is adjacency. RIPEstat's neighbour view, BGP.tools and Hurricane Electric each show AS38733, CMC Telecom Infrastructure Company, as the only observed IPv4 neighbour for AS149130. IP2Location's AS149130 summary likewise lists CMC Telecom as the upstream and no downstream networks.

This evidence has to be read with discipline. It does not prove that TEKNIX CLOUD has one router, one fibre or one commercial circuit. Two physically diverse links to the same provider can appear as one BGP neighbour. Private connections, default routes and partner-addressed services may not be visible to public collectors. A backup that is normally silent may also escape a snapshot. Conversely, several BGP sessions to one ASN can still share a building entrance, a metro duct, a core network or an account team. ASN count and circuit diversity are not the same thing.

What the observation does prove is that the public inter-domain path provides no visible alternate network counterparty. If AS38733 stops propagating AS149130, the two /24s lose their demonstrated route to the wider internet. The reason could be technical, commercial or administrative: fibre damage, router failure, a route filter, a maintenance error, congestion, an expired contract or a payment dispute. From the customer's perspective, these causes differ in repair method but can produce the same symptom, an unreachable server.

CMC Telecom is not a thin infrastructure provider. Its company introduction says it operates a 2,500-kilometre cross-Vietnam cable system and three data centres in Hanoi and Ho Chi Minh City. Its data-centre overview describes more than 2,800 racks, 5-20 kW rack designs, 24-hour monitoring and Tier III or TIA-942 Rated 3 facilities. The Tân Thuận site is described by CMC as a 1,200-rack, 10,000-square-metre facility in Ho Chi Minh City. These facts show that the observed upstream has substantial network and facility assets.

They do not locate TEKNIX CLOUD inside a CMC building. An upstream relationship can be delivered at a data centre owned by CMC, at a neutral facility, over a metro access circuit or through an intermediary arrangement. CMC's facility specifications cannot be inherited by a TEKNIX CLOUD product unless the service contract identifies that facility and the relevant certified scope. Even if a rack sits in a Tier III building, a single-powered server, one top-of-rack switch or one customer configuration can still fail.

There is no public PeeringDB profile for AS149130 in the ASN query. PeeringDB is voluntary, so absence is not evidence that the network does not peer or colocate. It does mean there is no operator-maintained public profile there listing exchange points, facilities, interconnection policy, traffic level or network contacts. The route table leaves the CMC dependency visible while the physical design stays private.

The “25 locations” claim needs a supplier map

A provider with two Vietnamese /24s can still sell servers in 25 countries. It could lease bare-metal inventory from wholesalers, resell virtual machines, use a federated cloud platform, rent racks under local contracts, or operate hardware addressed from partner networks. None of those models is inherently inferior. They simply move control and failure responsibility into different hands.

The phrase “25 server locations” is therefore a distribution claim, not an ownership claim. The website does not say “25 owned data centres,” and readers should not turn it into one. It does not list cities, facility names, local operators or network ASNs. It does not say whether each location offers the same VPS, storage and bare-metal products. It does not explain whether customer support can access the machines directly or must open a ticket with another provider.

This ambiguity has operational consequences. If TEKNIX CLOUD resells a server from a foreign supplier, the customer may depend on at least four parties: TEKNIX CLOUD for the account, the infrastructure supplier for the host, the data-centre operator for power and access, and one or more carriers for reachability. A failed disk can require a ticket to travel through that chain. A billing suspension at either provider can stop service. A regional price increase or contract termination can force migration even when the hardware is healthy.

Location claims also need a data map. The primary virtual machine may be in Singapore while backups, ticket attachments and management logs remain in Vietnam. A control panel can be hosted in a different country from the compute. A global storage product may replicate data across jurisdictions unless the contract restricts it. The word “location” has to be split into compute location, storage location, backup location, control-plane location and support-access location.

The minimum supplier map should answer six questions for every offered city. Who owns or leases the physical host? Which data centre contains it? Which ASN originates customer addresses? Which company provides remote hands? Where are backup copies kept? Which legal entity is responsible when the supplier fails? A provider may reasonably keep rack numbers and detailed topology confidential; it can still disclose the facility, country, service owner and recovery model under an appropriate agreement.

Without that map, “worldwide” is useful for discovery but weak for assurance. It tells a buyer where the provider hopes to sell, not what remains operable when one contract or one site disappears.

Five failure paths hide behind one monthly price

The first failure path is the host and rack. A virtual CPU is scheduled on a real processor; 25 GB of storage sits on real media. If a physical host fails, recovery depends on whether the workload can restart elsewhere, whether storage is shared or replicated, and whether spare compute capacity exists. A provider can own several hosts yet have no usable failover capacity during a busy period. The customer needs to know whether the advertised plan is a single-instance VPS, a high-availability service or simply a machine that will be rebuilt after hardware replacement.

The second path is power and facility maintenance. A data-centre certification describes the scope assessed at a particular site; it does not automatically cover the customer's rack architecture. Uptime Institute explains that Tier III means concurrently maintainable: capacity components and distribution paths can be removed for planned work without shutting down the critical environment. It does not mean no incident can occur, and it does not make single-corded IT equipment resilient. A buyer should ask whether each server has dual power supplies to separate feeds, whether network devices are similarly protected, and whether planned maintenance has ever required workload shutdown.

The third path is transit. AS149130's visible dependency on AS38733 means route propagation, capacity and operational coordination with CMC are part of the service. A second circuit to the same ASN may help with port or fibre failure; it may not protect against provider-wide routing policy, account suspension or a shared core incident. A genuinely independent fallback requires clarity about carrier, physical path, router, capacity and routing policy. It also needs testing under load. A backup link that cannot carry peak traffic turns a clean failover into severe loss and latency.

The fourth path is hardware stock and support labour. The repair time for a failed SSD, power supply, optic or switch depends on whether the part is on site and whether an authorised person can fit it. Global reseller locations magnify this issue because the local technician may work for a wholesaler rather than TEKNIX CLOUD. Support hours, language, escalation authority and remote-hands response become infrastructure properties. The public page offers an email contact but no incident telephone number, status page, severity definitions or response targets.

The fifth path is administrative control. Billing systems, domain renewals, licence servers, abuse handling and account permissions can disable a healthy machine. A low-margin plan may rely on automated suspension. A dispute between TEKNIX CLOUD and an underlying supplier can affect customers who paid on time. The customer agreement should require notice, a cure period where lawful, emergency access to data and a defined procedure for disputed invoices. It should also ensure that the status and support channels do not depend entirely on the failed production environment.

These paths can compound. A host failure during a facility maintenance window may exhaust spare capacity. A route change can make the support portal unreachable. A supplier may require payment before releasing an export from a suspended account. Resilience is not a list of components; it is the ability of the entire delivery chain to continue or recover when two inconvenient things happen together.

Backup is not recovery, and migration is not a download button

The website's public offer does not state whether VPS backups are included, whether snapshots are crash-consistent, how often copies are made, where they are stored or how long restoration takes. Customers should assume none of those properties until the service schedule says otherwise. A snapshot on the same storage system protects against some user errors; it does not protect against loss of the storage system, the facility account or the provider itself.

NIST describes contingency planning as a coordinated set of plans, procedures and technical measures that can restore systems, operations and data after disruption. Its contingency-planning guidance includes alternate equipment, alternate processing and recovery at another location. The important word is coordinated. A backup file has little value if credentials, network configuration, encryption keys, application dependencies and a destination platform are missing.

For a TEKNIX CLOUD customer, recovery should be defined by workload rather than by product. What is the maximum tolerable data loss? How quickly must service return? Does recovery require the same IP address? Can DNS be moved? Are licences tied to the failed host? Are backups accessible without the primary control panel? Has a complete restore been timed from a different location? The provider can supply capabilities, but the customer must configure and test the application. Cloud reliability is a shared responsibility, as Microsoft's reliability guidance explains even for much larger platforms.

Migration is the last recovery path. NIST's cloud synopsis and recommendations notes that portability relies on standard interfaces and data formats. For a basic VPS, portability may look straightforward because a customer can copy files and rebuild a Linux machine. In practice, the export can include disk images, databases, entity data, DNS zones, firewall rules, certificates, logs, snapshots and account metadata. The egress time for a large dataset can exceed the remaining service window.

The customer should test exit while the relationship is healthy. It should build one representative system elsewhere, restore data, change the network path and measure what was lost. It should keep independent copies of credentials and configuration. For critical services, it should retain a backup outside the provider's administrative domain. The test should also cover a degraded scenario in which the normal dashboard is unavailable and support must authorise an export manually.

A provider that can explain and demonstrate exit is not inviting customers to leave. It is showing that it understands the dependency it sells.

Vietnam's cloud rules make location and responsibility more concrete

Vietnam now regulates cloud and data-centre services expressly within telecommunications law. The 2023 Law on Telecommunications defines data-centre services and cloud computing services, requires providers to register or notify their provision, comply with cybersecurity, information-security and personal-data rules, and declare service quality. It also requires a telecommunications enterprise to declare a data centre's conformity with applicable standards and technical regulations before commercially providing data-centre or cloud services from it.

Decree 163/2024/ND-CP made the provisions governing data-centre and cloud-computing services effective on 1 January 2025. It sets information-retention duties for service-user details and requires state-agency data using cloud or data-centre services to be stored within Vietnam. These rules do not mean that every private company must keep every dataset in Vietnam, and they do not prove whether TEKNIX CLOUD has completed a particular filing. They do make supplier identity, service classification and physical location material compliance questions rather than optional brochure details.

The Law on Personal Data Protection, effective 1 January 2026, further raises the value of a precise processing map. A customer placing personal data on a hosted server needs to know which organisation processes it, which staff and subcontractors can access it, how incidents are handled, where cross-border transfers occur and how deletion or return works. A Vietnamese ASN and office address are not a complete answer when the same provider advertises global locations.

Data sovereignty should therefore be evaluated as an operational property. The primary dataset may be local, but a remote backup or ticket attachment may not be. A foreign location may meet latency needs while creating transfer obligations. A provider may use a global control plane even when the machine is local. The contract should identify each data class and location, not simply label the whole service “Vietnam” or “global.”

Regulation also intersects with recovery. If a state-agency workload must remain in Vietnam, an overseas recovery site may be unusable even if it is technically sound. If personal data must be returned or deleted, a provider needs an inventory of live volumes, backups and logs. If an underlying reseller fails, TEKNIX CLOUD still needs a lawful method to recover or dispose of customer data. Compliance and resilience share the same prerequisite: knowing where the data and control rights actually are.

What would count as credible redundancy

For the Vietnamese AS149130 service surface, credible network redundancy would begin with a diagram showing edge routers, cross-connects, carriers, physical entrances and remaining capacity after one failure. If both circuits lead to AS38733, the provider should explain which failures that design covers and which it does not. If a second provider or internet exchange is available but normally hidden from public view, a controlled failover record should show that it can carry the routes and traffic.

Facility redundancy would identify the production site and recovery site, their distance and shared dependencies. Two rooms in one building protect against a rack incident, not a building incident. Two buildings on the same floodplain, utility substation or metro-fibre route may still fail together. A buyer does not need sensitive schematics, but it does need enough information to understand the common failure boundary.

Compute redundancy would state how many hosts can fail before customer workloads cannot restart. Storage redundancy would identify whether replication is synchronous, asynchronous or backup-only, and what data-loss window follows. Support redundancy would show who takes over if the primary engineer, ticket system or supplier contact is unavailable. Commercial redundancy would address what happens if a wholesale provider terminates service or changes terms.

For the 25-location catalogue, the provider should resist a single global answer. Each location can have a different operator, network, hardware stock and legal environment. A resilient location matrix would publish at least a city or country, product type, address family, facility or supplier class, backup options and support coverage. Availability claims should attach to a product and site, not to the brand in general.

The proof should include recent tests. Route failover should be observed from several networks. A host evacuation should demonstrate spare capacity. A restore should record recovery time and data loss. A support exercise should show that an urgent ticket reaches someone authorised to act. An export test should show that a customer can rebuild elsewhere. Claims about design are useful; measured outcomes are much stronger.

Who is affected when the service fails

The immediate victim of a VPS outage is not necessarily the person who bought the server. A small hosting account can carry a company website, an online shop, a customer database, email, a remote-access gateway, monitoring or an application programming interface used by other businesses. One unreachable /24 can affect many unrelated tenants if addresses are densely allocated. Public routing data cannot count those customers or identify their services, so the impact should not be exaggerated. It can still be economically wider than the size of the provider suggests.

The effect depends on the layer. A withdrawn route makes every service on the affected addresses unreachable from much of the internet. A failed host affects only the workloads on that machine. Storage corruption can leave a server apparently online while damaging data. A support failure lengthens every incident. A billing lock can selectively suspend one account. A control-panel failure may prevent changes even while websites continue to run.

Customers can reduce these exposures. Public DNS can use an independent provider. Critical data can be replicated outside the account. Monitoring can run from several networks. Configuration can be kept in a separate repository. A secondary service can be prepared with different infrastructure and administration. None of these controls excuses a provider from its obligations; they prevent one provider account from becoming the customer's only route to recovery.

The provider is affected too. A small routed footprint means a major incident can consume much of the technical team's attention at once. If global locations rely on resellers, support staff must coordinate across time zones and contracts. Low monthly prices leave limited room for idle hardware and large support teams unless the business achieves scale. That is why buyers should ask about capacity and response rather than assume that inexpensive service is either fragile or efficient. The answer is in the operating design.

The procurement test is specific, not ceremonial

A serious buyer should ask TEKNIX CLOUD for a current service schedule, not a generic assurance deck. The schedule should name the contracting legal entity and tax identifier, selected location, physical infrastructure provider, IP-origin model, included support, backup policy, maintenance notice, availability target and service-credit conditions. It should distinguish responsibilities retained by TEKNIX CLOUD from those passed to a wholesaler or customer.

The buyer should then request evidence for the chosen product. A Vietnamese service using AS149130 should map to the two announced /24s or explain why it uses different addresses. A global service should name the partner network. The provider should state whether a customer can bring or retain an IP address, how abuse complaints are handled, and what happens to routing and data after termination.

Recovery questions should be framed as demonstrations. Restore a representative backup. Fail a host. Show how traffic moves during an upstream maintenance window. Escalate an urgent ticket outside business hours. Export a full account and rebuild it. The result need not meet hyperscale standards for every $6 workload. It must match the risk the customer is placing on the service.

The buyer should also resolve the branding boundary. Why does the service page carry a TekNix Corporation copyright while AS149130 belongs to TEKNIX CLOUD TECHNOLOGY INFRASTRUCTURE JOINT STOCK COMPANY? Which name appears on the invoice? Which company is the data processor? Which one owns or leases the Vietnamese rack? A clear answer could materially improve confidence. An unclear answer means support, liability and exit remain exposed to organisational ambiguity.

Finally, the buyer should monitor the facts that can be observed independently. The two prefixes, their RPKI status and their AS38733 adjacency are a useful baseline. A change is not automatically an incident, but it creates a question. Public routing is most valuable when combined with the provider's notice and the customer's own reachability tests.

A real network edge, and a still-unproved cloud estate

TEKNIX CLOUD is not merely a name on a colourful page. AS149130 is active, its 512 IPv4 addresses are visible, and both current /24 announcements have valid route-origin authorization. VNNIC and APNIC records connect that network to the assigned Vietnamese company. Those are meaningful operating signals.

The signals are also bounded. The only publicly observed adjacent ASN is CMC Telecom. No IPv6 origin or PeeringDB profile is visible. The website's 25-location claim comes without a location list or supplier map. Its pricing table repeats one small VPS configuration, while the page publishes no service-level, backup, incident, recovery or portability terms. Public corporate records and the site's TekNix Corporation branding leave the delivery boundary less clear than a customer contract should.

That combination earns a Weak evidence grade, not because the network appears dormant, but because the customer proposition is much larger than the verifiable estate. A live route can prove reachability. It cannot prove spare hardware, a second power path, an independent carrier, a staffed repair window or a recoverable copy of customer data. Those facts live in facilities and contracts.

TEKNIX CLOUD can close the gap with specificity: name the locations and suppliers, identify the legal service owner, publish meaningful product terms, document network and facility redundancy, and show tested restore and exit paths. Until then, a buyer should regard the visible AS149130 footprint as one demonstrated Vietnamese edge inside a broader, undisclosed hosting chain. The account may be convenient and economical. Its resilience remains something to prove before a failure, not discover during one.