Gemini Software Solutions P Ltd. Hosting Services, India sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Gemini Software Solutions P Ltd. Hosting Services, India is visible in APNIC and route-collector records as AS18120, with the APNIC RDAP autonomous-system record naming GEMINI-AS-IN and describing the holder as Gemini Software Solutions (P) Ltd. Hosting Services, India.
• The strongest infrastructure evidence is current routing, not marketing language. RIPEstat shows AS18120 as announced, reports four current IPv4 prefix announcements, and counts 2,048 IPv4 addresses in announced space, but those four announcements include overlapping /22 and /23 views rather than four separate address pools.
• The two public APNIC IP records are 202.72.248.0/22 and 110.232.180.0/22. Both point back to Gemini Software Solutions in India. They help anchor the network identity, but they do not prove rack count, owned data-centre space, hardware stock, multi-site failover or the ability to restore a customer's service during a facility or upstream incident.
• Transit evidence is useful but incomplete. The APNIC-derived whois record lists import and export policy with AS9498 and AS45820, while RIPEstat neighbour observation also sees AS17762. That is an operating edge, not a complete physical diversity map.
• The evidence grade is Medium. Gemini has a real company footprint, a Technopark/Nila address, a public cloud-services offer, active APNIC resources and current BGP visibility. The downgrade is for missing public proof of facility ownership, PeeringDB interconnection detail, route-origin validation coverage, support escalation depth and tested customer migration paths.

A hosted service starts with a route edge, then runs into physics

The useful question for Gemini Software Solutions P Ltd. Hosting Services, India is not whether the company exists. It does. The useful question is what kind of customer dependency sits behind the words "hosting services" when the public network edge is AS18120 and the company also presents itself as a software, cloud and support provider.

The APNIC RDAP autonomous-system record gives the strongest public identity anchor. It lists AS18120, name GEMINI-AS-IN, country IN and active status, with remarks describing Gemini Software Solutions (P) Ltd. Hosting Services, India. The same record points to Gemini Software Solutions (P) Limited as the registrant organisation, and the address label in the registrant entry is 414-415 Nila, Technopark Campus. That matches the corporate and campus story found elsewhere, but it still needs careful interpretation. A number-resource record is an identity and control signal. It is not a service-level agreement and not a proof of a particular rack or data hall.

The route edge is visible enough to treat Gemini as an infrastructure subject. RIPEstat's AS overview for AS18120 identifies the holder as GEMINI-AS-IN - Gemini Software Solutions (P) Ltd. Hosting Services, India and marks the ASN as announced. RIPEstat routing status shows IPv4 visibility across the RIS peer set at the query time and shows no IPv6 announced space in that snapshot. RIPEstat announced prefixes lists four current IPv4 announcements: 202.72.248.0/22, 202.72.248.0/23, 110.232.180.0/23 and 110.232.180.0/22. Because two of those are covering /22 announcements and two are more-specific /23 announcements inside the same blocks, the clean way to read the data is not "four independent blocks." It is "two APNIC blocks currently represented by four visible route announcements."

That distinction matters for customers. A hosting buyer is not buying a BGP table. The buyer is buying reachability to applications, support during failures, control of stored data and enough spare capacity to survive a bad day. Public routing records can tell the buyer where to begin the test. They cannot tell the buyer whether Gemini's edge has two routers, two power feeds, two cross-connect routes, enough spare servers or an emergency team that can act when a provider, facility or billing system becomes the pacing item.

Gemini's own language makes cloud part of the operating surface

Gemini's public site gives a second layer of evidence. The Gemini cloud-services page presents "End-to-End Cloud Solutions: Consulting, Migration & Support" and describes strategy, design, secure hosting, migration, cybersecurity, compliance, monitoring, disaster recovery and business continuity. It also says the team works across major providers. That language matters because it is broader than a simple software-development profile. Gemini is positioning itself somewhere in the path between customer applications and hosted infrastructure.

The Gemini about page describes Gemini Software Solutions as a technology partner with roots going back to 1998, a relationship with the YBA Kanoo Group, and services across sectors that include cloud services and software development. The Gemini technology-services page adds that the company designs, builds, deploys and maintains applications that integrate with databases, networks and hardware devices. Those statements do not prove that Gemini owns a data centre. They do show that a customer might reasonably encounter Gemini as an operator of application, hosting, integration, support and cloud-administration dependencies.

The Gemini contact page lists a Trivandrum location at 414-415, Nila, Technopark Campus, Kerala, India, plus other offices. That office footprint is relevant because APNIC records point to the same Nila/Technopark address. It is not, by itself, a rack map. A corporate office, a development centre and a hosting edge may overlap operationally without occupying the same physical space. The service could be delivered through leased cabinets, provider cloud regions, customer premises, third-party managed hosting, or a mix of those options.

The Technopark company detail page reinforces the campus identity. It describes Gemini Software Solutions (P) Ltd, says the company was established at Technopark in 1998, lists a Nila building presence in Technopark Phase I, and includes domains such as IT infrastructure consulting and support services. It also lists a primary building record for Nila. For an infrastructure reader, this is a strong location anchor and a weak facility-control proof. It tells us where a company presence is. It does not say where customer workloads are hosted, how many cabinets Gemini controls, which suppliers carry its routes, or how recovery is rehearsed.

That is the frame for the rest of the article. Gemini's public material makes cloud and support central enough to deserve scrutiny. The public network record makes the ASN and prefixes visible enough to test. The missing part is the expensive operating detail that turns a visible route edge into recoverable hosted capacity.

The address blocks are real, but they are not the same thing as usable capacity

The two APNIC IP records give the clearest number-resource picture. The APNIC RDAP record for 202.72.248.0/22 covers 202.72.248.0 through 202.72.251.255, names the network GEMINI, marks it active, gives the country as IN and describes it as Gemini Software Solutions, Hosting Services, Trivandrum, India. The APNIC RDAP record for 110.232.180.0/22 covers 110.232.180.0 through 110.232.183.255, names the network GEMINI-IN, marks it active, and carries a Gemini Software Solutions (P) Limited description with the Nila Technopark Campus address.

Those two /22s are meaningful assets. Each /22 contains 1,024 IPv4 addresses before network-use constraints. RIPEstat's routing-status view reports 2,048 IPv4 addresses in announced space, which lines up with the two covering /22 blocks. In a cloud or hosting context, that pool can support public server addresses, management endpoints, customer assignments, NAT infrastructure, monitoring systems or legacy application exposure. IPv4 is scarce enough that a visible allocation is not trivial.

But installed address space is not usable service capacity. A provider can have routable IPv4 and still lack enough physical compute, storage, power, transit or staff to carry a customer's failure scenario. A /22 does not say how many hypervisors are live. It does not say whether disks are mirrored, whether backups are restorable, whether management access survives a public-edge problem, or whether spare switches and optics are already on site. It also does not say how much of the address space is used for Gemini's own applications, historical customers, management networks, shared hosting, cloud integration or parked infrastructure.

The overlapping route announcements sharpen that point. Announcing both a /22 and a more-specific /23 can be perfectly normal. It can support traffic engineering, upstream policy or migration. It can also make a public prefix count sound larger than the unique address estate. A buyer should ask Gemini which prefixes are used for customer-facing hosting, which are used internally, which are carried through each upstream, and whether any prefixes are portable for customer exit or only provider-assigned for the duration of service.

The route table is a live clue. It is not a stock list. It does not tell the customer how many cabinets, servers, storage arrays, backup repositories, load balancers or firewall clusters sit behind the addresses. The public record supports the conclusion that Gemini has active, visible IPv4 routing. It does not support the conclusion that every visible address maps to available customer capacity.

Transit evidence shows a network edge, not physical diversity

AS18120 has enough transit evidence to show that it is not merely a dormant registry entry. RIPEstat ASN neighbours observed AS17762, AS45820 and AS9498 on the left side of AS18120 in the query snapshot. The RIPEstat whois data also includes import statements from AS9498 and AS45820 accepting ANY and export statements announcing AS18120 to AS9498 and AS45820. That is useful. It suggests Gemini has at least documented upstream policy in the registry-derived record and observed BGP adjacency in public collectors.

The limitation is equally important. A BGP neighbour is not automatically a physically diverse carrier path. Two upstream ASNs can enter the same building through the same duct, depend on the same metro fibre, use the same exchange fabric, share a last-mile provider, terminate in the same router, or rely on the same power domain. Even where the suppliers are commercially separate, the outage risk can still be common at the facility, cross-connect, router, route policy or support-approval layer.

Transit diversity has to be proven in four different ways. First, route diversity: if one upstream disappears, does the route remain visible from enough parts of the internet? Second, commercial diversity: are the upstreams actually separate contracts with independent escalation paths and enough committed capacity? Third, physical diversity: do fibres, entrances, racks and power feeds fail independently? Fourth, operational diversity: can Gemini change routing, contact suppliers and communicate with customers while the incident is active?

The public data can help design that test, but it cannot complete it. Customers should ask for a diagram that separates AS9498, AS45820 and any currently used additional neighbour by role. Are they paid transit, settlement-free peers, backups, historical sessions, or exchange-learned paths? Which one carries default? Which one is sized for full load? Which one has a different physical entrance? Which one has been used in a real failover?

Without those answers, the safe reading is that Gemini has a visible edge and observed neighbours, while the actual resilience of the edge remains contractual and operational rather than publicly demonstrated.

Route-origin validation is an assurance gap, not a verdict

Routing security is one area where the public record gives a specific downgrade. The RIPEstat route-origin validation checks for both current covering /22s return unknown: one for 202.72.248.0/22 with origin AS18120, and one for 110.232.180.0/22 with origin AS18120. In those snapshots, there are no validating ROAs returned.

An unknown RPKI state is not the same as an invalid origin. It does not say Gemini is hijacking its own routes or that the routes are broken. It says the public validation service did not see route-origin authorization that would make the origin positively valid in the RPKI view. That matters because more networks now use route-origin validation in routing decisions. Where a route is valid, operators have a clearer signal that the originating AS is authorized for the prefix. Where a route is unknown, the route may still be accepted, but it lacks that particular cryptographic authorization signal.

The difference is well explained by RFC 6811, which defines BGP prefix origin validation, and by APNIC's resource-certification material at the APNIC RPKI page. Those sources are not Gemini-specific, but they describe the control being tested. For a hosting customer, the practical consequence is simple: ask whether Gemini has published ROAs for the production prefixes, whether any upstreams enforce route-origin validation, whether there are route filters aligned with registry data, and how changes are reviewed before prefixes are more specifically announced or withdrawn.

RPKI also has a boundary. A valid origin would not prove that Gemini has redundant power, enough hardware, clean backups or good customer support. An unknown origin does not prove the service is unreliable. It is one signal in a larger resilience review. In AS18120's case, it is a signal that the public routing-security posture is not as strong as the active route visibility.

The absence of a PeeringDB profile keeps the interconnection picture thin

The PeeringDB API query for AS18120 returned no network entity. That is not a failure by itself. Many smaller networks, enterprise networks and provider-connected hosting operators do not maintain a PeeringDB page. PeeringDB is a voluntary directory, and its data is operator-maintained. Absence is not proof of no peering, no facilities or no customers.

Still, the absence removes a common way to cross-check interconnection claims. A PeeringDB profile can list exchanges, facilities, policy, prefix counts, traffic estimates and contact roles. Those fields are never a full audit, but they often reveal whether a network is exchange-facing, facility-diverse or mostly transit-only. For Gemini, the public PeeringDB query does not provide that second layer. The buyer is left with APNIC, RIPEstat, public aggregators and Gemini's own web material.

This makes direct due diligence more important. If Gemini claims multi-site hosting, the customer should ask for the actual site model. Which sites carry production traffic? Are they both in India? Are any in hyperscale cloud regions? Are customer backups in a different administrative domain? Are there separate maintenance windows? Are the management consoles and support portals hosted on the same infrastructure they manage?

The absence of PeeringDB also means facility claims should be treated as claims until supported. A public campus address at Nila, Technopark does not automatically map to a data hall. A cloud-services page that mentions major providers does not say which provider carries which customer. A route edge in AS18120 does not reveal whether the service sits in Gemini-controlled cabinets, a third-party colocation room, a public cloud account or a hybrid stack.

This is the right place for disciplined uncertainty. Public evidence shows an active AS and public cloud-services positioning. It does not show exchange memberships, facility diversity, peering policy or the commercial chain behind each path.

Gemini's campus footprint matters because support and access are physical

The Technopark and Nila address evidence should not be dismissed as mere office trivia. Hosting and cloud support depend on people, site access and escalation relationships. If a customer relies on Gemini for cloud migration, hosted application support, network exposure or managed operations, the physical location of the team and its access model shape the repair clock.

The Technopark listing describes Gemini as within Technopark and ties the company to the Nila building in Technopark Phase I. The Gemini contact page lists the same Trivandrum campus address and also lists Mumbai, Dubai, Bahrain and Saudi locations. That wider office footprint may be positive for customer support, but it also raises a placement question. Which office handles network incidents? Which office handles cloud operations? Which team can act on AS18120 routing? Which team can access physical equipment if equipment is not in a public cloud?

This matters most during the first hour of an incident. A customer outage can spend its early life as a ticket that has not yet reached the person with authority. The correct person may be a network engineer, a cloud administrator, a facility contact, an application owner, a billing administrator or a supplier escalation manager. If those responsibilities are split across offices or suppliers, the customer needs to know the path before failure.

Facility access is another boundary. If Gemini owns and operates racks, a Gemini engineer or authorized remote-hands provider may be able to replace equipment quickly. If the service depends on leased data-centre space, repair may wait for building access, remote-hands queues or parts availability. If the service is actually built on public cloud accounts, the physical repair path is abstracted, but support entitlements, quotas, region capacity and account controls become the equivalent constraints.

The public record does not say which model applies. The safe conclusion is that Gemini has an identifiable Indian campus footprint and a global office story, while the hosting recovery model remains undisclosed.

Cloud hosting hides supplier boundaries until something breaks

Gemini's cloud-services page says the company offers cloud consulting, cloud hosting and support, cybersecurity, data and application migration, post-migration monitoring, disaster recovery and business continuity. That language can describe several operating models. Gemini could resell or manage major public clouds. It could host some workloads on its own network. It could combine customer infrastructure, public cloud and its own routed resources. It could use AS18120 mainly for Gemini-controlled systems while customer workloads sit elsewhere.

Each model has a different failure path. If Gemini is the infrastructure operator, then racks, power, switching, storage, transit and spare parts are central. If Gemini is the managed-service layer over a hyperscale cloud, then identity access, cloud quotas, region selection, support entitlement, backup policy and customer-account ownership become central. If Gemini is an application operator, then code deployment, database replication, queue depth, logging and application support may be the bottlenecks.

If Gemini is a migration and support partner, then the customer's ability to leave or restore elsewhere depends on documentation, handover and operational ownership.

The buyer should not treat these as semantic differences. They determine who can fix a failure. A rack failure is not handled like a public-cloud account lock. An upstream route leak is not handled like a database restore. A failed payment or expired support contract can stop service just as effectively as a broken router if it blocks access to the control plane.

Public evidence does not allow a precise allocation of responsibility. That is why procurement should ask for a responsibility map. The map should name who controls public IP space, DNS, cloud accounts, hypervisors, storage, backups, monitoring, incident communication, customer data export, billing locks and supplier escalation. It should state which parts are Gemini-owned, which are customer-owned and which are third-party-operated.

Without that map, a customer may think it has bought a cloud service when it has actually bought a chain of dependencies that only becomes visible during an outage.

Installed capacity can be much larger than recoverable capacity

The headline route numbers around AS18120 are useful, but they say little about recoverable capacity. Installed capacity is what appears to exist in normal operation: IP address space, routers, cloud accounts, servers, storage, contracts and staff. Usable capacity is what remains when one part is down. Recoverable capacity is what can be restored inside the customer's time limit.

Gemini's public record supports installed-capacity questions. The AS is active. The two APNIC /22s are active. RIPEstat sees the route surface. Gemini markets cloud support. Technopark confirms a company presence. None of that says how many customer workloads can survive a failed router, storage array, supplier circuit, building incident, cloud-region impairment or support backlog.

This is where buyers should press for measured headroom. A provider might have two upstreams but only enough paid capacity on one of them to carry normal traffic, not failover traffic. It might have backups but no recent full restore. It might have a secondary site, but only for selected applications. It might have cloud migration skills but no contractual right to move a customer's data if the customer's account ownership is ambiguous. It might have a support team that is excellent during business hours but thin during weekends or holidays.

The route edge also has to be compared with the service edge. If a customer application uses AS18120 addresses, monitoring AS18120 route state is directly useful. If the application uses a public cloud provider's addresses and Gemini only manages it, then AS18120 may be less important than Gemini's account access, automation and support process. The customer should ask which edge carries its service and monitor that edge independently.

Capacity is not a claim; it is an exercise. A provider that can show recent failover tests, restore reports, route-withdrawal drills, customer notification samples and measured recovery times is in a different assurance category from a provider that can only show a cloud-services page.

Power, spares and remote hands set the repair clock

Every hosted service eventually has a physical clock. If a switch fails, someone needs the spare and the authority to replace it. If a storage node is sick, someone must decide whether to rebuild, fail over or isolate it. If a circuit is cut, someone must know the carrier, the path and the escalation. If a cloud account is locked, someone must clear identity, payment or compliance checks before technical work can continue.

For Gemini, public records do not show power design, rack location, spare inventory or remote-hands terms. That is normal for a privately operated service, but it is not a reason to ignore the issue. The customer should ask whether customer-facing services run in Gemini-controlled racks, in a third-party facility, in public cloud regions, at customer sites, or across multiple locations. Each answer changes the repair plan.

If the answer is Gemini-controlled racks, the next questions are concrete. Which facility houses production? Is there more than one power path? Are routers and storage spread across power domains? Are spares stocked on site or ordered when needed? Who is authorized for emergency access? How are changes approved outside office hours? Are maintenance windows announced with enough detail for customers to plan?

If the answer is public cloud management, the questions shift. Who owns the cloud account? Which region and availability-zone pattern is used? What service quotas could block recovery? What support plan is attached? Can Gemini act without waiting for a customer administrator? Are backups under a separate account or the same compromised or locked domain?

If the answer is hybrid, the customer needs both sets of answers. Hybrid service can be resilient, but it can also hide the exact place where responsibility shifts. The route table will not reveal that boundary. The contract and the recovery exercise have to reveal it.

Support is infrastructure when the provider controls the path to repair

Gemini's public pages repeatedly use support language. The cloud-services page mentions support, monitoring and disaster recovery. The about page presents Gemini as a technology partner. The Technopark listing includes support services as part of the company's expertise. In infrastructure terms, support is not decorative. It is the control system that turns a failure into a repair.

A hosted service can be technically redundant and still fail badly if support is unclear. The customer needs to know what qualifies as a major incident, who can escalate to network or cloud engineers, whether phone escalation exists, whether the status channel is independent of the affected service, and whether support can act on account, billing or access problems as well as packet loss.

Billing and account state deserve special attention. In managed hosting and cloud support, an unpaid invoice, expired card, customer-account lock, suspended resource, domain-control issue or disputed support entitlement can cause an outage that looks technical to users. The repair may depend on finance and administration rather than engineering. That is still infrastructure because it governs whether the customer can keep the service reachable.

Customers should ask Gemini to separate incident classes. What happens if AS18120 withdraws a customer prefix? What happens if an upstream degrades? What happens if the customer cannot log into a console? What happens if a backup restore is required? What happens if customer data must be exported urgently? What happens if the support portal is affected by the same outage?

Good support evidence is specific. It includes escalation contacts, response commitments, after-hours coverage, sample incident notices, root-cause formats, restoration responsibility and post-incident improvement tracking. Public pages can introduce the promise. Only operating evidence can show whether the promise survives pressure.

Data locality is not solved by an Indian ASN

The assigned region for this company is India, and the public network records support an Indian number-resource identity. APNIC lists country IN for AS18120 and for the two IP blocks. Gemini's own contact page lists Trivandrum and Mumbai offices, and Technopark places the company in Nila, Technopark Phase I. For Indian customers, that is relevant. It is not the same as data-locality assurance.

Data locality has to be broken down by data class. Where is the primary database? Where are backups? Where are logs? Where is object storage? Where are support tickets and attachments? Where is monitoring data? Where are customer credentials and secrets? Which staff can access each system, and from which jurisdictions? If Gemini uses major cloud providers, which regions are selected and who controls region changes?

Indian legal and security context raises the stakes. The Digital Personal Data Protection Act, 2023 makes personal-data processing a board-level and operational concern for many Indian businesses. The official CERT-In Directions under Section 70B are especially relevant to hosting and cloud-adjacent services because they address incident reporting, logs and obligations that include data centres, VPS providers and cloud service providers. Those legal sources do not prove anything specific about Gemini's implementation. They explain why a customer should not accept vague placement language.

The practical buyer question is placement evidence. Can Gemini state where each class of data is stored and processed? Can it produce a record of subcontractors and cloud regions? Can it keep logs within the required jurisdiction when applicable? Can it respond to security events without losing the ability to preserve evidence? Can it delete or export data on schedule when the customer leaves?

An Indian ASN is helpful for network identity. It does not, by itself, prove Indian storage, Indian backup, Indian support access or compliance with customer obligations.

Migration is the final test of hosted capacity

The most honest resilience test is whether a customer can leave. A provider can be competent and still fail a customer if the customer has no usable export, no route to rebuild elsewhere, no documentation and no tested handover. Gemini's cloud-services page mentions migration and knowledge transfer style work in the cloud lifecycle. That makes exit evidence a fair part of the infrastructure review.

Migration has several layers. Application data must export in a complete, documented format. Configuration must be reproducible. DNS and public endpoints must be movable. Logs and audit records must be preserved. Backups must be restorable outside the original account or facility. Identity and access must be separable from Gemini-controlled tools. If customer IP addresses are provider-assigned from AS18120 space, the customer needs a plan for address change, DNS cutover, certificate renewal and firewall updates.

Public routing records cannot show any of that. They can only identify one possible dependency: if a customer has built allowlists, VPNs, DNS records or monitoring around Gemini-addressed endpoints, moving away from those endpoints may take more than a data export. The IP dependency becomes part of the exit cost.

Customers should ask for a small, real migration rehearsal. Export one representative workload. Restore it under a different administrative boundary. Recreate network policy. Confirm that logs, attachments, metadata and user permissions survive. Measure downtime and customer actions. If the exercise requires manual Gemini intervention, document who can do it and under what entitlement.

Migration is not hostile to Gemini. It is an assurance of professionalism. A service that can help a customer leave cleanly is usually a service that understands the customer's dependency while the customer stays.

Public aggregators are signals, not settlement

Public routing aggregators are useful cross-checks for AS18120. Cloudflare Radar's routing view, BGP.tools, Hurricane Electric's BGP Toolkit, IPinfo's AS18120 page and BGPView each offer a different public lens on the ASN and its routes. The point of using several is not to inflate the evidence. It is to detect whether the basic route story is consistent.

These aggregators are not contracts. They can lag, disagree, simplify names, miss paths or show historical state differently from another collector. They are best read as monitoring instruments. If AS18120 disappears from one view, that may be a collector issue. If it disappears from many views while customers see reachability failures, the evidence becomes operationally useful. If one prefix becomes invalid or a new more-specific announcement appears, the customer has a concrete question to ask.

The same caution applies to non-company directories, cached search results and commercial intelligence pages. They may suggest that Gemini is connected to hosting, cloud or network services, but they cannot prove current service quality, facility ownership or customer dependency. For this article, the company-specific hard evidence comes from APNIC, RIPEstat, Gemini's own site and Technopark. The aggregators help watch the edge. They do not settle the underlying capacity question.

A sensible customer monitoring plan would track the announced prefix set, route-origin validation state, public reachability from multiple regions, DNS dependencies, certificate validity, application health and support responsiveness. The monitoring should be owned by the customer as well as by Gemini. During an incident, independent observations reduce argument and accelerate escalation.

Who is affected when this kind of service fails

The first affected party in a Gemini-hosted or Gemini-managed failure may be an application owner, a support desk, a logistics operator, a warehouse team, a finance team, a travel back-office process, a software user or a customer administrator. Gemini's own public materials emphasize business applications across domains, not only raw infrastructure. That means infrastructure failure can surface as business-process failure.

If AS18120 is directly involved in a customer service, a routing or upstream problem can make web applications, APIs, management endpoints, email gateways, monitoring probes or VPNs unreachable. If Gemini provides cloud management rather than direct hosting, the failure may be access to the cloud account, a bad migration, a backup restore problem, a support escalation delay or a security incident. If Gemini operates a product platform for customers, the failure can combine application, database and network symptoms.

The downstream effect can spread quickly. A warehouse system outage may delay dispatch and inventory visibility. A maritime or travel back-office system may interrupt operations. A BFSI-adjacent application may raise audit, availability and personal-data concerns. A support portal outage may prevent customers from reporting the very incident they need repaired.

This is why a company with a modest public route footprint can still matter. The size of an ASN does not measure the importance of the workloads behind it. A two-/22 network can carry critical endpoints. A managed cloud account can hold essential data. A small support team can be the only bridge between the customer and a third-party provider. The customer should size the risk by service dependency, not by how large the public routing footprint looks.

What a buyer should ask Gemini before treating the service as resilient

The first request should be a service-to-infrastructure map. Which Gemini services use AS18120? Which use the two APNIC /22s? Which use public cloud provider addresses? Which are hosted in India, and which are supported from India but hosted elsewhere? Which are multi-site, and which are single-site with backups?

The second request should be a route and transit explanation. Ask how 202.72.248.0/22, 202.72.248.0/23, 110.232.180.0/23 and 110.232.180.0/22 are used. Ask what AS9498, AS45820 and AS17762 represent today. Ask whether route-origin authorizations are published or planned. Ask how route filters are maintained and who approves BGP changes.

The third request should be a facility and supplier boundary map. If Gemini owns equipment, identify the facility, power model, spares, remote hands and replacement process. If Gemini uses third-party cloud or hosting providers, identify account ownership, region placement, support tier, backup account separation and quota risks. If the service is hybrid, name the boundary where responsibility changes.

The fourth request should be recovery evidence. Ask for dates and results of recent restore tests, failover exercises, backup verification, route failover, incident communications and customer export rehearsals. Ask what failed during those exercises and what changed afterward. A candid test report is more valuable than a generic uptime promise.

The fifth request should be data-portability evidence. Ask whether complete exports include files, databases, metadata, logs, user permissions, keys, configurations and documentation. Ask whether the export can happen during a degraded-service event. Ask how long the customer has after termination to retrieve data. Ask whether any provider-assigned IP dependency will make migration harder.

Those questions are not excessive. They are the normal minimum for a customer that depends on hosted capacity.

The evidence grade

Gemini Software Solutions P Ltd. Hosting Services, India earns a Medium public-network evidence grade. The positive side is clear. AS18120 is active in APNIC RDAP and public route views. The ASN holder text names Gemini Software Solutions (P) Ltd. Hosting Services, India. APNIC has two active IPv4 blocks tied to Gemini in India. RIPEstat sees current IPv4 announcements and observed neighbours. Gemini's own site advertises cloud services, hosting and support. Technopark independently anchors the company to Nila, Technopark Phase I, with IT infrastructure consulting and support services in the company listing.

The downgrade is also clear. The public record does not show owned racks, leased data-centre contracts, facility count, power design, spare inventory, customer placement, public PeeringDB interconnection detail, IPv6 service, positive RPKI validation, tested disaster-recovery results, support escalation depth or data-export evidence. The route edge is real, but the recovery story is not public.

That should not be read as an accusation. Many providers keep facility and customer details private for sensible security and commercial reasons. The point is narrower: a customer cannot infer resilience from an active ASN, a Technopark address and a cloud-services page. The customer has to ask for proof of the operating model.

The practical conclusion is that Gemini is a valid infrastructure dependency candidate for Indian cloud-service and hosting review. Its public record is stronger than a bare name and weaker than a fully disclosed network operator. Buyers should treat AS18120 and the two APNIC /22s as the opening map, then test racks or cloud-region placement, transit diversity, route-origin validation, support escalation, backup restoration and migration before relying on Gemini-hosted or Gemini-managed capacity for critical workloads.