C & M HOSTING SOLUTIONS PTY LTD as trustee for the C&M Filpo Hosting Trust sells hosted capacity that still depends on racks, transit and repair windows

Summary

• C & M HOSTING SOLUTIONS PTY LTD as trustee for the C&M Filpo Hosting Trust is the legal-name surface behind CMTG Hosting in public number-resource records. APNIC RDAP ties AS149427 and 103.177.193.0/24 to CMTG Hosting and records the entity description as C & M HOSTING SOLUTIONS PTY LTD as trustee for the C&M Filpo Hosting Trust, trading as CMTG Hosting.
• CMTG's own pages describe an Australian hosting and private-cloud provider with a Morley, Western Australia data-centre base, 140 square metres of data-centre floor space, 56-rack capacity, dual PDUs, A and B feeds, UPS-to-generator transition, cooling, fire protection, smart-card access, CCTV, hosted services and support.
• The current public routing footprint is small. RIPEstat showed AS149427 announced one IPv4 prefix, 103.177.193.0/24, with 256 IPv4 addresses, no IPv6 announced space, and one observed neighbour in the snapshot used here. Route-origin validation for 103.177.193.0/24 and AS149427 returned unknown rather than valid.
• CMTG's newer public material expands the operating claim: a $1 million data-centre upgrade, GPU acceleration, EPYC processors, DDR5, dark fibre, two Perth-based data centres, private circuits, immutable snapshots and ransomware detection. Those claims make the service more interesting, but they still need customer-side testing for real failover, restore speed and data portability.
• The evidence grade is Medium. The company and network are real and richer than many thin hosting entries, but the public record still leaves unresolved questions about multi-site topology, transit diversity, RPKI coverage, capacity headroom, provider contracts and what happens when a rack, upstream, support queue or migration path fails.

The cloud claim starts with a locked room

The word cloud can make hosted capacity look weightless. For CMTG, the better starting point is the locked room in Morley. The company's about page says its data centre is located at its head office in Morley, Western Australia, occupies 140 square metres of floor space and has capacity for 56 racks. Its data-centre page adds the equipment vocabulary that matters when a hosted application is no longer abstract: dual PDUs, A and B feeds, UPS support, transition to generator power, in-row cooling, hot aisle containment, Uniflair chillers in an N+1 configuration, temperature and humidity sensors, leak detection, Schneider Electric StruxureWare monitoring, VESDA smoke detection, Fike ProInert IG-55 gas suppression, smart-card access and CCTV.

That is more concrete than a typical small hosting footprint. It means the public article does not have to infer the physical dependency from routing tables alone. CMTG itself says hosted capacity is tied to a particular data-centre environment, power system, cooling design, monitoring stack and access-control process. The public evidence therefore supports a simple operating thesis: this is not only a resale brand wrapped around a hyperscale account. It is a provider that markets local infrastructure, local support and data location as part of the product.

The catch is that visible equipment claims are not the same as recoverable customer capacity. A 56-rack-capable room says something about maximum physical shape, not the number of live racks in use, the spare power available after growth, the commercial status of every cross-connect, the number of available replacement hosts, or whether all workloads can be moved before a failure becomes customer-visible. A dual PDU rack can still have an application pinned to one storage shelf. A generator path can still depend on fuel, maintenance and switching logic.

A monitoring platform can raise alerts quickly while the remedy still waits for parts, remote hands or a vendor ticket.

That distinction is the spine of this profile. CMTG sells the relief of not owning the hardware cycle: the customer buys hosted servers, private cloud, backup, support and network services rather than building its own data centre. The service can be rational, especially for Western Australian firms that need proximity, predictable support and Australian data handling. But the transaction moves the hard infrastructure questions from the customer's balance sheet to CMTG's operating room.

The buyer still needs to know what happens when one rack, one upstream, one storage array, one billing relationship or one support window becomes the bottleneck.

The public sources let us test part of the story. CMTG's hosting page says it provides servers for critical database applications, keeps company information in Australia, owns and manages the platform, offers colocation, business continuity, a 99.9% uptime guarantee for mission-critical data hosted in its data centre, server virtualisation and replication to a disaster-recovery platform. The newer private-cloud page raises the uptime claim to 99.99% for the private-cloud feature list and says data stays securely in Western Australia. Those statements describe the product promise. They do not disclose the failure modes, service-credit terms, maintenance carve-outs, restore-time commitments, tested failover evidence or the exact difference between hosted capacity in one room and capacity spread across more than one facility.

The identity trail is stronger than the operating trail

The public number-resource record is clear enough to connect the directory entity to CMTG Hosting. APNIC RDAP for AS149427 lists the autonomous-system handle as AS149427, name CHSPL-AS-AP, status active, with CMTG Hosting as the registrant and a registration event dated 10 January 2022. APNIC RDAP for 103.177.193.0 lists the range 103.177.193.0 through 103.177.193.255, netname CHSPL-AU, country AU, status active, and remarks that describe C & M HOSTING SOLUTIONS PTY LTD as trustee for the C&M Filpo Hosting Trust, trading as CMTG Hosting. RIPEstat's whois view for AS149427 repeats the description and country, while its whois view for 103.177.193.0/24 repeats the portable allocation context.

That identity evidence matters because the service-facing brand and the legal-name surface are not identical. The customer sees CMTG; the number-resource record carries the longer trustee name. In hosted infrastructure, that difference is not cosmetic. Contracts, abuse handling, route objects, data-protection claims and invoices can sit under different labels. When a buyer asks who is responsible for a migration, a restore or a billing lock, the answer has to be mapped from the trading name to the legal and operational counterparty.

The identity trail also helps separate live infrastructure from ordinary corporate marketing. CMTG's home page describes a trusted Australian IT partner with an enterprise-grade data centre in Perth, managed IT services, cloud services, backup and disaster recovery, cybersecurity, network and communications, product supply, consulting, licensing and internet links. The about page says CMTG was established in Perth in 1998 and specialises in high-performance data storage, application hosting, private cloud systems and ongoing support. The our-story page says the operational footprint is Perth, Melbourne and Sydney, while also describing the enterprise-grade data centre at the Perth headquarters.

Those statements give the company more than a single-purpose hosting identity. CMTG is an IT infrastructure provider, not just a VPS storefront. That breadth can help resilience when it means in-house support, project delivery, network capability and migration skill. It can also blur accountability when a customer buys a managed-service bundle rather than a clearly bounded hosting product.

The right question is not simply "Is CMTG a host?" It is "Which part of the CMTG service is hosted on its own infrastructure, which part depends on carrier or public-cloud partners, which part is support labour, and which part is a customer-specific managed contract?"

The public records cannot answer all of that. They tell us AS149427 exists, the /24 exists, the CMTG Hosting contact points exist, and the Morley data-centre claim exists. They do not disclose customer count, traffic levels, paid transit contracts, storage architecture, backup retention, maintenance history, incident history, service credits, restore test results or the contractual boundary between the trustee entity and CMTG's broader IT services.

A small public route footprint changes the risk lens

Public BGP evidence makes the hosted-capacity question sharper. RIPEstat's AS overview describes AS149427 as CHSPL-AS-AP - C & M HOSTING SOLUTIONS PTY LTD as trustee for the C&M Filpo Hosting Trust and marks it as announced. Its routing-status snapshot showed one announced IPv4 prefix, 256 IPv4 addresses, no announced IPv6 space, and 323 of 325 RIPE RIS IPv4 peers seeing the route in the queried view. The announced-prefixes endpoint listed 103.177.193.0/24 as the current prefix in the period shown. The routing-history endpoint showed that prefix appearing from May 2022 onward in the historical series.

That is a real route footprint, but it is a compact one. One /24 is enough to host control panels, customer services, VPN endpoints, remote-management systems, authoritative services or hosted workloads. It is not enough on its own to show the scale of the private-cloud estate. CMTG could operate substantial customer infrastructure behind private links, partner networks, NAT, provider-assigned addresses or non-public addressing. Conversely, a /24 can also support a visible hosting offer without proving a deep pool of internet-facing capacity. The public route table reveals an edge, not the whole platform.

The absence of public IPv6 announcement is also not a verdict by itself, but it is a useful procurement question. If a hosted provider's own public ASN does not show IPv6 announced space in the RIPEstat snapshot, customers that need IPv6 exposure should ask whether IPv6 is available through another upstream, a different platform, a public-cloud component or not at all. The answer matters for government, research, dual-stack web services and long-lived network designs. IPv6 can be bolted on late, but late dual-stack work often becomes a migration project rather than a checkbox.

Route-origin security is another unresolved item. RIPEstat's RPKI validation check returned unknown for AS149427 and 103.177.193.0/24 in the snapshot used here, with no validating ROAs. Unknown is not the same as invalid. It means the route was not covered by a Route Origin Authorization in that result. For customers, that is a risk-control gap rather than a live outage. Networks enforcing route-origin validation reject invalid routes, not unknown routes, but a valid ROA would reduce ambiguity and improve routing hygiene. APNIC's resource certification material and RFC 6811 explain the point: RPKI validates origin authorization, not server health, data recovery or physical diversity.

The public route surface therefore creates a double message. It confirms that CMTG Hosting has an observable network identity. It also warns customers not to confuse a live ASN with a complete resilience picture. The hard buyer questions remain: Which services use 103.177.193.0/24? Which hosted products depend on addresses outside that block? Are customer workloads reachable through public IPs, private circuits, VPNs or remote desktops? Is there a second routable block for failover? Are route changes tested? Is the unknown RPKI state deliberate, temporary or simply unaddressed?

Transit evidence points to concentration unless proven otherwise

RIPEstat's ASN-neighbours endpoint showed one observed neighbour in the queried snapshot: AS2764. RIPEstat's AS overview for AS2764 labels that network AAPT - AAPT Limited, and APNIC RDAP for AS2764 identifies AAPT Limited as the registrant. BGP.tools' AS149427 page described the CMTG network as small, with one upstream carrier and two peers in its public summary. PeeringDB's API query for ASN 149427 returned no network entity for the ASN.

Each of those sources sees the internet from a different angle, so they should not be collapsed into one precise transit map. A route collector's observed neighbour is not a carrier contract. A public aggregator summary is not a capacity table. PeeringDB absence is not proof that a network has no peering, only that the common self-maintained interconnection directory did not return a profile for this ASN. Still, the combined picture is enough to make concentration the default question. Public BGP does not show a richly multi-homed autonomous system with many visible upstreams, exchange points and public interconnection sites.

CMTG's own service pages add another layer. The communications menu and listed services include business-grade internet, SD-WAN, private tail and dark fibre, mobile voice and data, and network services. The 2025 private-cloud platform post says the platform is hosted across two Perth-based data centres and that clients can connect using private circuits or dark fibre. The Neil Morris profile says some customers connect via dark fibre and quotes 10Gbit connections with sub-millisecond latency and no ingress or egress charges. Those claims may describe private customer paths that do not appear as additional public BGP neighbours.

That is why the transit question has to be tested twice. At the public internet edge, customers need to know how many upstreams can carry default traffic, what happens if AS2764-facing reachability degrades, whether BGP sessions terminate on separate routers, whether there is a second carrier path, and whether route-origin records are maintained. At the private-connectivity edge, they need to know whether dark-fibre paths share ducts, meet-me rooms, optical shelves, power supplies or building entrances. Two logical paths can still fail together. Two data centres can still share a core storage dependency or a common management plane.

Two carriers can still converge at one exchange or one maintenance window.

The distinction matters especially for customers attracted by local performance. Local private circuits can make hosted desktops and engineering applications feel close, which is a real advantage when large files, graphics workloads or latency-sensitive applications are involved. But locality can create a single-region dependency. If a customer has no public-cloud fallback, no offsite export, no tested restore outside CMTG's environment and no independent access path, then the same locality that improves performance can tighten the failure blast radius.

Sovereignty is a promise, not a recovery plan

Data sovereignty is central to CMTG's public positioning. The hosting page says hosting data with CMTG means company information remains in Australia and says CMTG owns and manages its platform. The private-cloud page says CMTG's private cloud is supported locally in Western Australia and that data stays securely in WA. The digital-sovereignty post argues that CMTG's WA-based private cloud keeps infrastructure and operations within Australia and helps organisations reduce offshore dependencies.

That is a meaningful buying proposition for Australian organisations with compliance, client confidentiality, operational-control or latency concerns. It gives a Western Australian buyer a local counterparty and a local support narrative rather than a remote hyperscale ticket queue. It may simplify conversations about jurisdiction, support access and where data is expected to reside. The Office of the Australian Information Commissioner's privacy-principles material and the Australian Signals Directorate's Essential Eight material show why governance, access control, backup, patching and accountability matter beyond pure hosting performance.

But sovereignty does not automatically solve resilience. A workload can remain within Western Australia and still be difficult to recover if backups are locked into one provider, if restore targets are not tested, if encryption keys depend on one management plane, if a billing dispute suspends access, or if a storage failure corrupts primary and replicated copies. A customer can be protected from offshore jurisdictional uncertainty while still exposed to a local cooling fault, software bug, fibre cut, ransomware event or migration bottleneck.

CMTG's best public material recognizes that the issue is broader than geography. The private-cloud platform post mentions two geographically diverse Perth data centres, backups, immutable snapshots and ransomware detection. The backup-resilience post says backup has become a strategic asset and focuses on confidence in rapid recovery. The data-centres critical infrastructure post says data centres need energy strategy, operational continuity and infrastructure security from design through daily operations. Those are the right categories. The remaining question is evidence: how often is restore tested, what is the measured recovery time for different workloads, and can customers leave with data, machine images, configuration and network dependencies intact?

For a buyer, the sovereignty test should therefore be practical. Ask where data is stored, where backups are stored, where metadata and logs are stored, who can access each layer, which law governs the contract, what happens if CMTG changes an upstream or facility provider, and how quickly a workload can be restored outside the CMTG platform. Locality is valuable only when it is paired with recoverability.

The 2025-26 upgrade story is a capacity clue, not a blank cheque

CMTG's recent public posts make the operating surface more dynamic than the older pages suggest. In May 2025, CMTG announced a $1 million data-centre upgrade at its Morley site, with high-powered computing clusters, GPU acceleration, expanded networking and storage, improved connectivity through dark fibre networks, and replacement chillers for more energy-efficient cooling. In July 2025, the Neil Morris hosted-services profile described production-platform upgrades including a 52% jump in CPU base-clock speed, DDR5 RAM with 118% speed gains, GPU-accelerated Windows 11 virtual desktops and ransomware detection built into upgraded IBM SAN storage. In December 2025, the new private-cloud platform post named AMD EPYC CPUs and NVIDIA GPUs, and emphasized dedicated resources for clients.

Those claims are useful because they convert cloud marketing into a hardware-cycle story. Hosting economics depends on timing: a provider buys servers, storage, networking and cooling; customers rent slices or service outcomes; the provider hopes utilization and support efficiency cover the capital cost, power bill, maintenance and future refresh. A hardware upgrade can improve performance and extend the provider's product range, but it can also concentrate customers on a newer stack that must be operated, patched, monitored, cooled and eventually replaced.

The question for customers is not whether EPYC, DDR5, GPUs or upgraded storage sound fast. The question is whether installed capacity is also usable capacity after failure. How much of the new compute pool is reserved for burst or failover? Are GPU workloads tied to a small number of hosts? Are virtual desktops pinned to a storage tier that has a separate replication mechanism? Does immutable-snapshot protection cover all products or selected backup tiers? Are customer resources dedicated by contract, by policy or only by practical configuration? How fast can CMTG replace a failed GPU host if the global processor and memory supply pressure described in its infrastructure-cost post becomes a real stock constraint?

CMTG's story is especially relevant for engineering, construction and other data-heavy firms. The private-cloud platform post argues that local private cloud can support CAD, BIM, simulation software, virtual desktop use and private circuits more predictably than public internet-only cloud. That is plausible: large files and graphics workloads often punish high latency, variable egress costs and shared resource contention. But specialized workloads also make migration harder.

A customer with large model repositories, custom GPU images, licensing servers and private circuits cannot simply pick up and move during an incident unless the exit path was designed before the incident.

The upgrade narrative therefore supports the "Hosting economics" topic for this profile. CMTG is asking customers to avoid their own capital refresh and trust the provider's refresh cycle instead. That can lower friction and improve performance. It also makes transparency about capacity, spares, service levels and portability more important, because the customer has fewer direct levers when the provider's hardware cycle becomes stressed.

Support windows are infrastructure

CMTG's support model is not an accessory to the hosting product; it is part of the infrastructure. The support page lists business-hours operational support from Monday to Friday, 05:00 to 17:00 WST; optional extended weekday support from 17:00 to 20:00 WST; weekend and public-holiday support from 05:00 to 17:00 WST with named exclusions; and support contact details. The same page asks customers to provide the nature of the issue, number of users affected and workload affected. It also says CMTG has a three-tier local support team of more than 20 accredited and experienced service engineers for proactive monitoring, support and management of server hosting and network environments.

That is a public support surface with enough specificity to analyze. It says CMTG has staff and a process, not only an email address. It also reveals that recovery expectations may differ by contract. If extended support is an optional add-on and public-holiday exclusions exist, a customer running a critical hosted application has to know which tier governs a Sunday-morning storage alarm, an after-hours router fault, a Christmas Day application outage or a ransomware restore. The difference between "monitored" and "actioned" is where downtime often lives.

Support labour becomes most visible when the failure is messy rather than binary. A simple host reboot may be quick. A degraded storage pool, failed replication job, customer-side DNS misconfiguration, application licensing issue, private-circuit carrier ticket or backup restore from immutable storage may require coordination across CMTG engineers, vendors, carriers and the customer.

The public support page's request for number of users and workload affected is the right triage lens, but the customer still needs escalation terms: severity definitions, response targets, restore targets, communications cadence, authority to make changes and decision rights when a risky workaround is available.

This is where the company identity also matters. CMTG is not only selling raw compute. It sells managed IT, cloud, backup, cybersecurity, network services, licensing, consulting and hardware supply. That breadth can reduce finger-pointing when the same team controls the desktop, server, backup and network path. It can also create bundled dependencies. If one provider supplies the hosted environment, the backup, the remote desktop, the endpoint security, the internet link and the help desk, then a failure in the provider's systems can affect more layers at once.

Customers need to ask which functions are independent, which are merely different services from the same control plane, and which can be operated if CMTG's own support tooling is impaired.

The public evidence makes a fair middle-ground assessment possible. CMTG has a visible support page, a named local service model and staff claims. That is stronger than a thin VPS brand with only an order form. But support transparency remains incomplete until a buyer sees the actual service agreement, maintenance notice policy, out-of-hours entitlement, restore-test evidence and incident-report practice.

The rack failure path is not hypothetical

The first failure path is the simplest: one rack or one room loses usable service. CMTG's data-centre page says racks have dual PDUs and A/B feeds, and that UPS enables transition to generator power. Those are standard and useful mitigations. They do not eliminate the need to test what happens when a PDU fails, a rack breaker trips, a firmware issue affects a storage shelf, a top-of-rack switch fails, or maintenance work removes one power path.

The fact that the page lists dual feeds should lead customers to ask whether their servers and network devices actually use both feeds, whether power supplies are balanced, and whether failover is tested under load.

The second failure path is cooling and environmental control. CMTG names in-row cooling, hot aisle containment and N+1 chillers. That is specific. It still leaves practical questions: What is the maximum temperature rise after one chiller or in-row unit is lost? How long can the room remain within limits during a power transition? Are customer workloads throttled or migrated during cooling incidents? Does the monitoring platform alert customers or only staff? Which environmental alarms trigger customer-visible incident notices?

The third failure path is the public network edge. AS149427's public routing surface currently appears small. If the public services a customer needs depend on 103.177.193.0/24 and a limited visible upstream set, then transit, BGP configuration, route filtering and route-origin records become part of the application risk. If private circuits carry the most important traffic, the public route table may understate the customer's exposure, but it also raises a different question: could the customer keep operating if the private circuit fails and traffic must shift to the public internet?

The fourth failure path is hardware stock. CMTG's upgrade posts emphasize newer CPUs, GPUs, DDR5 and storage. Those are good for performance but can be harder to replace quickly when supply chains tighten. CMTG itself has written about global infrastructure pressure as memory and processor costs rise. Customers using specialized hosted desktops, engineering workstations or GPU-enabled workloads should ask what spare hosts exist, which components are stocked locally, what lead times apply, and whether a degraded mode is available without the same accelerator profile.

The fifth failure path is backup and migration. CMTG says it offers business continuity, disaster recovery, replication, immutable snapshots and ransomware detection. Those controls matter only when the customer knows what is protected, how frequently, how long, where copies reside, who can delete or modify them, and how a restore is rehearsed. A backup that can recover data after a ransomware event may still leave the customer waiting on DNS, application reconfiguration, licensing, desktop images, firewall rules, identity integration and user acceptance testing.

The sixth failure path is billing and contract dependency. This is less dramatic than a power event but can be just as decisive. Hosted capacity is controlled by the provider's terms, invoices, renewal windows, acceptable-use rules and service boundaries. The terms-and-conditions page names hosted services, internet services, offsite backup, Office 365 and managed services agreement categories. A customer should review the exact terms for suspension rights, data-return obligations, termination assistance, dispute handling, maintenance windows and service credits. A good technical architecture can still become trapped if the contract does not define exit rights.

Two Perth sites would change the grade if proved operationally

The strongest newer claim in CMTG's public material is not the $1 million figure or the processor names. It is the statement in the private-cloud platform post that CMTG's new platform is hosted across two Perth-based data centres, with multiple internet and data links, private circuits or dark fibre, backups, immutable snapshots and ransomware detection across two geographically diverse Perth data centres. If that is implemented as true independent service capacity, it meaningfully improves the resilience story.

But "two data centres" can mean several different things. It can mean active-active compute, active-passive recovery, backup replication, storage-only replication, remote immutable snapshots, a secondary network point of presence, or staged migration capacity. It can mean two buildings owned or leased by the provider, a primary facility plus colocation space, or a partner facility. It can mean independent power, independent fibre entrances and independent carriers, or it can mean a second site that still shares key management systems, carrier paths or operational staff. Public prose does not settle those differences.

The buyer test should be explicit. For each critical workload, ask where the primary compute runs, where the replica runs, how storage is replicated, how often consistency is checked, what data loss is acceptable, how long failover takes, how customers connect after failover, whether DNS or route changes are automated, whether the secondary site has enough capacity for multiple simultaneous customer failures, and whether failback is rehearsed. The same question should be asked for the control plane: identity, backup console, monitoring, remote access, billing, ticketing and documentation.

A second data centre does less good if the operator cannot manage it during an incident.

The two-site claim also matters for data sovereignty. A Western Australian two-site platform can be attractive because it keeps data close while reducing one-room exposure. That is a genuine proposition for firms that need low latency and local jurisdiction. The risk is assuming that regional diversity exists simply because two Perth locations exist. A local fire, flood, grid event, carrier maintenance, software bug or operator mistake can affect both if the architecture is not deliberately separated.

On the evidence available publicly, the correct posture is positive but conditional. CMTG has said enough to justify asking serious resilience questions rather than dismissing the platform as a one-room claim. It has not publicly disclosed enough to treat multi-site recovery as proven for every hosted customer or product. That is why the evidence grade remains Medium rather than Strong.

What a customer should test before trusting the invoice

A prospective customer should begin by mapping the service boundary. Which legal entity signs the contract? Which services are supplied directly by CMTG infrastructure? Which depend on third-party cloud, carriers, software vendors or hardware supply chains? Which workloads use AS149427 and 103.177.193.0/24? Which use private links, VPNs, public cloud, Microsoft 365 or customer-controlled addresses? This is not paperwork for its own sake. It determines who can fix the service when the failure crosses layers.

The second test is route and connectivity. Ask CMTG to describe upstreams, peering, private-circuit diversity, dark-fibre routes, failover methods and IPv6 availability. Ask whether AS149427 has RPKI ROAs planned or present through another validator. Ask for a looking-glass or traceroute method if available, but do not treat a traceroute as a contract. For private circuits, ask whether separate fibres enter separate buildings, whether last-mile provider diversity exists, and whether backup internet paths are sized for degraded operation.

The third test is restore. Do not accept "backed up" as a complete answer. Ask for recovery point and recovery time objectives by workload class. Ask when the last restore test occurred, how long it took, what failed, and whether the test included application, database, identity, DNS, firewall and user access. Ask whether immutable snapshots can be restored to a clean environment if the primary control plane is compromised. Ask how ransomware detection changes the restore decision. Ask whether customers receive reports after tests or incidents.

The fourth test is hardware and capacity. For private cloud, ask how compute, memory, storage and GPU resources are reserved. Ask whether high-performance tiers are oversubscribed, how noisy neighbours are handled, what spare capacity exists at each site and how upgrades are rolled out. Ask what happens if a customer needs urgent growth during a supply-chain constraint. CMTG's own discussion of memory and processor cost pressure makes this a fair question, not a hostile one.

The fifth test is support. The public page defines support hours and optional extensions. A customer should align that with its operating hours, not the provider's default. If the customer runs operations at night, on holidays or across time zones, the contract should define the response window, escalation path, named roles, incident communications and authority to act. Support is not just the first reply; it is the ability to drive a technical fault through carriers, vendors, storage, network and application layers until the service is restored.

The sixth test is exit. Hosted capacity should be portable before it is urgent. Ask for export formats, VM image access, backup copy access, DNS and IP migration options, data-return timing, assisted migration terms and deletion attestations. A provider that is confident in its service should be able to describe how a customer leaves cleanly. Without that, the customer's resilience depends on staying with the provider through any commercial or technical dispute.

Who is affected when the system fails

CMTG's public material points toward several affected groups. Engineering and construction firms using GPU-enabled virtual desktops or private cloud would feel performance, file-access and project-delivery impacts. Mid-market organisations using hosted database applications would face operational downtime if application servers, storage or connectivity failed. Businesses relying on CMTG backup and disaster recovery would be exposed if restore paths were slow or incomplete.

Customers using CMTG support, network services and managed IT could see a broader outage if the same provider controls the hosted environment and the user-support channel.

The direct customer is not the only party. CMTG's sovereignty messaging is aimed at clients whose own customers, regulators or project partners care where data sits and who can access it. If a local hosted environment fails, those downstream parties may not care that data remained in Western Australia. They care whether payroll, design files, client records, production systems, backups or collaboration tools are available and intact. That is why local hosting must be judged on both jurisdiction and continuity.

There is also a public-internet dimension, though the visible route footprint is modest. AS149427's /24 may support services whose users never know the CMTG name. If public DNS, VPN endpoints, remote desktops or hosted applications sit on that range, a routing problem can surface as an application problem. Because the public footprint appears compact, it is especially important to know which critical services are exposed there and which have alternative reachability.

The most important affected group may be customers that believe outsourced hosting removes infrastructure responsibility entirely. It does not. It changes the skill required. Instead of maintaining racks, those customers need to maintain evidence: service maps, restore tests, support terms, exit plans, dependency registers and escalation contacts. CMTG may supply much of the technical work, but the customer still owns the business risk of not knowing how the hosted system fails.

Evidence grade: Medium

CMTG's public evidence is better than a thin directory listing. The APNIC and RIPEstat records tie AS149427 and 103.177.193.0/24 to the legal-name surface and CMTG Hosting. The company site describes a specific Morley data-centre environment, 140 square metres, 56-rack capacity, dual power feeds, UPS-to-generator transition, cooling, monitoring, fire protection, security controls, local support, hosted services, private cloud and backup. Recent posts add upgrade details, two Perth data-centre claims, dark fibre, private circuits, newer compute, GPU acceleration and storage protection.

The limiting evidence is equally important. Public routing shows one current IPv4 /24 and no IPv6 announced space in the RIPEstat snapshot. RPKI validation for the prefix and origin returned unknown. PeeringDB returned no network profile. RIPEstat neighbour evidence showed AS2764 only in the snapshot, while BGP.tools summarized one upstream and two peers. Public pages do not disclose exact customer topology, live rack utilization, failover design, route diversity, restore-test history, spare capacity, service-credit terms, maintenance history or exit mechanics.

That leaves the profile in the middle. The entity is real, the CMTG service surface is publicly described, and the Morley data-centre claim is specific enough to discuss infrastructure rather than branding. But customers should not buy the promise on slogans. They should test multi-site capacity, restore paths, transit diversity, support escalation, hardware spares and data portability before treating CMTG's hosted capacity as resilient for critical workloads. The public answer is not negative.

It is conditional: CMTG appears to operate a serious local hosting platform, but the resilience case depends on facts that only contracts, architecture diagrams, route records, restore evidence and customer-specific testing can settle.