Summary

  • Outofbox Cloud has a current public route: AS147192 originates 103.174.148.0/23, and that route was visible to 325 of 326 RIPE RIS IPv4 peers in the 15 July 2026 observation.
  • The physical evidence is concentrated in Sadashiv Nagar, Belagavi. A 2020 local report described more than 100 installed servers and room for nearly 300, while a September 2025 college visit described racks, cooling and backup power at the same locality. Neither source proves the site's current powered, usable or spare capacity.
  • The company's claim of eight data-centre regions is not accompanied on its public product pages by eight city names, facility operators, power designs, capacity figures or a region-by-region status history. Its own terms also disclaim uninterrupted or error-free operation despite a separate 99.99% SLA claim.
  • AS147192 has one observed neighbour, AS141815, registered to the legally distinct Outofbox Networks Private Limited. That network has broader upstream and exchange connectivity, but logical route diversity beyond the first hop does not establish diverse fibre entrances, conduits, buildings, utility feeds or failure domains for Outofbox Cloud.

Eight regions are advertised; one locality is evidenced

The most consequential sentence on Outofbox Cloud's product site is not the price of a small virtual machine. It is the claim, on the company's Boxes page, that customers can deploy across eight data-centre regions. That same page uses the marketing phrase "global availability" and advertises a 55-second launch time and a 99.99% uptime SLA. Those are measurable propositions, but they are not evidence of a global operating footprint. They imply more than a web storefront: enough installed compute, storage and address capacity to accept an order; a control plane capable of placing the workload; a powered facility; a routed path; support staff; and, if the word "regions" is used in its normal infrastructure sense, geographically distinguishable operating locations.

The public evidence does not let a reader enumerate eight such locations. No eight-city list appears alongside the claim. The page does not identify facility owners, colocation partners, utility feeds, rack counts, power envelopes, certifications, commissioning dates or regional status endpoints. A customer may encounter more detail after creating an account, and private contracts may contain it. The public claim nevertheless cannot be treated as proof that eight independently operable facilities exist, that all are accepting deployments, or that a workload can fail over between them.

What can be evidenced is a smaller footprint with real operational signals. The BTW directory entry identifies the company that is the subject of this profile. APNIC records associate that company with an autonomous system and a portable IPv4 assignment. The company's website and registry contacts point to Sadashiv Nagar in Belagavi, Karnataka. Independent local material describes servers, racks, cooling and backup power there. At the observation time, the company's web and customer-control domain names also resolved to addresses inside that assigned IPv4 block. The DNS observation establishes an address association only; the physical and routing evidence, considered separately, supports a real local operation. None of it supports an eight-site map.

That distinction is not pedantry. A customer choosing a regional provider may reasonably value local support, Indian data residency and lower-latency access from Karnataka. Those benefits can be substantial even if the platform is concentrated in one city. The risk appears when a compact local platform is sold using language that readers may interpret as hyperscale geography. The right assessment is neither "there is no infrastructure" nor "eight regions are proven." It is that the Belagavi footprint is supported, while the geography beyond it remains unknown in public evidence.

The company, the earlier brand and the network operator are not interchangeable

OUTOFBOX CLOUD PRIVATE LIMITED is an Indian private company. A current MCA-derived company record published by IndiaFilings gives the corporate identification number U72900KA2021PTC149665, an incorporation date of 19 July 2021, an active filing status as of its November 2025 update, and the registered office at Fourth Floor, Oneness, Sadashiv Nagar, Belagavi. It lists Ajit Kumar S Patil and Gowdesh Singangouda Patil as directors. Because that page republishes registry information rather than serving as the registry itself, the precise current filing state should be confirmed against Ministry of Corporate Affairs master data before a material contract.

The Outofbox Cloud brand predates that company. A preserved February 2020 local report described OutofBox.cloud as a service launched from Belagavi and called it a wholly owned subsidiary of FAAST Networks. It said the service ran on a customised OpenStack environment, had more than 100 servers at the time, and could accommodate close to 300 physical servers. The report also described the site as the brand's first data centre. Those statements concern a 2020 operation and a brand relationship before OUTOFBOX CLOUD PRIVATE LIMITED was incorporated in July 2021. They are useful history, not a current ownership certificate.

A second legal entity matters to the network story. APNIC registers AS141815 to Outofbox Networks Private Limited, while AS147192 belongs to Outofbox Cloud. The records use the same Sadashiv Nagar street address and the same telephone number, but different network-contact email domains. Corporate-data sources indicate overlapping directors, and the 2020 report describes a group relationship. Even so, two private limited companies are two legal persons. The network company's telecom authorisation, contracts, circuits and address space cannot automatically be booked as assets or obligations of the cloud company.

That boundary becomes especially important in a failure or an exit. If a customer buys compute from Outofbox Cloud but the first visible network path is supplied by Outofbox Networks, the customer needs to know which company signs the service agreement, which owns or leases the servers, which holds the facility lease, which invoices for bandwidth, which employs the network operations staff, and which entity is responsible for restoration. Shared directors, branding, address or telephone number may make coordination easier. They do not replace contractual rights.

The current public website sometimes blurs the product and infrastructure layers. It advertises public cloud, virtual private cloud, private cloud, load balancing, managed Kubernetes, platform services, SAP-oriented hosting, a banking community cloud, dedicated servers and colocation. Some may be delivered directly; some may rely on affiliated infrastructure or suppliers. The public pages do not publish a service-by-service ownership matrix. This profile therefore attributes the products to the company's marketing and the number resources to their registered holders, without assuming that every layer is owned by the same entity.

What is physically evidenced in Belagavi

The strongest recent physical evidence is not a marketing map. It is a September 2025 account from the Department of Artificial Intelligence and Data Science at Angadi Institute of Technology and Management. The department's activity record says students visited Outofbox Cloud Private Limited in Sadashiv Nagar, Belagavi, on 22 September. It describes virtual-machine management, virtual private clouds and firewalls, then identifies physical and virtual servers, server racks, cooling, backup power, routers, switches, firewalls and storage systems in the data-centre setup. The department also published the account in its 2025-26 newsletter.

This is meaningful corroboration. It indicates that equipment associated with the company was physically viewable in the named locality less than a year before this article. It is more useful for location than an IP geolocation database, because an institutional visit concerns an actual place rather than an inference from network latency or registration data. The Belagavi Technology Companies Association likewise describes Outofbox Cloud as locally hosted and India-based, though that association profile is promotional and does not disclose its verification method.

The evidence still has limits. The college account does not state the building's exact room, floor area, rack count, rack density, utility service, UPS topology, battery autonomy, generator rating, fuel endurance, cooling duty, fire suppression, occupancy approval or facility operator. It does not say whether the viewed systems carried production customer workloads, served as a training lab, or mixed both functions. It does not identify ownership labels on the equipment.

The shared street address appears in company and number-resource records as an administrative contact; an administrative address is not, by itself, a facility certificate.

The 2020 article supplies numbers but not current status. "More than 100 servers" is an installed-equipment claim at one moment. "Close to 300 physical servers" is a design or space-capacity claim. It does not state how many rack units, power sockets or kilowatts were then energised. It cannot show how many servers remain in service in 2026, how many are customer-ready, what proportion are reserved, or whether later growth moved workloads elsewhere.

The phrase "virtually unlimited" virtual machines in that report should be understood as promotional language: every virtual machine ultimately consumes finite CPU, memory, storage, network, power and cooling capacity.

No public record located for this profile identifies a second Outofbox Cloud facility with comparable physical evidence. No public power sanction, utility connection capacity, generator approval, fire no-objection certificate, building-level data-centre permit or environmental filing was found that could be safely tied to the cloud company's production floor. Absence from a public search is not proof that a document or approval does not exist. It means that a reader cannot use one to quantify the site or test the eight-region claim.

The map should therefore be drawn conservatively. Belagavi is a supported operating locality and registered contact location. Mumbai is a supported logical exchange location for AS141815 at NIXI, not proof that Outofbox Cloud owns servers in Mumbai. Bengaluru and Chennai labels returned by commercial IP-location tools are measurement estimates, not facility addresses. The remaining advertised regions are unknown until the company publishes city names and the legal or operational basis for each.

A product catalogue is not an inventory

Outofbox Cloud's current pricing page makes the service economically tangible. It lists configurations ranging from a small two-CPU, 2 GB memory, 100 GB NVMe plan at ₹630 per month to much larger compute and memory combinations. The Boxes page describes general-purpose, CPU-optimised, memory-optimised and storage-optimised instances and says some plans use dedicated hyper-threads. These details show what the company offers to sell. They do not reveal the number or generation of physical hosts, the oversubscription policy, storage replication, spare-parts inventory or placement rules behind the plans.

The distinction between a catalogue and capacity matters most during a surge or failure. A plan can remain visible when no suitable host has spare memory. A control panel can accept an order while hardware fulfilment is delayed. A nominally dedicated vCPU may be isolated at the scheduler while still sharing a socket, memory channels, storage controllers, top-of-rack switches and power feeds. NVMe capacity may be local to a host, replicated across hosts, backed by a storage cluster, or restored from a separate backup service. The public plan table does not resolve those possibilities.

The homepage says the platform has more than 40 clients and more than 500 cloud deployments. Those are first-party counters without a date, definition or audit. A "deployment" could be an active virtual machine, an application launch, a historical provisioning action, a test environment or a customer project. It cannot be converted into installed servers or sold capacity. Nor does 512 assigned IPv4 addresses impose a one-address-per-server rule: addresses may serve hypervisors, virtual machines, network address translation, load balancers, routers, reserves or customer assignments.

The website also advertises load balancing. A load balancer can distribute requests among multiple servers, but it does not prove geographic redundancy. Servers behind it may share a rack, top-of-rack switch, UPS, cooling loop, building entrance and upstream router. Likewise, a virtual private cloud provides logical isolation, not a physically separate cloud. A private-cloud offer can run on dedicated hardware within a shared facility. Each is useful, but each addresses a different failure layer.

For capacity to be decision-grade, the provider would need to connect the plans to an operating envelope: available host pools by region, CPU and memory allocation rules, storage durability, network-port commitments, provisioning lead times, maintenance reserve, and the point at which "available" capacity is actually powered and deployable. None of those values is public. The safe conclusion is that specific products are marketed and the service endpoints are live, while installed and available inventory remain unknown.

The public network is real, compact and visible

The clearest current operating evidence is AS147192. The APNIC autonomous-system record names OOBCLOUD-AS-IN and OUTOFBOX CLOUD PRIVATE LIMITED, marks the record active, and shows a registration date of 13 October 2021. The APNIC address record assigns 103.174.148.0 through 103.174.149.255 as portable IPv4 space to the company. That is a /23 containing 512 addresses. The resource record has no corresponding IPv6 block.

RIPE NCC's routing-status observation on 15 July 2026 found one originated IPv4 prefix, 512 addresses, no IPv6 prefix and one observed neighbour. The route was visible to 325 of 326 IPv4 peers in RIPE's Routing Information Service, which is strong evidence of wide public-route visibility at that moment. It is evidence of reachability, not a global operating footprint. The announced-prefixes result shows 103.174.148.0/23 continuously in the 1-15 July observation window.

Visibility has history rather than being a one-day artefact. RIPE's routing history shows AS147192 originating the /23 from November 2021 through the current query window, subject to the sampling and visibility thresholds of the collector system. The route-origin validation result was valid, with a route origin authorisation allowing AS147192 to originate the /23 and prefixes down to /24. RPKI validity reduces one class of origin error; it does not provide uptime, capacity, path diversity or protection against an authorised operator mistake.

At the observation time, A records for the company's public website and customer-control hostname pointed to addresses inside the /23 assigned to OUTOFBOX CLOUD PRIVATE LIMITED: the main site to 103.174.148.253 and mycloud.outofbox.cloud to 103.174.148.14. This establishes only a point-in-time association between those domain names and that assigned range.

It does not establish who owned or operated the responding servers or applications, where they were physically hosted, whether either address was anycast, whether either hostname formed part of a production control plane, or whether either service shared a failure domain with customer workloads.

PeeringDB's AS147192 profile is informative mainly for what it does not document. The self-reported entry describes an Asia-Pacific scope, a 100-1000 Mbps traffic band and 512 IPv4 addresses. It lists zero public exchange connections and zero facilities, and it has not been materially updated since October 2022. PeeringDB is voluntary; zero fields can mean undisclosed or stale information rather than physical absence. They nevertheless cannot be used to substantiate eight regions.

The network is therefore both genuine and compact. It has a stable route, valid origin authorisation and live service endpoints. Yet the entire public origin surface is one IPv4 block with no visible IPv6 announcement and one immediate observed neighbour. The route evidence supports operating status more strongly than the website alone. It also defines a narrow logical dependency that deserves examination.

One immediate neighbour, then a broader network

RIPE's AS147192 neighbour observation identifies only AS141815 on the left side of collected paths. A second collector-based report reaches the same basic topology. This does not prove that there is only one physical circuit. Private links, backup sessions, routes hidden by policy and connections with too little collector visibility may not appear. What it does prove is that the public route available to the examined collectors did not show independent first-hop diversity.

AS141815 is registered to Outofbox Networks Private Limited. The Indian Department of Telecommunications' 2026 list of ISP authorisations lists that company, not Outofbox Cloud Private Limited, with a Category B authorisation for Karnataka and the same Sadashiv Nagar address. This is a valuable legal distinction: the network company has the disclosed ISP authorisation, while the cloud company owns the visible cloud ASN and address block. The public record does not show the intercompany agreement under which transit or facilities are supplied.

Beyond that first neighbour, AS141815 has more route options. RIPE's current neighbour result shows four observed neighbours: AS45117, AS9730, AS137085 and the cloud company's AS147192. Its routing status shows four originated IPv4 /24s and no visible IPv6. PeeringDB lists an operational 1 Gbps connection at NIXI Mumbai for AS141815. The existence of multiple external AS adjacencies beyond AS141815 may improve route choice and recovery from an upstream routing failure.

It still does not prove physical redundancy for the cloud. Two upstream ASNs can arrive over fibres in one cable, one carrier handoff, one street trench, one building entrance or one router. An internet-exchange port in Mumbai may be reached through a single backhaul from Belagavi. The cloud ASN may connect to the network ASN through one cross-connect or one device. No public source identifies circuit providers, handoff locations, route reflectors, edge-router pairs, fibre entrances, conduit paths, protection switching, committed rates or failover-test results.

The distinction between logical and physical diversity also applies to geography. NIXI Mumbai is an exchange point where AS141815 has a port; it is not evidence that Outofbox Cloud operates compute or storage in Mumbai. A route can traverse Mumbai while the workload remains in Belagavi. Conversely, a provider could lease compute elsewhere without announcing it from AS147192. Network maps and AS paths show packet reachability, not server ownership.

For a customer, the useful question is not simply "How many upstreams?" It is: which failure removes access to this specific workload? Answering that requires a path from the virtual machine's host and top-of-rack switch through the facility edge, cloud-network handoff, long-haul circuits and upstream providers. Public routing reveals the AS-level middle of that chain. The rack-level and civil-engineering ends remain unknown.

Historical capacity cannot be promoted to current usable capacity

The 2020 figure of more than 100 servers is the only public installed-equipment count located for this profile. The same report's "close to 300" figure describes how many physical servers the first data centre could host. Even if both were precise when published, they represent different states. Installed equipment is not design space. Powered equipment is not necessarily operational. Operational equipment is not necessarily available to a new customer. Available equipment may already be reserved, or may not satisfy a workload's CPU, memory, storage and network combination.

No 2026 source states the current server count. No source gives megawatts, kilowatts, rack count, rack density or utility allocation. No source quantifies UPS modules, generator capacity, battery duration, diesel storage, cooling redundancy, power-usage effectiveness or fire suppression. No source identifies an N, N+1, 2N or distributed-redundant design. The 2025 student visit confirms that cooling and backup power solutions were present; it does not specify their capacity, maintenance condition or ability to carry a full production load through an extended utility failure.

The website's "eight data center regions" also lacks a capacity denominator. A region could mean a full company-operated facility, a leased rack, capacity rented from another cloud, an edge site, a planned location or a selectable label in a control panel. Those arrangements create different obligations and failure modes. Without region names and operator disclosures, installed capacity cannot be attributed to the company and customer data location cannot be established.

Address space is similarly easy to overread. A /23 gives the organisation 512 IPv4 addresses, not 512 servers. A single server can host many private-addressed virtual machines behind a few public addresses. A customer can receive several public addresses. Some addresses are consumed by network, broadcast, gateway, management, reserve or anti-abuse functions. IPv4 count is a useful upper-bound input for certain public-address products, but it is not a compute, storage, power or customer count.

The advertised configurations provide no stock signal either. A 32-core plan shown online is an offer, not proof that a matching host is free. The company may operate a pooled scheduler, provision manually, maintain spare hardware, or buy capacity from partners. The public pages do not say. The terms do not publish a fulfilment deadline. A prospective buyer should ask for a dated capacity confirmation for the selected region and configuration, including whether the resources are installed, powered, tested and immediately assignable.

The defensible capacity finding is therefore narrow. Historical installed capacity: more than 100 servers, reported in 2020 and not independently audited. Historical design capacity: close to 300 physical servers at the first Belagavi site, reported in 2020. Current physical presence: racks, servers, cooling and backup power observed in a 2025 educational visit. Current installed, powered, usable, sold, reserved and spare capacity: unknown.

A 99.99% badge needs a clock, scope and remedy

The Boxes page advertises a 99.99% uptime SLA. If measured over a 365-day year with no exclusions, 0.01% downtime equals about 52.6 minutes. If measured monthly, it is roughly 4.4 minutes in a 30-day month. Real service-level agreements define the measurement period, the component measured, what counts as unavailable, maintenance exclusions, customer responsibilities, claim windows and service credits. A percentage without those terms cannot tell a customer what remedy follows a host, storage, network or control-plane failure.

The company's public Terms and Conditions create additional uncertainty. They say the company strives for availability and security but does not guarantee uninterrupted or error-free operation, and they disclaim liability for inability to use the services. A separate signed service order may override or supplement those website terms. No public SLA schedule, credit table or status-history archive was located to reconcile the marketing percentage with the disclaimer.

Scope is crucial. Compute uptime can exclude a customer's operating system. Host uptime can coexist with an unreachable network. Network uptime can coexist with storage corruption. A regional SLA can exclude simultaneous multi-region failure, while a virtual machine deployed in only one region has no geographic recovery. Backup success is not restore success. Support availability does not guarantee a restoration time.

For Outofbox Cloud, the SLA question is tied directly to the network and facility evidence. Does the 99.99% apply to each individual Box, the hypervisor pool, the first network hop, the control panel, storage, or all of them? Is it measured from external probes? Are the eight regions separate SLA scopes? Does a failure of AS141815 count? Does planned maintenance at the Belagavi facility count? What credit is available, and is the customer's sole remedy a credit? Until a contract answers those questions, the badge is a marketing claim rather than a quantified recovery guarantee.

How the service can fail

The first failure path is facility power. A utility interruption should transfer the critical load to UPS and then to generation or another supply. The 2025 visit supports the presence of backup power, but no public source states autonomy or redundancy. A generator can fail to start, run out of fuel, overheat or support only part of the load. Batteries can be degraded. Switchgear can create a common point of failure. If the site has one utility feed or one distribution path, multiple devices may go dark together even when individual servers have dual power supplies.

The second path is cooling. Servers may keep electrical power while thermal limits force shutdowns or throttling. A compact facility needs enough cooling for the actual rack density, not merely the room's nominal area. Redundant air-conditioning units can still share controls, condensers, pumps or power. The educational visit confirms cooling equipment but not duty, redundancy or maintenance. A customer cannot infer thermal resilience from the presence of a cooling unit.

The third path is network access. AS147192's one publicly visible neighbour means the cloud's route reaches the observed internet through AS141815. A second upstream beyond AS141815 can help if one provider route fails, but not if the cloud-to-network handoff, shared edge router, Belagavi backhaul or building entrance fails. Route-origin authorisation protects the legitimacy of the origin, not availability. A valid route can still be withdrawn, filtered or unreachable.

The fourth path is management access, whose architecture is unknown. The website and customer-control domain names pointed into the company's assigned /23 during observation, but that fact does not identify server or application ownership, physical hosting, a production control-plane role, or co-failure with customer workloads. DNS, authentication, billing and support become availability dependencies only where the actual architecture makes them so. A customer would need an architecture description and tested out-of-band procedures; the public record does not supply either.

The fifth path is storage. The pricing pages advertise NVMe quantities and weekly backups on some web-hosting-style plans, but do not explain replication for Boxes. Local NVMe can deliver excellent performance while exposing a virtual machine to host-level failure unless data is replicated elsewhere. A replicated storage cluster can survive a drive or node failure but not necessarily a building outage or operator error. A weekly backup limits recovery-point exposure only if it is successful, isolated, retained and restorable. The site does not publish restore testing or backup-location details.

The sixth path is hardware stock. A small regional provider can offer close support and attractive pricing, but replacement time depends on spare drives, power supplies, memory, network cards, switches and complete hosts. The company does not publish parts inventory or vendor support. A failed component may be replaced in minutes if a spare is on site, or in days if it must be sourced. Capacity advertised in a plan table does not establish repair stock.

The seventh path is people and escalation. The site advertises 24/7 monitoring and support, but the public terms do not define response or restoration targets. A real escalation chain needs an acknowledged incident, technical owner, communications cadence and authority to move a workload or replace equipment. The size of the on-call team, network-operations separation, access-control model and after-hours facility access are unknown. Customer testimonials on the homepage are useful market signals, but they are selected by the company and do not substitute for incident statistics.

The eighth path is billing or contract failure. A technically healthy virtual machine can become unavailable if an account is suspended, a payment is disputed, an abuse complaint is mishandled or the supplying entity changes terms. The website terms reserve broad discretion and limit guarantees. Customers need notice periods, dispute escalation, data-export rights and a defined grace period. Regulated or critical customers also need clarity about subcontractors and which legal entity can access data.

The ninth path is migration. The ability to boot a virtual machine quickly is not the same as the ability to leave quickly. Images may depend on proprietary networking, managed databases, object storage, snapshots or identity services. Large data sets take time and bandwidth to export. Egress charging, image formats, API compatibility and deletion confirmation are not described publicly. Without a tested export, the customer remains dependent on both the platform and its support team during an incident.

The tenth path is correlated geography. If the evidenced servers, control plane, cloud-network handoff and staff are concentrated in Sadashiv Nagar, one building-scale event could affect them together. The site claims eight regions, but no public source permits a customer to select two named facilities and verify that they have separate operators, grids, flood zones, backhaul routes and control planes. Multi-server placement inside one room is useful availability engineering; it is not geographic disaster recovery.

These are scenarios, not claims that any of them has occurred. They show why a current route and a photographed rack are necessary but limited public evidence evidence for resilience. Reliability depends on how the layers are connected and on what the provider has tested under failure.

Banking language raises a higher diligence standard

Outofbox Cloud advertises a banking community cloud and says its platform is suitable for compliance-sensitive workloads. That language does not prove that a bank uses the service or that the platform has passed a particular audit. It does make the missing details more consequential. A regulated financial institution cannot outsource responsibility simply by buying a service marketed for banks.

The Reserve Bank of India's 2023 directions on outsourcing IT services explicitly include cloud computing and data-centre services. They require covered regulated entities to perform due diligence, map supply-chain dependencies, monitor service levels, maintain business-continuity and disaster-recovery arrangements, preserve audit and access rights, and plan an exit. The cloud appendix addresses the data lifecycle and movement of cloud-hosted services. Those duties sit primarily with the regulated customer, but a provider must be able to supply the evidence and contractual rights the customer needs.

CERT-In's 2022 cybersecurity directions apply operational obligations to service providers, data centres, VPS providers and cloud providers. They include time synchronisation, six-hour reporting for specified incidents, a rolling 180-day log requirement within India, and retention of specified customer-registration information for five years after cancellation or withdrawal. This profile did not locate public compliance attestations from Outofbox Cloud. That absence does not prove non-compliance; these controls may be internal. A customer should ask how the obligations are implemented and how they interact with privacy, access control and deletion commitments.

The company's privacy page does not answer those enterprise questions. It contains visibly generic WordPress "Suggested text" about comments, cookies, media and user profiles. It does not identify the corporate legal name, data-centre regions, subprocessors, cloud-service telemetry, retention schedule, security contact, customer-workload handling or cross-border transfers. A signed data-processing agreement may provide those details, but the public page should not be treated as a cloud-specific privacy statement.

For a bank or other critical customer, the practical request is an evidence pack: named sites and operators; subcontractors; data-location and movement rules; security certifications and scope; penetration-test and audit summaries; incident history; backup and restore tests; recovery time and recovery point commitments; power and network topology; staff access controls; key management; deletion evidence; and an exit runbook. The provider's compact local footprint could be an advantage for residency and support, but only if the customer can verify where data and copies actually reside.

Data locality is supported at country level, not at eight-region resolution

The evidence strongly associates Outofbox Cloud with India. The company is registered in Karnataka. APNIC marks its number resources in India. The physical reports point to Belagavi. The associated network company holds a Karnataka ISP authorisation. The public route and service endpoints are active. These facts support an India-centred operating identity.

They do not establish the location of every workload. An IP registration country is not a server coordinate. A customer may be placed on hardware owned by the provider, leased racks, partner capacity or another cloud. Backups may reside elsewhere. The eight advertised regions are unnamed. The word "global" on a product page can describe sales reach or internet reachability rather than data-centre geography.

This matters for data sovereignty and latency. A customer seeking Karnataka residency should obtain a contract naming the city and facility boundary, not rely on the company's address. A customer seeking Indian residency should identify primary data, replicas, snapshots, logs and support access. A customer seeking geographic recovery should identify a second site and test a restore there. The evidence that establishes one locality cannot be stretched into evidence for eight.

What would turn the claim into infrastructure evidence

Outofbox Cloud could materially improve the public assessment without disclosing sensitive engineering detail. First, it could publish an eight-region list with city, country, launch status, whether the capacity is company-operated or partner-operated, and which services are available in each. A region marked planned should be separated from one that is accepting production workloads.

Second, it could publish a service-level schedule. That document should define the measured component, observation method, maintenance exclusions, claim process and credits. A status page with historical incidents and region-level components would let customers compare the percentage with operating history. A statement that terms are superseded by a signed SLA would reconcile the current disclaimer.

Third, it could provide a high-level resilience design for the Belagavi site: number of utility feeds, UPS and generator redundancy class, minimum fuel autonomy, cooling redundancy, fire protection, rack and power envelope, network-edge design and the date of the last failover test. Exact circuit routes and security-sensitive details need not be public. Dated, independently assured summaries would be enough to distinguish installed, powered and usable capacity.

Fourth, it could clarify the boundary with Outofbox Networks Private Limited and FAAST Networks. Customers need to know who supplies transit, who holds the telecom authorisation, who operates edge equipment, whether the arrangement is an affiliate subcontract, and what happens if that supply relationship changes. The route data already makes the dependency visible; contractual disclosure would make it manageable.

Fifth, it could publish portability details: supported image exports, snapshot formats, API documentation, egress pricing, bandwidth limits, deletion procedures and tested restoration to another region or provider. Portability is not a secondary feature for a small cloud. It is part of resilience because it gives a customer a recovery path when the provider, facility or contract is the failure domain.

Finally, it could date its capacity claims. A quarterly statement of hosts in service, sellable resource pools, reserved capacity and maintenance spare by region would be unusually transparent. Even a less granular statement, independently assured and clearly labelled, would be better than allowing a 2020 report's 300-server design figure to carry a 2026 interpretation it cannot support.

The operating conclusion

Outofbox Cloud is not merely a name in a company index. It has a long-visible autonomous system, a validly authorised IPv4 origin, public domain names that mapped into its assigned /23 at the observation time, and recent independent evidence of physical cloud equipment in Belagavi. The local operating case is credible, while the DNS association does not identify server ownership or hosting location. The public network case is also clear: AS147192 originates one /23 and reaches the observed internet through one immediate AS neighbour, the legally distinct but closely connected Outofbox Networks Private Limited.

The larger resilience claim is not yet evidenced. Eight data-centre regions are advertised but not named. A 99.99% SLA is displayed but not publicly defined. A historical report gives an installed count and design ceiling, but current powered and usable capacity is unknown. Racks, cooling and backup power were seen, but their engineering envelope and failure tolerance are unknown. Broader connectivity behind AS141815 exists, but physical route and facility diversity are unknown.

That leaves a practical, fair reading. Outofbox Cloud can be assessed as a small India-centred provider with a supported Belagavi footprint and an operating public network. It should not yet be assessed from public evidence as an eight-region cloud with demonstrated geographic failover. Customers can close that gap through contracts, site and architecture evidence, capacity confirmation, restore tests and a real SLA. Until then, the most important infrastructure fact is not how quickly a Box can launch. It is how many independently survivable places can keep that Box running when Belagavi, the first network hop or the supplying company fails.