datacenter Cloud 9 Ltd. has to prove whether marketed data-centre capacity can survive power and carrier constraints

Summary

• The precise public network entity behind the directory name is not currently a live route edge. RIPEstat's AS overview for AS203301 identifies the holder as datacenter Cloud 9 Ltd., but marks the ASN as not announced on July 12, 2026, and RIPEstat routing status shows zero announced IPv4 or IPv6 space.
• The same Cloud 9 Ltd. organisation has a much stronger live operating signal through AS57814. RIPEstat AS57814 routing status shows the ASN announced with 27 IPv4 prefixes, 3 IPv6 prefixes and 12 observed neighbours, while RIPE registry text ties AS57814 to ORG-CL434-RIPE, the Cloud 9 Ltd. organisation.
• The Cloud9 public site markets a Tbilisi-based carrier-neutral data centre, colocation, VPS, VDS, dedicated servers, domains and shared hosting. Its own data-centre page states that most services are delivered from its Tbilisi facility and lists power, cooling, fire-suppression, security and interconnection claims.
• The physical-resilience claims are unusually specific but still buyer-facing claims. Cloud9 says the facility uses three independent power substations, a 630 KVA diesel generator, N+N power feed for the colocation zone, DX cooling, Novec 1230 fire suppression, scheduled facility access and 24/7 engineering coverage; customers still need maintenance-history, generator-runtime, cooling-failover and restore evidence.
• The evidence grade is Medium. There is real Cloud 9 Ltd. facility and AS57814 routing evidence, plus PeeringDB entries for Cloud9 Dinamo Arena and IXP.ge, but the exact AS203301 entity is quiet and public material does not prove audited capacity, dual active utility operation, carrier-path diversity, spare power headroom or customer failover outcomes.

The company is visible, but the assigned data-centre ASN is quiet

The first test for datacenter Cloud 9 Ltd. is not whether the brand has a website. It is whether the exact public network identity attached to the directory subject is doing work today. On that question, the answer is a downgrade. RIPEstat's AS overview for AS203301 names the holder as datacenter Cloud 9 Ltd. and shows the ASN as assigned, but it also reports that the ASN is not announced. RIPEstat routing status for AS203301 shows no announced IPv4 prefixes, no announced IPv6 prefixes and no observed neighbours in the July 12, 2026 view.

That is not a small footnote. If a directory card, routing table, procurement memo or customer note treats AS203301 as the current public edge of a data-centre service, the current evidence does not support that treatment. RIPEstat announced prefixes for AS203301 returns an empty current list. RIPEstat's routing history shows that AS203301 previously originated 185.139.56.0/22 from 2016 until October 2023, so the ASN was not always inert. But a historic route is not usable customer capacity in 2026. It is evidence of prior operation, not present service.

The more interesting point is that the quiet AS203301 does not make Cloud 9 Ltd. disappear. It forces a separation between an assigned data-centre ASN and the operator's broader current network. RIPEstat's AS overview for AS57814 identifies AS57814 as Cloud9 Cloud 9 Ltd. and marks it announced. RIPEstat routing status for AS57814 reports 27 IPv4 prefixes, 3 IPv6 prefixes and full route-collector visibility in the checked view. RIPE registry-derived data for AS57814 ties the ASN to ORG-CL434-RIPE, the same Cloud 9 Ltd. organisation handle visible in RIPE's organisation record.

The responsible reading is therefore neither dismissal nor blind confidence. AS203301 should not be treated as a live edge without fresh evidence. AS57814 shows that the Cloud9 operation has a real routed footprint. A customer evaluating colocation, VPS or dedicated servers should ask which ASN and prefixes carry the purchased service, whether AS203301 has been retired, reserved, or repurposed, and whether any customer-facing service still depends on its old route plan. The distinction matters because network identity is not branding. It is the path through which reachable customer systems survive a fault.

The marketed facility is a single Tbilisi anchor

Cloud9's public position is direct: its data-centre page presents the company as a carrier-neutral data-centre operator in Georgia and says most Cloud9 services are delivered from its Tbilisi-based data centre. The footer and contact page give the operating location as 2 Akaki Tsereteli Avenue, Dinamo Stadium, Gate 5, Tbilisi, Georgia 0112. PeeringDB's facility record for Cloud9 Dinamo Arena also places a facility named Cloud9 Dinamo Arena at A. Tsereteli Ave 2 in Tbilisi, with Cloud9 LTD as the organisation and support email contacts.

That is better than a vague cloud page with no place attached. The public footprint gives a buyer a building-level question to ask. The problem is that a building address is not the same thing as a full capacity map. Cloud9 can credibly point to a Tbilisi facility, but public material does not disclose the number of rooms, live cabinets, spare cabinets, power draw, cooling reserve, fuel contracts, generator runtime under measured load, carrier entrance diversity or the amount of customer capacity that remains after a component fails.

The Cloud9 site also ties several services back to this physical anchor. Its colocation page sells 1U, 2U, tower-server, half-rack, full-rack and cage arrangements. Its VPS page sells managed and self-managed virtual private servers. Its VDS page sells larger virtual slices, and its dedicated-server page sells physical servers. The company's terms of service list hosting, colocation, data-centre services, rack rental, cross-connects, power distribution units and internet-provider interconnection as offered services.

That product breadth raises the stakes. A failure at one Tbilisi anchor can affect customers in different ways: a colocation customer may own the failing hardware but rely on Cloud9 for power, cooling, access and cross-connects; a VPS customer may rely on Cloud9 for the server, storage, virtualisation platform and backups; a dedicated-server customer may rely on Cloud9 for server replacement, remote access and network continuity. The same outage can therefore look like a power event, a cooling event, a routing event or a support event depending on the customer's contract.

The location evidence is solid enough to make the analysis concrete. It is not enough to make the service resilient by itself. The buyer still needs to know whether the Tbilisi facility is the only live production site for the purchased service, whether backups leave the site, whether failover uses another Cloud9 location or only another cluster in the same building, and whether customer contracts distinguish "available for sale" from "usable after a fault."

Power claims are specific, but runtime is still the test

Cloud9's public power claims are unusually specific for a regional hosting provider. The data-centre page states that the facility is powered by three independent power substations and has a 630 KVA diesel generator. The same page says the colocation zone uses N+N redundant power feed with UPS support. The colocation page repeats the promise in customer-facing terms: rack packages list A/B dual power for 1U and 2U servers, while tower-server service is listed with single power.

Those details are useful because they create measurable questions. Three substations can reduce utility concentration, but the phrase does not reveal whether the feeds are simultaneously live, whether they enter the building through physically separated paths, whether switchgear has a single failure point, whether maintenance can be done without exposing customers, or whether all colocation cabinets can draw their contracted load during a utility event. A 630 KVA generator is a serious piece of equipment, but the relevant number is not the plate rating.

It is the tested runtime and load profile after UPS transfer, fuel delivery, cooling demand and non-IT building loads are included.

N+N power is also a claim that needs cabinet-level proof. If both sides of a dual-feed cabinet are genuinely independent, a single feed failure should not shut down dual-corded customer equipment. But many customer failures happen at the edge of a well-designed power plan: a single-corded device connected through the wrong power distribution unit, an overloaded A side during maintenance, a breaker trip caused by a customer burst, a generator test that does not include real load, or a remote-hands task that leaves a cable in the wrong path.

Cloud9's public material does not show how frequently failover is tested or how customers receive evidence.

The tower-server package matters because it openly uses single power. That is not a flaw; it is a service tier. It does mean that customers cannot infer data-centre-wide power resilience from a product that may use one electrical path at the device. The buyer should match workload criticality to equipment design. A non-critical server can rationally accept a single power path. A production system that must survive a feed failure needs dual-corded equipment, tested A/B distribution, enough spare power headroom and a contract that explains what Cloud9 will do during maintenance.

The biggest power question is not whether the marketing page names components. It is whether Cloud9 can provide recent, customer-relevant evidence: last full generator load test, transfer-test dates, UPS maintenance windows, fuel-supply arrangement, maximum supported rack density, actual customer load, and incident history. Without that evidence, the facility may still be good, but the buyer is relying on a promise rather than a demonstrated failure state.

Cooling, fire protection and security narrow the possible failure paths

The facility page offers a comparable set of claims for cooling, fire protection and physical security. Cloud9 says temperature and humidity are controlled by a DX cooling system. It says server rooms have no windows or outside-facing walls, and that nearby plumbing is limited to the fire-suppression system. It also says the data centre uses early temperature, smoke and fire detection, plus a Novec 1230 fire-suppression system. For access control, the page points to CCTV, biometric controls, a seismic-standard building and guarded premises.

These claims matter because a data-centre outage is often not a pure power outage. Cooling can become the binding constraint during a grid event, a generator event or a high-density cabinet deployment. If chilled air capacity, airflow management or compressor redundancy is weak, servers may run out of thermal headroom even when power remains available. DX cooling can be a perfectly valid design choice, but the customer needs to know the number of units, redundancy pattern, maintenance practice, spare-part availability and heat-removal capacity at the contracted rack density.

Fire protection also has a hard boundary. The presence of a gas-based fire-suppression system is comforting only if detection, zoning, pressure retention, staff response and customer communication are current. A false discharge can interrupt service. A real fire can make access impossible even if equipment is not destroyed. Smoke or heat damage can leave customer gear in an uncertain state. The public claim shows an intended protection layer, not the tested recovery path after an alarm.

Security has a similar distinction. Biometrics, CCTV and guards reduce unauthorised access risk. They do not answer who can enter during an emergency, how customer access is approved, how quickly a remote-hands task can be performed, or whether facility access remains available during a citywide disruption. Cloud9's colocation FAQ says customer visits must be scheduled and that visitors need valid ID. The terms say colocation customers can request 24/7 access by prior arrangement through the customer account or email. Those rules are sensible, but they also mean access is mediated by Cloud9's support and facility staff.

This is why physical infrastructure should be read as a system. Power, cooling, fire protection, access control and support labour are not independent marketing boxes. A failed cooling unit can require power work. A power event can raise cooling load. A fire alarm can suspend access. A security rule can slow repair. A customer should ask Cloud9 for the combined scenario: what happens if a power feed fails while a cooling component is under maintenance, or if a customer server needs hands-on work during a facility access restriction?

Carrier neutrality must mean more than a carrier list

Cloud9 uses the phrase carrier-neutral on its data-centre page and says it is also an IXP operator. The same page states that Cloud9 is connected to leading telecommunications carriers and smaller ISP operators through reserved dark fibre with several alternative routes and total interconnection capacity of 250 Gbps. The colocation page says direct fibre connections to major local ISPs help deliver low-latency local reachability.

The routing evidence gives partial support to the interconnection story. RIPEstat ASN neighbours for AS57814 shows 12 observed neighbours in the checked view, including Georgian networks such as Magticom, Caucasus Online, System Net, Silknet and Skytel, as well as other adjacent networks and IXP.ge. PeeringDB's AS57814 network profile lists Cloud9 as a regional network-services network with IPv6 support, open peering policy, one facility and one exchange presence. PeeringDB's Cloud9 netixlan entry shows a 10 Gbps connection at IXP.ge.

Those are meaningful signals. They are also not enough to prove carrier-path diversity. Route collectors can show adjacent ASNs, but they cannot show whether separate carriers enter through separate ducts, whether cross-connects share a meet-me room, whether one upstream dominates international reachability, whether local peers carry production traffic during an upstream fault, or whether customer contracts include any route-diversity guarantee. A network can have several logical neighbours and still share a vulnerable physical path.

The public AS57814 route policy in RIPE registry-derived data names several upstream or adjacent ASNs in import and export statements. The exact AS203301 record is narrower: RIPE registry-derived data for AS203301 lists policy statements involving AS34797 and AS35076, while the current route status shows no live announcements. That difference is another reason to ask which route plan applies to a given customer service.

The carrier-neutral claim is therefore plausible but incomplete. A customer should ask for current upstreams, public and private peering arrangements, cross-connect options, meet-me physical paths, maintenance-notice commitments, route-security practices and measured failover results. The phrase "carrier neutral" should mean a customer can make real choices among carriers and routes. It should not simply mean the facility is willing to sell a cross-connect if the customer can arrange one.

AS57814 shows breadth that AS203301 does not

The strongest current network evidence is AS57814, not AS203301. In the July 12, 2026 RIPEstat view, AS57814 has a broad footprint for a Georgian regional hosting and data-centre operator: 27 IPv4 prefixes, 3 IPv6 prefixes and full visibility from RIPE RIS peers in both address families. RIPEstat announced prefixes for AS57814 includes IPv4 routes such as 188.93.94.0/24, 185.139.56.0/24, 185.139.57.0/24, 185.139.58.0/24, 45.138.44.0/22 and several other /24s, plus IPv6 space including 2a0d:8a00::/32.

That breadth changes the article's conclusion. If only AS203301 existed, the evidence grade would be weak or negative for present routing. AS57814 prevents that. It shows a live Cloud 9 Ltd. network with IPv4 and IPv6, multiple neighbours and current routing-security support. RIPEstat RPKI validation for 188.93.94.0/24 under AS57814 returns valid, and the same is true for the checked Cloud9 /24s carved out of the older 185.139.56.0/22 space.

The contrast with AS203301 is sharp. RIPEstat prefix overview for 185.139.56.0/22 shows the aggregate itself not announced, with related /24s now visible. RIPEstat prefix-routing consistency for 185.139.56.0/22 shows 185.139.56.0/24, 185.139.57.0/24 and 185.139.58.0/24 in live BGP under AS57814, while the /22 route object is not live. RIPEstat RPKI validation for AS203301 and 185.139.56.0/22 returns an invalid-asn result because the route authorisation in the checked view points to AS57814, not AS203301.

That does not mean Cloud9 is misrouting. It means the active route authority appears to have moved to AS57814. For a buyer, that is a documentation issue and a resilience issue. Contracts, service descriptions and incident playbooks should name the ASN actually carrying service traffic. If AS203301 is retained as a dormant or legacy data-centre entity, Cloud9 should be clear about that. If it is expected to return, the route-origin authorisation and route policy should be changed before customer traffic depends on it.

IXP.ge improves the local story but does not remove international risk

Cloud9's interconnection claim is helped by IXP.ge evidence. PeeringDB's IXP.ge record identifies IXP.ge, also known as Geo-IX, in Tbilisi and notes that the exchange is available in Tbilisi and Kutaisi. IXP.ge's own about page describes the exchange association's purpose as direct exchange of internet traffic between Georgian networks without using third-party networks. IXP.ge's members page lists Cloud9 among full members.

This is positive for local reachability. When local ISPs, hosting providers and service networks exchange traffic locally, domestic traffic can avoid unnecessary detours through foreign transit. Lower latency and less dependence on a single foreign path can matter for Georgian customers, content, government-facing services and small businesses that mostly serve users inside the country. It also fits Cloud9's claim that local connectivity is a differentiator.

IXP participation should not be confused with full redundancy. Peering at an exchange can reduce the load on upstream transit and improve local paths, but it does not automatically protect a customer from facility power failure, switch failure, route-server issue, fibre break, international congestion or DNS and application-layer outages. PeeringDB lists Cloud9's IXP.ge port at 10 Gbps in the checked record; Cloud9's own data-centre page separately advertises 250 Gbps of total interconnection capacity. Those two figures can both be true if the latter includes private cross-connects, upstreams and other local capacity.

Public records do not reconcile the composition.

The more relevant question is which paths carry which traffic when something breaks. If the primary international upstream fails, how much traffic moves to other upstreams and at what quality? If the IXP port fails, do local users remain reachable through transit? If a fibre route into Dinamo Arena is damaged, are alternative routes truly separate? If a customer buys a cross-connect, is it on a diverse path from Cloud9's own upstream links or in the same physical bundle?

Cloud9's public material gives the buyer enough to ask good questions. It does not provide enough to treat local peering as disaster recovery. The best version of the service would combine a live AS57814 edge, IXP.ge local traffic, several independent upstreams, visible route-security hygiene and clear customer traffic-engineering options. The public record supports some of that picture. It leaves the physical path and failover tests to be proved.

Colocation packages reveal where usable capacity can shrink

Cloud9's colocation menu is unusually transparent about the base package. The colocation page lists 1U and 2U rack packages with A/B dual power, 1 Gbps link and a separate management link. It also lists a tower-server option with single power. The page states that each customer receives unmetered 1 Gbps connectivity to Georgian ISPs and 30 Mbps global connectivity, and it describes half-rack, full-rack and cage options as custom or enterprise arrangements.

Those numbers are not just prices. They define the customer-visible constraint. Local connectivity may be abundant relative to many small workloads, while global connectivity per basic colocation customer is bounded. A Georgian customer serving mostly domestic users may find that acceptable. A company serving international users, remote workers, cross-border APIs or global backups should test the global path carefully. Thirty megabits per second may be enough for management, small sites or low-traffic services, but it is not a blanket cloud-capacity claim.

The distinction between installed and usable capacity matters here. A facility can advertise high aggregate interconnection while individual products are sold with narrower global allowances. A rack can have dual power while a customer's own server has one power supply. A management link can be available while a failed operating system still requires human action. A cage can be tailored while shared facility resources, access scheduling and generator capacity remain common.

Cloud9's FAQ is helpful because it states boundaries. For colocation, hardware failure remains the customer's responsibility, while Cloud9 says it will assist with repair. Visits need to be scheduled. Full rack and cage installations may take more time than a single-server installation. These are normal terms, but they mean recovery is shared. A customer cannot outsource every failure just by placing gear in the facility.

The customer should therefore ask for a product-by-product resilience table. For 1U and 2U service, what happens if one feed fails? For tower service, is any single-power redundancy available through an automatic transfer switch? For half racks, what power density is included? For cages, what carrier options are physically reachable? For all service types, how much global capacity remains available during upstream maintenance or failure? Public package tables are a useful starting point, not the final answer.

VPS, VDS and dedicated servers turn facility claims into customer commitments

The hosted-server products add another layer. Cloud9's VPS page offers managed and self-managed packages with KVM virtualisation, daily backups, control-panel options and advertised local and global network speeds. The VDS page offers larger fixed-resource virtual servers. The dedicated-server page lists managed and self-managed packages, says servers can be set up within 24 to 48 hours when available in stock, and describes enterprise-grade drives, redundant network connections and redundant power supplies.

These claims move the risk from a pure facility question to an operations question. For VPS and VDS customers, Cloud9 controls the host, storage, virtualisation layer, backup system, IP allocation, control panel and support channel. A customer may not know which physical server or rack carries the workload. The resilience proof therefore has to include backup restore tests, host failure response, storage isolation, monitoring, customer communication and the ability to move a virtual server without a long outage.

Daily backups are useful, but a backup claim is not a recovery claim until restore time is known. A small website may tolerate a next-day restore. A business portal or transactional service may not. Backups also need placement detail. If backups sit in the same facility, they may protect against file deletion and server failure but not against a facility-wide incident. If backups leave the facility, the buyer needs to know where they go, how they are encrypted, how fast they can be restored and what happens when the customer exits.

Dedicated servers create a different burden. Cloud9 says processor availability depends on stock, and custom requirements can add installation time. That is normal, but it matters during a failure. If a dedicated server fails, is there a hot spare, a same-day replacement, or only best-effort stock? If a disk fails, who replaces it and how quickly? If a customer self-manages the server, where does Cloud9's responsibility end? If redundant power and network connections are present, are they connected to independent facility paths?

The article's central question is therefore not whether Cloud9 sells hosted products. It clearly does. The question is whether the marketed capacity can be turned into a tested recovery outcome for each product. VPS, VDS, dedicated server and colocation customers buy different parts of the stack. They should receive different resilience evidence.

The terms disclose a maintenance and access boundary

The Cloud9 terms of service are important because they disclose parts of the operating boundary that the marketing pages do not. The terms name Cloud 9 LLC, give company ID 405063755, state a Georgian legal address, and list the product categories offered through the Cloud9 site and portal. They define data-centre services to include telecommunications rack rental, cross-connects, power distribution units, internet-provider and mobile-operator interconnection, and IP address rental.

For colocation, the terms say customers must book facility access through the customer account or email, provide visitor details and follow data-centre conduct rules. They also say customers can request 24/7 access by prior agreement and can request 24/7 remote-hands service for tasks such as rebooting or cable replacement. Those are valuable commitments, but they still depend on staff availability, ticket handling and facility conditions at the time of the incident.

The most important maintenance statement is that Cloud9 is authorised to conduct pre-planned technical works for colocation service, with duration not exceeding eight hours. That clause should not be read as an outage guarantee, but it is a serious operational boundary. If a customer needs continuous service, it should understand whether planned work can affect one feed, one router, one meet-me path, one customer cage, or the full service. It should also understand how much notice is given, whether redundant customers can avoid impact, and how emergency works differ from planned works.

The terms also promise 24/7 technical support by email, and the contact page says email opens a ticket. That is useful for service operations, but email-based support can be fragile during incidents if the customer's email system is hosted at the same provider or if the portal is affected. A serious customer should keep an out-of-band contact path and know whether support can act when customer identity, billing or portal access is impaired.

Contracts often carry the real answer to infrastructure risk. Marketing pages describe what the operator wants to sell. Terms describe where responsibility is shared, limited or scheduled. In Cloud9's case, the terms do not undermine the data-centre story; they make it more concrete. They show that customer access, remote hands, planned works, backups and support are part of the service boundary. The buyer's job is to convert those clauses into measurable operational commitments.

The route-security picture is better on the active edge

Route security is one area where the active Cloud9 edge looks better than the dormant ASN. RIPEstat RPKI validation for 188.93.94.0/24 originated by AS57814 returns valid. The checked Cloud9 prefixes 185.139.56.0/24, 185.139.57.0/24, 185.139.58.0/24, 45.138.44.0/22 and 2a0d:8a00::/32 also return valid when tested against AS57814. That is a positive hygiene signal for the routes customers are more likely to see today.

The exact AS203301 picture is the opposite. The old 185.139.56.0/22 aggregate is not live as an aggregate in the checked prefix overview, and an AS203301 origin validation check for that aggregate returns invalid-asn because the visible authorisation is for AS57814. That should not be sensationalised. It simply reinforces that AS203301 is not the current route edge for the old address block.

For a data-centre buyer, this matters because route-origin validation can affect reachability during a route change. If a provider shifts a prefix between ASNs, changes upstreams, introduces a backup announcement, or deaggregates during an incident, route authorisation needs to match. Otherwise, networks that filter invalid routes can drop the traffic at exactly the moment resilience is needed. Cloud9's AS57814 evidence is encouraging because the active edge validates. AS203301 should be documented as quiet unless and until the authorisation and route plan are changed.

The buyer's question is simple: which prefixes will my service use, what is their current RPKI state, and who can change authorisations during an emergency? For colocation customers bringing their own addresses, the question becomes whether Cloud9 supports customer route objects, ROAs, BGP sessions and emergency route changes quickly enough. For Cloud9-provided addresses, the company should be able to show current valid origin state and explain its backup announcement plan.

Route security will not keep a generator running or a cooling unit online. It does, however, remove one preventable failure mode. In a facility that sells carrier neutrality and hosted capacity, the network-control plane should be as well documented as the power plant.

Installed capacity is not the same as ready capacity

The capacity question should be split into three layers: what Cloud9 has installed, what it is willing to sell, and what remains ready after a fault or expansion request. The public site is rich on service categories but thin on physical headroom. It advertises colocation units, half racks, full racks and cages on the colocation page, and it advertises custom data-centre requirements on the data-centre page. It does not publish live cabinet availability, power-density limits, reserved cooling margin, spare breaker capacity, spare server inventory or the time needed to add a new carrier path.

That missing layer matters because marketed capacity can become constrained before a room is full. A rack may be physically empty but unavailable at the power density a customer needs. A generator may support today's load but leave little margin for a new high-density row. A cooling design may support standard hosting racks but require changes for dense compute. A fibre entrance may support current providers but need new civil work for a requested diverse route. In each case, the sales page can be true while the usable capacity for a specific customer is not immediately ready.

Local approvals and building constraints should also be part of the buyer's diligence. Cloud9's public pages identify the Dinamo Stadium/Tsereteli Avenue location and describe the data centre as built and managed by Cloud9, but they do not disclose expansion permits, utility upgrade commitments, construction phases or landlord and stadium-site constraints. That absence is not evidence of a problem. It is evidence that a customer should not treat future rack or cage capacity as a finished asset until Cloud9 confirms the delivery path, the power path, the cooling path and the cross-connect path in writing.

The same caution applies to the 24-hour installation statement for some colocation services and the 24-to-48-hour setup statement for dedicated servers. Those timings are useful for standard orders. They should not be reused for a full rack, a cage, a carrier build, a high-density deployment or a recovery migration unless Cloud9 says the exact configuration is available. The failure path in this article includes construction delay because an expansion promise often fails quietly: the customer signs before the breaker, rack, patch path, server stock or carrier route is actually ready.

The buyer should therefore ask for a readiness statement, not only a price quote. Which cabinets are live now? Which power feeds are already commissioned? Which carriers are already present at the requested meet point? Which routes require new work? Which servers are in stock? Which parts are held locally? Which upgrades need utility, facility or supplier approval? These questions turn a broad data-centre claim into a delivery commitment.

Who is affected when the Tbilisi anchor fails

The visible customer base is not fully disclosed, but Cloud9's about page advertises more than 1,200 active clients, more than 3,500 active services, more than 5,000 registered domains and 99.9 percent system uptime. Those figures are operator-published and should be treated as marketing figures unless contractually documented, but they show the type of dependency at stake. This is not merely an empty ASN with no customer promise attached. It is a hosting and data-centre business presenting itself as a local infrastructure provider.

If the Tbilisi facility fails, different customers fail differently. Colocation customers may lose power, cooling, management access or uplink capacity while still owning the equipment. VPS customers may lose virtual servers, control panels, backups or DNS updates. Dedicated-server customers may wait for hardware repair or replacement. Domain and hosting customers may experience email, website and account disruption. Customers using Cloud9 for migration or managed support may need staff action at the same time everyone else is asking for help.

Locality cuts both ways. A Georgian operator with local support can be valuable for language, jurisdiction, payment, access and low-latency domestic service. It can also create concentration if many small Georgian businesses, developers and organisations rely on one Tbilisi building and one provider's support desk. The impact of an outage is not measured only by total prefix count or global traffic share. It is measured by the customers who have no second site, no second provider and no tested export path.

The route evidence suggests Cloud9 has a real network beyond a small stub. AS57814's current prefix count, neighbours and IPv6 support are meaningful. PeeringDB's Cloud9 Dinamo Arena facility record adds a physical interconnection layer. IXP.ge membership adds local-exchange relevance. But the public record does not show customer failover outcomes. It does not show how many customers run single-site services, how many use backups outside the facility, how many have dual-carrier service, or how many know the difference between local and global bandwidth allowances.

That uncertainty is precisely why the assigned article title matters. Marketed data-centre capacity has to survive power and carrier constraints, not merely describe them. Cloud9's public story is credible enough to deserve scrutiny and specific enough to make the scrutiny fair. The missing proof is not identity. It is tested survivability.

What would raise the evidence grade

Cloud9 could raise confidence without exposing sensitive facility details. A public network page could state the current role of AS203301, the active role of AS57814, the main AS set, customer BGP options, route-security policy and route-authorisation practice. A facility page could preserve security while giving ranges for live cabinet count, available rack density, supported power densities, generator runtime, UPS redundancy, cooling redundancy and maintenance notice standards. A status page could separate facility, network, hosting, DNS, portal and email services.

For enterprise colocation, the most valuable evidence would be customer-specific. Buyers should ask for a recent generator load-test summary, UPS maintenance evidence, cooling redundancy design, remote-hands response targets, incident-communication samples, route-failover evidence, cross-connect diversity options, backup placement, restore-time evidence and a clear statement of which services are single-site. If the answer varies by product, it should vary in writing. A tower server, a 1U dual-power server, a full rack and a managed VDS do not share the same risk profile.

The current evidence supports a Medium grade. AS203301 alone is not live and should be downgraded. Cloud9's broader operation is visible through official facility pages, legal terms, AS57814 routing, PeeringDB facility and exchange entries, IXP.ge membership and valid route-origin checks on active prefixes. The remaining gaps are the ones that usually matter during an outage: actual power path independence, generator endurance, cooling failover, carrier physical diversity, maintenance impact, spare hardware, backup restore, and customer migration proof.

The practical conclusion is direct. A buyer should not reject Cloud9 only because AS203301 is quiet. It should not buy critical capacity only because the website says carrier-neutral data centre. The right move is to treat Cloud9 as a real Georgian data-centre and hosting operator whose live evidence is concentrated in AS57814 and the Tbilisi facility, then require proof that the purchased service keeps working when one feed, one cooling path, one carrier path, one server host or one support channel fails.