Summary

The company is visible enough to analyze

Cloud9 Cloud 9 Ltd. deserves a more concrete reading than many small hosting entries because several independent public records align. The company site uses the Cloud9 brand for a Georgian hosting and data-center business. The home page describes Cloud9 as a professional web hosting provider and experienced data-center operator in Georgia. The footer lists an operating address at 2 Akaki Tsereteli Ave., Dinamo Stadium, Gate 5, Tbilisi, Georgia 0112, with a phone number and support email. The terms of service identify "Cloud 9 LLC", company ID 405063755, with a legal address in Tbilisi and contact emails for contract and support matters. The naming is not perfectly uniform across public surfaces, but the address, domain and registry evidence point to the same Georgian hosting operator.

The RIR records make that identity more than a website claim. RIPE RDAP for AS57814 lists the registrant organisation as Cloud 9 Ltd., shows the address as 2 Tsereteli ave, 0112, Tbilisi, Georgia, and gives public administrative, technical and abuse contacts. RIPE RDAP for ORG-CL434-RIPE gives the organisation as Cloud 9 Ltd., the same Tbilisi address, a phone number and contact email. RIPE RDAP for AS49297 ties another autonomous system to the same organisation and contact set.

That matters because the company's visible services are infrastructure services. Cloud9 sells customer-facing capacity: shared hosting, virtual servers, dedicated servers, colocation, email, domains, certificates and data-center services. A customer who buys those services is not merely buying a brand; the customer is relying on rack space, power, routing, support labour and contract terms. The public evidence is strong enough to place Cloud9 in that category. It is not strong enough to answer every customer-continuity question without contract and design documents.

The most important framing is therefore practical. Cloud9 is visible as an operating Georgian hosting and network provider. It also concentrates much of the customer story around a named Tbilisi facility. That combination is useful for regional service and data locality. It also means a customer should ask where each service actually runs, how it fails, how it recovers, and what happens if the customer needs to leave quickly.

The network record has two AS numbers, but only one is visibly active

The public routing picture has a clean center and one important caveat. RIPEstat's AS overview for AS57814 shows the holder as Cloud9 Cloud 9 Ltd. and marks the AS as announced at the 12 July 2026 query time. RIPEstat's AS overview for AS49297 shows the same holder string but marks that AS as not announced at the same query time. RIPEstat announced-prefix data for AS57814 lists a broad set of visible routes, including 185.229.110.0/24, 45.138.44.0/22 and 195.69.140.0/22 among others, while the same endpoint for AS49297 returns no announced prefixes.

That distinction should be preserved. It would be wrong to say that every Cloud9-related AS is actively carrying traffic. It would also be wrong to say the company has no visible network. AS57814 is clearly alive in the public route view. RIPE RIS prefix counts show 28 originating IPv4 prefixes, 13 transiting IPv4 prefixes, three originating IPv6 prefixes and two transiting IPv6 prefixes for AS57814 at the 12 July 2026 query time. Those counts do not prove how many customers are active, how full the platform is, or how much spare capacity exists, but they do show a network surface materially larger than a single dormant route.

The route examples also show current prefix visibility. RIPEstat prefix overview for 185.229.110.0/24 says the prefix is announced by AS57814 and relates it to 185.229.108.0/22. RIPEstat's BGP state sample for 185.229.110.0/24 returned hundreds of route observations, with paths reaching AS57814 through upstream or peer ASes such as AS20771 and AS35805 in the sample. BGP.tools for AS57814 describes Cloud 9 Ltd. as a long-running network that peers with other networks and has upstream carriers, and BGP.tools for 185.229.110.0/24 shows that prefix originated by AS57814.

The operational inference is balanced. Cloud9 is not a placeless reseller with no network. The company has a live AS, IPv4 and IPv6 visibility, route objects and public peering data. But route visibility is not the same as a customer guarantee. A customer still needs to know which of its workloads sit on Cloud9's own prefixes, which sit on vendor platforms, which routes carry backup services, and whether a failover event has enough headroom after normal customer load.

The data center is the heart of the offer

Cloud9's data-center page is unusually direct about physical dependence. It says most of the services provided by Cloud9 are delivered from its own Tbilisi-based data center. The page describes a carrier-neutral data center, 24/7/365 monitoring by engineers, security controls, power redundancy, fire detection and suppression, climate control and interconnectivity. It says the facility is powered by three independent power substations and a backup 630 kVA diesel generator; it also says the colocation zone has N+N redundant power feed with UPS. For connectivity, Cloud9 says it is connected to leading telecommunications carriers and small ISP operators through reserved dark fibre with several alternative routes and 250 Gbps total interconnection capacity.

PeeringDB supports the Tbilisi facility claim in a different way. PeeringDB's facility record for Cloud9 Dinamo Arena lists the facility at A. Tsereteli Ave 2, Tbilisi, Georgia 0112, with Cloud9 LTD as the organisation, a note that the business provides data-center, hosting, cloud and ISP services in Georgia, net count 7, exchange count 1 and carrier count 1. PeeringDB's network-facility relation for net_id 20057 also ties AS57814 to Cloud9 Dinamo Arena. That public PeeringDB evidence does not certify the engineering design, but it gives an independent facility anchor that matches the address pattern on Cloud9's own pages.

The key issue is installed versus usable capacity. A data-center page can name substations, UPS and a generator, but a customer needs to know how those assets behave under maintenance and failure. How many racks are actually built out and powered? What is the per-rack power allowance? How much spare UPS and generator capacity remains after current load? How much fuel is contracted during a long utility outage? Are power paths truly independent to the customer rack, or are they shared before a failure point? How is generator start tested under load? The public pages do not answer those questions at customer depth.

The same distinction applies to connectivity. A 250 Gbps total interconnection statement is meaningful, especially in a regional market, but it is not the same as customer-available bandwidth during a fault. A customer needs to know whether its service uses shared transit, an IXP path, a private cross-connect, a local ISP route, or a Cloud9 backbone path; whether the backup path exits the same building; and whether any bandwidth guarantees survive a fibre cut or carrier maintenance. Cloud9's public pages give enough confidence to treat the data center as real.

They do not remove the need to test what a customer can actually consume during stress.

Hosting is a rack service before it is a cloud service

The Cloud9 retail menu is broad. The company sells Linux shared hosting, Windows shared hosting, VPS, VDS, dedicated servers, Zimbra email, domains, certificates and colocation. The terms of service describe hosting services, domain registration, virtual server rental, physical server rental, email services, data-center services, security and DDoS defence, server infrastructure planning, DevOps services and cloud services. Those are not all the same dependency.

Shared hosting depends on web servers, control panels, DNS, storage and support policy. VPS depends on the physical host, hypervisor, storage, snapshots and noisy-neighbour controls. VDS is advertised as a stronger virtual server product, but it still depends on the physical server allocation and failover design. Dedicated server rental depends on Cloud9-owned hardware, replacement stock, remote console access and staff availability. Colocation depends on the customer's own equipment, Cloud9 rack services and the customer's ability to repair or authorise remote hands.

Email depends on mail server operation, spam filtering, DNS, storage, backups and migration tooling.

The public product pages make the retail offer legible, but they cannot prove resource availability by themselves. A VPS plan can list CPU, memory and storage, yet real performance depends on contention, storage layout and failure capacity. A dedicated server can be available for purchase, yet a failed motherboard, disk or power supply depends on spare inventory and staff response. A shared-hosting account can be inexpensive, yet restore time depends on backup frequency, backup integrity and whether the backup system is isolated from the failed server.

A domain or email service can be managed through a customer portal, yet the customer's recovery may depend on whether DNS and mailbox exports can be moved quickly.

That is why hosted capacity still needs a physical audit by the customer. The question is not simply whether the service exists. It is whether the service remains usable after one host, one switch, one storage system, one cooling unit, one power path, one cross-connect or one support shift fails. Cloud9's public information supports a real service provider with a facility and network. It does not publish enough detail to infer customer-specific survival under each of those failure modes.

Colocation draws a clear ownership boundary

The colocation page is one of the most valuable public sources because it exposes the boundary between Cloud9-owned capacity and customer-owned equipment. Cloud9 sells 1U, 2U and tower colocation options, half racks, full racks and custom cages. The 1U and 2U offers include A/B dual power, a 1 Gb/s link and a management link; the tower server offer lists single power, a 1 Gb/s link and a management link. The page says the 1 Gb/s connectivity is unmetered to Georgian ISPs and includes 30 Mb/s global connectivity per customer. It also says the management link is for IPMI, iLO, iDRAC or BMC access with internal IP and secure VPN access.

Those details are commercially useful and also reveal the limits. Colocation is not the same as managed dedicated hosting. Cloud9's FAQ states that in colocation the equipment is the customer's responsibility, while Cloud9 will offer assistance in speeding correction. It says Cloud9 has engineers available 24/7/365 for remote hands, and that Cloud9 has performed large-scale migrations, with each migration depending on the workload. It also says space and IP addresses can be ready in under 24 hours after quote and initial payment, while full racks and cages may take more time because of parts and labour.

For customers, that boundary is decisive during outages. If a colocated server has a disk failure, power supply fault or firmware problem, Cloud9 can provide remote hands only within the customer's contract and the available spare parts or replacement plan. If the customer has no spare disks, no remote console credentials, no documented boot media and no migration target, the rack can remain powered while the application stays offline. The same is true for network changes: a management link helps only if the customer has access rights, VPN details, known credentials and a tested console path.

The pricing and bandwidth language also deserves care. A local 1 Gb/s link and 30 Mb/s global connectivity may be enough for many Georgian hosting uses, but it is not the same as global cloud bandwidth. A customer serving international users, offsite backups or large data exports needs to know how burst traffic, billing, congestion and emergency migration behave beyond normal monthly use. The colocation page gives Cloud9 credit for making the boundary public. It also gives buyers the terms they should verify before placing critical hardware there.

Peering and route diversity look better than the weakest hypothesis

The assignment's initial risk hypothesis warned of a thin public footprint. The actual route and peering evidence is stronger than that. PeeringDB's AS57814 network record lists Cloud9 as a network-services profile with AS57814, website https://www.cloud9.ge/, IPv6 support, regional scope, heavy outbound traffic, 200-300 Gbps self-reported traffic, an open general peering policy, one facility and one exchange count. It lists the IRR AS set as AS-SET-CLOUD9. The profile is self-maintained and should not be treated as audited capacity, but it is a public infrastructure profile, not a blank page.

PeeringDB's netixlan entry lists Cloud9 on IXP.ge with a 10,000 Mb/s port, IPv4 address 185.1.224.232, route-server peer status true and operational status true. PeeringDB's IXP.ge record describes the exchange as in Tbilisi and Kutaisi, with Cloud9 Dinamo Arena among the facility entries. Cloud9's own data-center page says the company is also an Internet Exchange Point operator and provides cross-connection to carriers. Taken together, these sources support a meaningful local interconnection role.

RIPEstat also shows route-policy consistency across a wider set of prefixes and peers. AS-routing consistency for AS57814 lists many prefixes as present both in BGP and in whois routing data, including 45.138.44.0/22, 185.229.108.0/24, 185.229.109.0/24, 185.229.110.0/24, 188.93.88.0/24 and 195.69.140.0/22. It also shows several import and export peers in BGP and whois, including AS49628, AS20771, AS35805, AS16010 and AS34797, along with other BGP-visible peers not present in the checked whois data. RIPEstat AS path-length data shows AS57814 visible from many collector locations.

This is not the profile of a one-prefix host with a single observable upstream. Still, diversity at the routing layer must be translated into service resilience. A route can have multiple paths while a customer service still depends on one top-of-rack switch, one storage array, one power distribution path or one support decision. A customer should ask which providers are used for its service, whether routes are actively monitored, whether Cloud9 can shift traffic during a maintenance event, and whether international reachability remains acceptable when one peer or transit provider is impaired.

Routing hygiene is partial but visible

Routing security is a place where Cloud9 has visible evidence, though it should be assessed prefix by prefix. RIPEstat RPKI validation for AS57814 and 185.229.110.0/24 returns a valid status, including validating ROAs for origin 57814 covering 185.229.110.0/24 and 185.229.108.0/22. That matters because valid route origin authorization helps networks reject announcements from the wrong origin for that prefix. It does not solve application downtime, but it reduces one class of routing mistake or hijack.

The AS-routing consistency endpoint gives another positive sign by showing many Cloud9 prefixes in both BGP and whois routing data. The PeeringDB profile's AS set also gives networks a public entity to use in routing policy. These are good signals for a regional provider because many operational incidents begin with a route filter, stale entity, missing ROA or mismatch between what a provider announces and what an upstream is willing to carry.

The caveat is that the evidence is not universal certification. The RPKI validation link above validates one representative prefix, not every route. The AS-routing consistency output shows some whois routes not currently in BGP and some peers in BGP but not in the checked whois policy. That is normal for many networks, but it means customer-facing claims should be measured against the exact prefix or service. A customer using an address from a particular block should ask whether that block has a valid ROA, a maintained route object, documented upstream filters and a monitoring contact who can respond to route leaks or reachability loss.

Routing hygiene should also be connected to migration rights. If a customer's service uses Cloud9-provided IP addresses, the customer needs to know whether those addresses can move with the workload or whether DNS, certificates, allowlists and mail reputation must be rebuilt elsewhere. Cloud9's network evidence is strong enough that customer services may be deeply integrated with its address space. That makes clean documentation more important, not less.

Power and cooling claims need customer-specific proof

Cloud9's public data-center claims are detailed enough to use, but not detailed enough to replace engineering evidence in a contract. The data-center page says the facility is supplied by three independent power substations and a 630 kVA diesel generator. It says the colocation zone has N+N redundant power feed and a UPS system. It describes early temperature, smoke and fire detection, a 3M Novec 1230 fire suppression system, DX cooling, temperature and humidity control, no windows or outside-facing walls in server rooms and only fire-suppression plumbing nearby. It also says all key systems are monitored 24/7/365 by engineers.

Those are the right categories: power, fire, cooling, physical security and monitoring. The remaining question is whether the customer receives redundant service after ordinary maintenance and credible failure events. If a customer buys 1U colocation with A/B dual power, are both feeds genuinely carried to separate upstream power paths, or can one upstream component still affect both? If a customer buys tower colocation with single power, has the customer priced the risk of a single power supply? If a customer rents a dedicated server, does the contract include component replacement times and a hardware replacement path?

If a virtual server runs on Cloud9 hardware, what level of host or storage failure can the platform absorb without downtime?

Cooling has similar hidden constraints. DX cooling may be appropriate for the facility, but the customer needs to know the rack-level density limits, hot-aisle and cold-aisle design, sensor placement and escalation path when a rack runs hot. A facility can have a redundant cooling design while a specific customer rack is still constrained by airflow or power density. Fire suppression also matters differently for physical colocation and virtual services. A fire suppression event may protect equipment from worse damage, but it can still result in emergency access controls, inspection windows and recovery delays.

The public site says the facility is Tier 3 in the sense that it can schedule maintenance without disrupting service. The colocation FAQ explains Tier 3 as Uptime Institute's classification system and says Cloud9's data center is on Tier 3. Customers should ask whether Cloud9 holds a current third-party certification or uses the term to describe design intent. The distinction is not pedantic. A design aligned with Tier III concepts is useful, but a certified facility, an audited maintenance record and a customer-specific redundancy letter carry different evidentiary weight.

The portal simplifies service, but billing and access become dependencies

Cloud9's terms of service are important because they show how customers actually touch the infrastructure. The terms say a user registers on cloud9.ge and receives a personal account on the Cloud9 portal at my.cloud9.ge, where the user can purchase new products, manage existing products, cancel unwanted products, control payments and open support tickets at any time. The terms also state that the user is responsible for maintaining account confidentiality and for actions taken with the account.

That portal design is useful. It lets customers manage infrastructure without waiting for a sales conversation. It also makes account access a continuity dependency. If the customer's authorised email account is lost, if credentials are compromised, if a staff member leaves, or if billing contacts are not updated, the customer's ability to open tickets, cancel services, control payments or make emergency changes can be impaired. The terms put responsibility on the user to keep contact persons, registration data, email and telephone details current. That is ordinary legal language, but it becomes operational during an outage.

Billing is another repair-path dependency. If an invoice or settlement period issue disables a service, the customer may experience a technical outage whose root cause is administrative. The customer should know how Cloud9 notifies account contacts, how much notice applies before suspension or termination, whether emergency restoration is available after payment, and which person can authorise a change during a crisis. Public terms can describe the general contract. Critical customers still need account governance: shared ownership of the portal, documented contacts, offboarding rules and tested support escalation.

Data retention and deletion also matter. Cloud9's terms and privacy language say personal data and service-delivery data may be stored for defined legal and service purposes, and that data may be deleted or destroyed after the relevant retention period. Customers should distinguish between account data, logs, backups, mailbox data, hosted files and virtual machine images. A customer's ability to leave Cloud9 depends on the export format, the timing of deletion, the availability of backups and whether the customer can retrieve data after cancellation.

The practical lesson is simple: the portal is part of the infrastructure. Customers should secure it like production access, assign more than one authorised maintainer, keep billing data current and verify the procedure for emergency support before the first incident.

Data sovereignty is a strength only if service placement is explicit

Cloud9's strongest locality claim is Georgian presence. The company site, terms, RIPE records and PeeringDB all point to Tbilisi. RIPE RDAP for ORG-CL434-RIPE lists Cloud 9 Ltd. in Tbilisi. PeeringDB's facility record lists Cloud9 Dinamo Arena in Tbilisi. RIPEstat geolocation for 185.229.110.0/24 places that representative prefix in Tbilisi at the July 2026 result time. The Cloud9 data-center page says most services are delivered from Cloud9's own Tbilisi data center.

For customers that need Georgian hosting, local support or low-latency access to Georgian networks, that is valuable. Many businesses do not want every workload sent to a hyperscale region in another jurisdiction, especially when customer support, regulatory requests, language and local internet paths matter. Cloud9's colocation and virtual server offers can therefore be read as a local-capacity play: the customer buys proximity, a local company, local carrier access and a local facility.

The word "most" still matters. Cloud9's public pages do not prove that every service, backup copy, email record, portal function, DNS service, security service or support dataset is stored only in Georgia. The privacy policy discusses personal data processing and service delivery, but the public text does not map every product to a storage location. The terms of service list a wide service portfolio, including domains, certificates, email, security, DDoS defence and cloud services, some of which may involve third-party systems. That is normal for hosting businesses, but it means data locality must be specified per service.

A customer with sovereignty requirements should therefore ask Cloud9 for a service-placement statement. Where is the primary workload? Where are backups? Where are logs? Where are support tickets? Which external registries, certificate authorities, email-security systems or payment processors touch customer data? Can all data be exported and deleted on a defined schedule? If the customer needs Georgian-only processing, which Cloud9 products qualify and which do not? Cloud9's public evidence supports Tbilisi as a strong center of gravity. It does not automatically settle every data-sovereignty question.

DNS and domain services make Cloud9 part of customers' control plane

Cloud9 sells domain registration, DNS-adjacent hosting and email services, so its role can reach beyond compute. The site's name-server panel lists cPanel nameservers for Linux, Windows and VPS hosting: ns1.cpanel.ge and ns2.cpanel.ge for Linux hosting, ns5.cpanel.ge and ns6.cpanel.ge for Windows hosting, and ns3.cpanel.ge and ns4.cpanel.ge for VPS hosting. Public DNS observations show cloud9.ge using ns1.cpanel.ge and ns2.cpanel.ge as authoritative nameservers, cloud9.ge resolving to 188.93.90.171, and its MX record pointing to tbs01-mail02.cpanel.ge. Those names link the retail web, hosting and email offer back to the provider's own service namespace.

This is important because DNS is a control plane, not a decoration. If a customer hosts a website, email domain or application on Cloud9 and uses Cloud9-managed nameservers, a DNS incident can affect migration, failover and recovery even when the underlying server is healthy. Conversely, if the customer keeps DNS at an independent provider and uses Cloud9 only for compute or colocation, the customer may be able to redirect traffic more quickly during a Cloud9 service issue. The right choice depends on the customer's risk tolerance and skill level.

Domain registration adds another layer. A customer that buys domains through Cloud9 should know how registry access works, whether the customer can obtain transfer codes quickly, who receives renewal notices, whether domain locks are in place, and what happens if a billing issue coincides with renewal. A domain can outlive any one hosting provider, but only if the customer keeps control of credentials, registrant details and transfer rights.

Email raises the stakes further. Zimbra email can be convenient for businesses that want a local hosted mailbox product, but mail recovery depends on DNS, mailbox backups, export formats, anti-spam reputation, user passwords and support timing. Customers should ask how mailboxes can be exported, how DNS records are restored, how long deleted mail remains recoverable and what support commitment applies during a mail outage. Cloud9's domain and email services are legitimate parts of its offer. They also make Cloud9 a control-plane provider for customers that might otherwise think they are only buying servers.

The main failure paths are ordinary, not exotic

The most credible Cloud9 failure paths are not science-fiction events. They are familiar infrastructure problems: a rack power issue, a cooling incident, a hardware failure, a route leak, an upstream carrier fault, a DDoS event, a billing suspension, a portal access problem, a failed backup, a slow spare-part replacement, a failed migration or a support queue that grows faster than staff can clear it. Because Cloud9 offers both hosted services and colocation, the customer impact depends on what the customer bought.

For a shared-hosting customer, the failure may be a website offline, database unavailable, DNS error, control-panel login issue or backup restore delay. For a VPS or VDS customer, the failure may be host contention, storage failure, hypervisor maintenance, an unreachable management console or network loss. For a dedicated server customer, the failure may be a physical component that requires inventory and hands-on replacement. For a colocation customer, the failure may be customer-owned hardware that Cloud9 can help access but does not own. For a domain customer, the failure may be loss of control over the name rather than the server.

For an email customer, the failure may be mailbox access, DNS routing, mail queueing or spam reputation.

The route view suggests Cloud9 has more network diversity than a tiny single-homed provider, but that does not eliminate service concentration. If many customer services are inside one facility, a facility-level event can still matter even with multiple carriers. If backups are stored in the same site, recovery can be delayed by the same incident that takes production offline. If support tickets and billing access depend on the portal, an account or portal issue can complicate technical repair. If a customer owns colocated gear but has no local spare parts, the facility can be operating normally while the customer's workload remains down.

This is why Cloud9's public evidence should be read as a starting point for due diligence, not a substitute for it. Customers should ask what fails together. Do hosted servers, DNS, portal and backup targets share the same building? Does the service have a second site? Are snapshots stored outside the primary storage system? Are route changes tested? Can a customer move a domain, mailbox or server image during a dispute or emergency? Each answer reduces the gap between "hosted in a data center" and "recoverable when the data center, network or account path is under stress."

Migration is the hidden cost of cheap capacity

Cloud9's colocation page says the company has performed large-scale migrations and will help customers plan and execute a move into its data center. That is a positive sign because migration skill matters in regional hosting. But every migration has two sides: entering the provider and leaving the provider. Customers often negotiate the first side carefully and ignore the second until an outage, price change, compliance demand or business sale forces the question.

The exit problem is different for each Cloud9 service. Shared-hosting customers need website files, databases, DNS zones, email accounts and logs. VPS customers need VM images, snapshots or reproducible server builds. VDS and dedicated server customers need operating-system access, data copy paths, firewall rules, images, licences and IP renumbering plans. Colocation customers need physical access, shipping windows, remote-hands coordination, cabling maps and equipment lists. Domain customers need transfer codes and unlocked registrant records. Email customers need mailbox exports, DNS changes and user reconfiguration.

A customer that uses several services at once needs the whole map.

Bandwidth can become the limiting factor. Cloud9's colocation page says standard customer connectivity includes unmetered 1 Gb/s to Georgian ISPs and 30 Mb/s global connectivity per customer. That may be perfectly adequate for normal local workloads, but a bulk export to another country can behave very differently. If a customer needs to move terabytes of virtual machines, backups or mailboxes, the customer should know whether temporary bandwidth upgrades are available, how much they cost and whether migration traffic competes with production traffic.

IP addressing is another hidden cost. If a customer's services are built around Cloud9-provided IP addresses, migration requires DNS changes, certificate reissues, firewall allowlist updates, mail reputation rebuilding and customer communication. If the customer has provider-independent addresses or keeps DNS short-lived and independent, migration can be easier. Cloud9's network presence is useful, but a customer should not assume that the address space used today can travel with the service tomorrow.

The safest buyer posture is to treat the first migration plan and the exit plan as one document. If Cloud9 is the right provider, it should still be possible to define how the customer gets data, domains, mailboxes, server images and equipment back under its own control.

What customers should verify before placing critical workloads

The public evidence supports Cloud9 as a real Georgian infrastructure provider. The customer questions are therefore more advanced than "does it exist?" The first set is about facility and capacity. Which exact facility hosts the service? Is it Cloud9 Dinamo Arena, another Cloud9 room or a third-party platform? How many racks, power feeds, cooling paths and network paths are involved for the specific customer service? What is the customer's power density, bandwidth allocation and failover capacity? Is there a second site, and is it active, warm or backup-only?

The second set is about network operation. Which prefixes will the customer's service use? Are they covered by valid RPKI ROAs and current route objects? Which upstreams and peers carry the customer's traffic? Does the customer get any route diversity guarantee? What happens if IXP.ge, one upstream, one fibre route or one building handoff fails? How are route leaks, DDoS events and international reachability problems handled? What visibility can the customer see during an incident?

The third set is about data recovery. How often are backups taken? Where are they stored? Are they immutable or isolated from production credentials? How often are restores tested? How quickly can a full virtual server, mailbox or database be restored? Can a customer restore without Cloud9's primary portal being available? Are backup exports included in the price, and are emergency exports rate-limited by bandwidth?

The fourth set is about support and control. Who answers outside business hours? Which issues are covered by remote hands, and which are billable? What is the support escalation path for colocation, dedicated server replacement, route changes, domain transfers and mail outages? How many authorised contacts can the customer maintain? What happens if the billing contact leaves? Can the customer designate emergency contacts separate from billing contacts?

The fifth set is about exit. Can the customer receive a current asset list, DNS zone file, mailbox export, VM image, backup copy, domain transfer code and access record on request? How much notice is required? What happens during a dispute? How long are deleted or cancelled services recoverable? Which data is destroyed and when? These questions are not hostile. They are the minimum terms that turn a hosted service into a responsible dependency.

Bottom line

Cloud9 Cloud 9 Ltd. should be read as an operating Georgian hosting and data-center provider with credible public infrastructure evidence. Its own pages sell the relevant services. RIPE records tie Cloud 9 Ltd. to AS57814 and AS49297, and RIPEstat shows AS57814 as announced while AS49297 is not visible in BGP. AS57814 has a meaningful route surface across IPv4 and IPv6, with originating and transiting visibility. PeeringDB places Cloud9 at Cloud9 Dinamo Arena in Tbilisi and shows an IXP.ge presence. Cloud9's data-center page gives concrete facility claims around power, cooling, fire suppression, monitoring and carrier interconnection.

That is enough to move beyond the weakest interpretation. Cloud9 is not merely a name in a directory. It is a local infrastructure provider with a facility-centered offer, public routing presence and retail products that can matter for Georgian businesses, developers, public bodies and regional service providers. The value proposition is clear: buy hosted or colocated capacity close to Georgian networks, with local support and a data-center operator that presents itself as carrier-neutral.

The remaining risk is the same risk that follows every regional cloud and hosting provider. The cloud label does not erase racks, transit, power, hardware, DNS, billing, account access or migration. Public pages do not prove spare capacity during a component failure, restore speed after a backup incident, customer export rights, after-hours escalation or clean failover from one facility to another. Customers can use Cloud9 well if they document those terms. They should not use it as a black box.

For critical workloads, Cloud9's capacity should be treated as real but contract-dependent. The company has enough public infrastructure evidence to be taken seriously. The customer's safety depends on turning that evidence into specific answers: where the workload runs, what fails with it, how routes survive, how backups restore, who repairs hardware, who answers after hours, what happens when a bill or account contact goes wrong, and how the customer exits without losing data or control.