Outofbox Cloud promet huit régions de centres de données; les preuves publiques pointent toujours vers un seul site Belagavi

Résumé

• Outofbox Cloud a une route publique actuelle: AS147192 origine 103.174.148.0/23, et cette route était visible par 325 des 326 pairs IPv4 du RIPE RIS lors de l'observation du 15 juillet 2026.
• Les preuves physiques sont concentrées à Sadashiv Nagar, Belagavi. Un rapport local de 2020 décrivait plus de 100 serveurs installés et de la place pour près de 300, tandis qu'une visite universitaire de septembre 2025 décrivait des racks, du refroidissement et une alimentation de secours au même endroit. Aucune source ne prouve la capacité actuelle sous tension, utilisable ou de réserve du site.
• La revendication de huit régions de centres de données par l'entreprise n'est pas accompagnée sur ses pages produits publiques de huit noms de villes, d'opérateurs de installations, de conceptions électriques, de chiffres de capacité ou d'un historique de statut région par région. Ses propres conditions générales désavouent également un fonctionnement ininterrompu ou sans erreur malgré une revendication distincte de SLA de 99,99 %.
• AS147192 a un voisin observé, AS141815, enregistré auprès de Outofbox Networks Private Limited, une entité juridiquement distincte. Ce réseau dispose d'une connectivité amont et d'échange plus large, mais la diversité logique des routes au-delà du premier saut n'établit pas de diversité des entrées de fibre, des conduits, des bâtiments, des alimentations électriques ou des domaines de panne pour Outofbox Cloud.

Huit régions sont annoncées; une seule localité est attestée

La phrase la plus conséquente sur le site produit d'Outofbox Cloud n'est pas le prix d'une petite machine virtuelle. C'est l'affirmation, sur la pageBoxes, que les clients peuvent déployer sur huit régions de centres de données. Cette même page utilise l'expression marketing « disponibilité mondiale » et annonce un temps de lancement de 55 secondes et un SLA de disponibilité de 99,99 %. Ce sont des propositions mesurables, mais elles ne constituent pas une preuve d'une empreinte opérationnelle mondiale. Elles impliquent plus qu'une vitrine web: suffisamment de capacité de calcul, de stockage et d'adresses installée pour accepter une commande; un plan de contrôle capable de placer la charge de travail; une installation alimentée; un chemin routé; du personnel de support; et, si le mot « régions » est utilisé dans son sens normal d'infrastructure, des emplacements d'exploitation géographiquement distincts.

Les preuves publiques ne permettent pas à un lecteur d'énumérer huit de ces emplacements. Aucune liste de huit villes n'accompagne la revendication. La page n'identifie pas les propriétaires d'installations, les partenaires de colocation, les alimentations électriques, les nombres de racks, les enveloppes de puissance, les certifications, les dates de mise en service ou les points de terminaison de statut régional. Un client peut obtenir plus de détails après avoir créé un compte, et des contrats privés peuvent les contenir.

La revendication publique ne peut néanmoins pas être traitée comme une preuve que huit installations indépendamment opérationnelles existent, que toutes acceptent des déploiements, ou qu'une charge de travail peut basculer entre elles.

Ce qui peut être attesté est une empreinte plus petite avec de véritables signaux opérationnels. L'entrée d'annuaire BTWidentifie l'entreprise qui est le sujet de ce profil. Les registres APNIC associent cette entreprise à un système autonome et à une attribution IPv4 portable. Le site web de l'entreprise et ses contacts de registre pointent vers Sadashiv Nagar à Belagavi, Karnataka. Des documents locaux indépendants décrivent des serveurs, des racks, du refroidissement et une alimentation de secours là-bas. Au moment de l'observation, les noms de domaine du site web et du panneau de contrôle client résolvaient également vers des adresses à l'intérieur de ce bloc IPv4 attribué. L'observation DNS établit uniquement une association d'adresses; les preuves physiques et de routage, considérées séparément, soutiennent une opération locale réelle. Aucune d'elles ne soutient une carte de huit sites.

Cette distinction n'est pas de la pédanterie. Un client choisissant un fournisseur régional peut raisonnablement valoriser le support local, la résidence des données en Inde et un accès à plus faible latence depuis le Karnataka. Ces avantages peuvent être substantiels même si la plateforme est concentrée dans une seule ville. Le risque apparaît lorsqu'une plateforme locale compacte est vendue en utilisant un langage que les lecteurs peuvent interpréter comme une géographie hyperscale. La bonne évaluation n'est ni « il n'y a pas d'infrastructure » ni « huit régions sont prouvées ».

C'est que l'empreinte de Belagavi est soutenue, tandis que la géographie au-delà reste inconnue dans les preuves publiques.

L'entreprise, la marque antérieure et l'opérateur réseau ne sont pas interchangeables

OUTOFBOX CLOUD PRIVATE LIMITED est une société privée indienne. Un registre actuel de l'MCA publié parIndiaFilingsdonne le numéro d'identification d'entreprise U72900KA2021PTC149665, une date d'incorporation au 19 juillet 2021, un statut de dépôt actif en date de sa mise à jour de novembre 2025, et le bureau enregistré au Fourth Floor, Oneness, Sadashiv Nagar, Belagavi. Il liste Ajit Kumar S Patil et Gowdesh Singangouda Patil comme directeurs. Parce que cette page republie les informations du registre plutôt que de servir de registre lui-même, l'état exact actuel des dépôts devrait être confirmé auprès des données maîtresses du Ministère des Affaires Corporatives avant un contrat matériel.

La marque Outofbox Cloud précède cette entreprise. Unrapport local de février 2020conservé décrivait OutofBox.cloud comme un service lancé depuis Belagavi et l'appelait une filiale à part entière de FAAST Networks. Il indiquait que le service fonctionnait sur un environnement OpenStack personnalisé, comptait plus de 100 serveurs à l'époque et pouvait accueillir près de 300 serveurs physiques. Le rapport décrivait également le site comme le premier centre de données de la marque. Ces déclarations concernent une opération de 2020 et une relation de marque avant la création d'OUTOFBOX CLOUD PRIVATE LIMITED en juillet 2021. Ce sont des éléments historiques utiles, pas un certificat de propriété actuel.

Une deuxième entité juridique compte pour l'histoire du réseau. APNIC enregistre AS141815 au nom deOutofbox Networks Private Limited, tandis que AS147192 appartient à Outofbox Cloud. Les registres utilisent la même adresse de rue à Sadashiv Nagar et le même numéro de téléphone, mais des domaines de courriel de contact réseau différents. Les sources de données corporatives indiquent des directeurs qui se chevauchent, et le rapport de 2020 décrit une relation de groupe. Néanmoins, deux sociétés privées à responsabilité limitée sont deux personnes juridiques. Les autorisations télécom, contrats, circuits et espace d'adressage de la société de réseau ne peuvent pas être automatiquement comptabilisés comme des actifs ou obligations de la société cloud.

Cette frontière devient particulièrement importante en cas de panne ou de sortie. Si un client achète du calcul à Outofbox Cloud mais que le premier chemin réseau visible est fourni par Outofbox Networks, le client doit savoir quelle entreprise signe le contrat de service, laquelle possède ou loue les serveurs, laquelle détient le bail de l'installation, laquelle facture la bande passante, laquelle emploie le personnel d'exploitation réseau, et quelle entité est responsable de la restauration. Des directeurs, marques, adresses ou numéros de téléphone partagés peuvent faciliter la coordination. Ils ne remplacent pas les droits contractuels.

Le site web public actuel brouille parfois les couches produit et infrastructure. Il annonce cloud public, cloud privé virtuel, cloud privé, équilibrage de charge, Kubernetes géré, services de plateforme, hébergement orienté SAP, un cloud communautaire bancaire, des serveurs dédiés et de la colocation. Certains peuvent être livrés directement; certains peuvent reposer sur des infrastructures ou fournisseurs affiliés. Les pages publiques ne publient pas de matrice de propriété service par service.

Ce profil attribue donc les produits au marketing de l'entreprise et les ressources numériques à leurs titulaires enregistrés, sans supposer que chaque couche est détenue par la même entité.

Ce qui est physiquement attesté à Belagavi

La preuve physique récente la plus solide n'est pas une carte marketing. C'est un récit de septembre 2025 du Département d'Intelligence Artificielle et de Science des Données de l'Angadi Institute of Technology and Management. Leregistre d'activitésdu département indique que des étudiants ont visité Outofbox Cloud Private Limited à Sadashiv Nagar, Belagavi, le 22 septembre. Il décrit la gestion de machines virtuelles, des clouds privés virtuels et des pare-feu, puis identifie des serveurs physiques et virtuels, des racks de serveurs, du refroidissement, une alimentation de secours, des routeurs, des commutateurs, des pare-feu et des systèmes de stockage dans la configuration du centre de données. Le département a également publié le compte rendu dans sonbulletin d'information 2025-26.

Il s'agit d'une corroboration significative. Elle indique que des équipements associés à l'entreprise étaient physiquement visibles dans la localité nommée moins d'un an avant cet article. C'est plus utile pour la localisation qu'une base de données de géolocalisation IP, car une visite institutionnelle concerne un lieu réel plutôt qu'une inférence à partir de la latence réseau ou de données d'enregistrement. LaBelagavi Technology Companies Associationdécrit également Outofbox Cloud comme hébergée localement et basée en Inde, bien que ce profil d'association soit promotionnel et ne divulgue pas sa méthode de vérification.

Les preuves ont encore des limites. Le compte rendu universitaire ne précise pas la salle exacte du bâtiment, la superficie, le nombre de racks, la densité des racks, le service public, la topologie UPS, l'autonomie des batteries, le calibre du générateur, l'endurance en carburant, le devoir de refroidissement, la protection incendie, l'approbation d'occupation ou l'opérateur de l'installation. Il ne dit pas si les systèmes vus supportaient des charges de travail de production client, servaient de laboratoire de formation, ou mélangeaient les deux fonctions. Il n'identifie pas d'étiquettes de propriété sur l'équipement.

L'adresse de rue partagée apparaît dans les registres d'entreprise et de ressources numériques comme un contact administratif; une adresse administrative n'est pas, en soi, un certificat d'installation.

L'article de 2020 fournit des chiffres mais pas de statut actuel. « Plus de 100 serveurs » est une affirmation d'équipement installé à un moment donné. « Près de 300 serveurs physiques » est une affirmation de conception ou de capacité d'espace. Il ne précise pas combien d'unités de rack, de prises électriques ou de kilowatts étaient alors sous tension. Il ne peut pas montrer combien de serveurs restent en service en 2026, combien sont prêts pour les clients, quelle proportion est réservée, ou si la croissance ultérieure a déplacé les charges de travail ailleurs.

L'expression « machines virtuelles virtuellement illimitées » dans ce rapport doit être comprise comme un langage promotionnel: chaque machine virtuelle consomme en fin de compte une capacité finie de CPU, mémoire, stockage, réseau, puissance et refroidissement.

Aucun enregistrement public trouvé pour ce profil n'identifie une deuxième installation d'Outofbox Cloud avec des preuves physiques comparables. Aucune sanction publique d'électricité, capacité de raccordement au réseau, approbation de générateur, certificat de non-opposition incendie, permis de centre de données au niveau du bâtiment ou dépôt environnemental n'a été trouvé qui pourrait être lié en toute sécurité au plancher de production de l'entreprise cloud. L'absence d'une recherche publique n'est pas la preuve qu'un document ou une approbation n'existe pas.

Cela signifie qu'un lecteur ne peut pas les utiliser pour quantifier le site ou tester la revendication des huit régions.

La carte doit donc être tracée avec prudence. Belagavi est une localité opérationnelle soutenue et un emplacement de contact enregistré. Mumbai est un emplacement d'échange logique soutenu pour AS141815 à NIXI, pas une preuve qu'Outofbox Cloud possède des serveurs à Mumbai. Les étiquettes Bengaluru et Chennai renvoyées par les outils de localisation IP commerciaux sont des estimations de mesure, pas des adresses d'installations. Les régions annoncées restantes sont inconnues jusqu'à ce que l'entreprise publie les noms de villes et la base juridique ou opérationnelle de chacune.

Un catalogue de produits n'est pas un inventaire

Lapage de tarificationactuelle d'Outofbox Cloud rend le service économiquement tangible. Elle liste des configurations allant d'un petit plan à deux CPU, 2 Go de mémoire, 100 Go NVMe à 630 ₹ par mois à des combinaisons de calcul et mémoire beaucoup plus grandes. La page Boxes décrit des instances à usage général, optimisées CPU, optimisées mémoire et optimisées stockage et indique que certains plans utilisent des hyper-threads dédiés. Ces détails montrent ce que l'entreprise propose à la vente. Ils ne révèlent pas le nombre ou la génération des hôtes physiques, la politique de sursouscription, la réplication du stockage, l'inventaire des pièces de rechange ou les règles de placement derrière les plans.

La distinction entre un catalogue et une capacité compte surtout lors d'une montée en charge ou d'une panne. Un plan peut rester visible lorsqu'aucun hôte approprié n'a de mémoire libre. Un panneau de contrôle peut accepter une commande alors que la réalisation matérielle est retardée. Un vCPU nominalement dédié peut être isolé au niveau du planificateur tout en partageant un socket, des canaux mémoire, des contrôleurs de stockage, des commutateurs top-of-rack et des alimentations électriques.

La capacité NVMe peut être locale à un hôte, répliquée entre hôtes, soutenue par un cluster de stockage, ou restaurée à partir d'un service de sauvegarde séparé. Le tableau des plans publics ne résout pas ces possibilités.

La page d'accueil indique que la plateforme compte plus de 40 clients et plus de 500 déploiements cloud. Ce sont des compteurs de première partie sans date, définition ou audit. Un « déploiement » pourrait être une machine virtuelle active, un lancement d'application, une action de provisionnement historique, un environnement de test ou un projet client. Il ne peut pas être converti en serveurs installés ou en capacité vendue.

512 adresses IPv4 attribuées n'imposent pas non plus une règle d'une adresse par serveur: les adresses peuvent servir aux hyperviseurs, machines virtuelles, traduction d'adresses réseau, équilibreurs de charge, routeurs, réserves ou attributions clients.

Le site web annonce également l'équilibrage de charge. Un équilibreur de charge peut distribuer les requêtes entre plusieurs serveurs, mais il ne prouve pas la redondance géographique. Les serveurs derrière peuvent partager un rack, un commutateur top-of-rack, un UPS, une boucle de refroidissement, une entrée de bâtiment et un routeur amont. De même, un cloud privé virtuel fournit une isolation logique, pas un cloud physiquement séparé. Une offre de cloud privé peut fonctionner sur du matériel dédié dans une installation partagée. Chacun est utile, mais chacun adresse une couche de panne différente.

Pour que la capacité soit de niveau décisionnel, le fournisseur devrait relier les plans à une enveloppe opérationnelle: pools d'hôtes disponibles par région, règles d'allocation CPU et mémoire, durabilité du stockage, engagements de port réseau, délais de provisionnement, réserve de maintenance, et le point auquel la capacité « disponible » est réellement sous tension et déployable. Aucune de ces valeurs n'est publique. La conclusion prudente est que des produits spécifiques sont commercialisés et les points de terminaison de service sont en direct, tandis que l'inventaire installé et disponible reste inconnu.

Le réseau public est réel, compact et visible

La preuve opérationnelle actuelle la plus claire est AS147192. Leregistre de système autonome de l'APNICnomme OOBCLOUD-AS-IN et OUTOFBOX CLOUD PRIVATE LIMITED, marque le registre actif et montre une date d'enregistrement au 13 octobre 2021. Leregistre d'adresse APNICattribue 103.174.148.0 à 103.174.149.255 comme espace IPv4 portable à l'entreprise. C'est un /23 contenant 512 adresses. Le registre de ressources n'a pas de bloc IPv6 correspondant.

L'observation du statut de routagedu RIPE NCC le 15 juillet 2026 a trouvé un préfixe IPv4 originaire, 512 adresses, aucun préfixe IPv6 et un voisin observé. La route était visible par 325 des 326 pairs IPv4 du Routing Information Service de RIPE, ce qui est une forte preuve d'une large visibilité de route publique à ce moment-là. C'est une preuve d'accessibilité, pas d'une empreinte opérationnelle mondiale. Lerésultat des préfixes annoncésmontre 103.174.148.0/23 en continu dans la fenêtre d'observation du 1er au 15 juillet.

La visibilité a un historique plutôt que d'être un artefact d'un jour. L'historique de routagede RIPE montre AS147192 originaire du /23 de novembre 2021 jusqu'à la fenêtre de requête actuelle, sous réserve des seuils d'échantillonnage et de visibilité du système de collecte. Lerésultat de validation de l'origine de la routeétait valide, avec une autorisation d'origine de route permettant à AS147192 d'originer le /23 et les préfixes jusqu'à /24. La validité RPKI réduit une classe d'erreur d'origine; elle ne fournit pas de disponibilité, capacité, diversité de chemin ou protection contre une erreur d'opérateur autorisé.

Au moment de l'observation, les enregistrements A pour le site web public de l'entreprise et le nom d'hôte du panneau de contrôle client pointaient vers des adresses à l'intérieur du /23 attribué à OUTOFBOX CLOUD PRIVATE LIMITED: le site principal vers 103.174.148.253 et mycloud.outofbox.cloud vers 103.174.148.14. Cela établit uniquement une association ponctuelle entre ces noms de domaine et cette plage attribuée.

Cela n'établit pas qui possédait ou exploitait les serveurs ou applications répondants, où ils étaient physiquement hébergés, si l'une ou l'autre adresse était anycast, si l'un ou l'autre nom d'hôte faisait partie d'un plan de contrôle de production, ou si l'un ou l'autre service partageait un domaine de panne avec les charges de travail client.

Le profil PeeringDB d'AS147192est informatif principalement par ce qu'il ne documente pas. L'entrée auto-déclarée décrit une portée Asie-Pacifique, une bande de trafic de 100 à 1 000 Mbps et 512 adresses IPv4. Elle liste zéro connexion d'échange publique et zéro installation, et n'a pas été mise à jour de manière significative depuis octobre 2022. PeeringDB est volontaire; des champs zéro peuvent indiquer des informations non divulguées ou obsolètes plutôt qu'une absence physique. Ils ne peuvent néanmoins pas être utilisés pour étayer huit régions.

Le réseau est donc à la fois authentique et compact. Il a une route stable, une autorisation d'origine valide et des points de terminaison de service en direct. Pourtant, toute la surface d'origine publique est un seul bloc IPv4 sans annonce IPv6 visible et un seul voisin immédiat observé. La preuve de routage soutient plus fortement le statut opérationnel que le site web seul. Elle définit également une dépendance logique étroite qui mérite d'être examinée.

Un voisin immédiat, puis un réseau plus large

L'observation des voisins d'AS147192de RIPE n'identifie que AS141815 du côté gauche des chemins collectés. Un deuxième rapport basé sur des collecteurs atteint la même topologie de base. Cela ne prouve pas qu'il n'y a qu'un seul circuit physique. Des liaisons privées, des sessions de sauvegarde, des routes cachées par des politiques et des connexions avec une visibilité trop faible des collecteurs peuvent ne pas apparaître. Ce que cela prouve, c'est que la route publique disponible pour les collecteurs examinés n'a pas montré de diversité de premier saut indépendante.

AS141815 est enregistré auprès de Outofbox Networks Private Limited. Laliste 2026 des autorisations ISPdu Département Indien des Télécommunications liste cette entreprise, pas Outofbox Cloud Private Limited, avec une autorisation de Catégorie B pour le Karnataka et la même adresse à Sadashiv Nagar. C'est une distinction juridique précieuse: la société de réseau dispose de l'autorisation ISP divulguée, tandis que la société cloud possède l'ASN et le bloc d'adresses cloud visibles. Le registre public ne montre pas l'accord inter-entreprises en vertu duquel le transit ou les installations sont fournis.

Au-delà de ce premier voisin, AS141815 a plus d'options de routes. Lerésultat des voisins actuelsde RIPE montre quatre voisins observés: AS45117, AS9730, AS137085 et l'ASN de la société cloud, AS147192. Son statut de routage montre quatre /24 IPv4 originaires et aucun IPv6 visible. PeeringDB liste uneconnexion opérationnelle de 1 Gbps à NIXI Mumbaipour AS141815. L'existence de plusieurs adjacences AS externes au-delà d'AS141815 peut améliorer le choix de route et la récupération après une panne de routage amont.

Cela ne prouve toujours pas la redondance physique pour le cloud. Deux ASN amont peuvent arriver sur des fibres dans un seul câble, une seule remise d'opérateur, une seule tranchée de rue, une seule entrée de bâtiment ou un seul routeur. Un port d'échange Internet à Mumbai peut être atteint via un seul backhaul depuis Belagavi. L'ASN cloud peut se connecter à l'ASN réseau via une seule interconnexion ou un seul dispositif.

Aucune source publique n'identifie les fournisseurs de circuits, les emplacements de remise, les réflecteurs de routes, les paires de routeurs de bordure, les entrées de fibre, les chemins de conduit, les taux de commutation de protection ou les résultats de tests de basculement.

La distinction entre diversité logique et physique s'applique également à la géographie. NIXI Mumbai est un point d'échange où AS141815 a un port; ce n'est pas une preuve qu'Outofbox Cloud opère du calcul ou du stockage à Mumbai. Une route peut traverser Mumbai pendant que la charge de travail reste à Belagavi. Inversement, un fournisseur pourrait louer du calcul ailleurs sans l'annoncer depuis AS147192. Les cartes réseau et les chemins AS montrent l'accessibilité des paquets, pas la propriété des serveurs.

Pour un client, la question utile n'est pas simplement « Combien d'amonts? » C'est: quelle panne supprime l'accès à cette charge de travail spécifique? Répondre à cela nécessite un chemin depuis l'hôte de la machine virtuelle et le commutateur top-of-rack à travers la bordure de l'installation, l'interconnexion cloud-réseau, les circuits longue distance et les fournisseurs amont. Le routage public révèle le niveau AS du milieu de cette chaîne. Les extrémités au niveau du rack et du génie civil restent inconnues.

La capacité historique ne peut être promue en capacité actuelle utilisable

Le chiffre de 2020 de plus de 100 serveurs est le seul décompte d'équipement installé trouvé pour ce profil. Le chiffre « près de 300 » du même rapport décrit combien de serveurs physiques le premier centre de données pourrait accueillir. Même si les deux étaient précis lors de la publication, ils représentent des états différents. L'équipement installé n'est pas un espace de conception. L'équipement sous tension n'est pas nécessairement opérationnel. L'équipement opérationnel n'est pas nécessairement disponible pour un nouveau client.

L'équipement disponible peut déjà être réservé, ou peut ne pas satisfaire la combinaison CPU, mémoire, stockage et réseau d'une charge de travail.

Aucune source de 2026 ne donne le nombre actuel de serveurs. Aucune source ne donne de mégawatts, kilowatts, nombre de racks, densité de racks ou allocation de services publics. Aucune source ne quantifie les modules UPS, la capacité du générateur, la durée des batteries, le stockage de diesel, la redondance de refroidissement, l'efficacité de l'utilisation de l'énergie ou la suppression d'incendie. Aucune source n'identifie une conception N, N+1, 2N ou à redondance distribuée.

La visite étudiante de 2025 confirme que des solutions de refroidissement et d'alimentation de secours étaient présentes; elle ne précise pas leur capacité, leur état de maintenance ou leur capacité à supporter une charge de production complète lors d'une panne de service public prolongée.

Le « huit régions de centres de données » du site web manque également d'un dénominateur de capacité. Une région pourrait signifier une installation complète exploitée par l'entreprise, un rack loué, une capacité louée auprès d'un autre cloud, un site périphérique, un emplacement planifié ou une étiquette sélectionnable dans un panneau de contrôle. Ces arrangements créent différentes obligations et modes de panne. Sans noms de régions et divulgations des opérateurs, la capacité installée ne peut être attribuée à l'entreprise et la localisation des données client ne peut être établie.

L'espace d'adressage est également facile à surinterpréter. Un /23 donne à l'organisation 512 adresses IPv4, pas 512 serveurs. Un seul serveur peut héberger de nombreuses machines virtuelles avec des adresses privées derrière quelques adresses publiques. Un client peut recevoir plusieurs adresses publiques. Certaines adresses sont consommées par des fonctions réseau, de diffusion, de passerelle, de gestion, de réserve ou anti-abus. Le nombre d'IPv4 est une entrée de borne supérieure utile pour certains produits d'adresses publiques, mais ce n'est pas un nombre de calcul, de stockage, de puissance ou de client.

Les configurations annoncées ne fournissent pas non plus de signal de stock. Un plan 32 cœurs affiché en ligne est une offre, pas la preuve qu'un hôte correspondant est libre. L'entreprise peut opérer un planificateur mutualisé, provisionner manuellement, maintenir du matériel de rechange ou acheter de la capacité auprès de partenaires. Les pages publiques ne le disent pas. Les conditions générales ne publient pas de délai d'exécution.

Un acheteur potentiel devrait demander une confirmation de capacité datée pour la région et la configuration sélectionnées, y compris si les ressources sont installées, sous tension, testées et immédiatement attribuables.

La conclusion défendable sur la capacité est donc étroite. Capacité installée historique: plus de 100 serveurs, rapportée en 2020 et non auditée indépendamment. Capacité de conception historique: près de 300 serveurs physiques sur le premier site de Belagavi, rapportée en 2020. Présence physique actuelle: racks, serveurs, refroidissement et alimentation de secours observés lors d'une visite éducative en 2025. Capacité installée, sous tension, utilisable, vendue, réservée et de rechange actuelle: inconnue.

Un badge 99,99 % a besoin d'une horloge, d'un périmètre et d'un recours

La page Boxes annonce un SLA de disponibilité de 99,99 %. Si mesuré sur une année de 365 jours sans exclusions, 0,01 % de temps d'arrêt équivaut à environ 52,6 minutes. Si mesuré mensuellement, c'est environ 4,4 minutes dans un mois de 30 jours. Les véritables accords de niveau de service définissent la période de mesure, le composant mesuré, ce qui compte comme indisponible, les exclusions de maintenance, les responsabilités du client, les fenêtres de réclamation et les crédits de service. Un pourcentage sans ces termes ne peut pas dire à un client quel recours suit une panne d'hôte, de stockage, de réseau ou de plan de contrôle.

LesConditions généralespubliques de l'entreprise créent une incertitude supplémentaire. Elles disent que l'entreprise s'efforce d'assurer la disponibilité et la sécurité mais ne garantit pas un fonctionnement ininterrompu ou sans erreur, et elles déclinent toute responsabilité en cas d'incapacité à utiliser les services. Un bon de commande de service signé séparément peut remplacer ou compléter ces conditions du site. Aucun calendrier de SLA public, tableau de crédit ou archive d'historique de statut n'a été trouvé pour concilier le pourcentage marketing avec les clauses de non-responsabilité.

Le périmètre est crucial. La disponibilité du calcul peut exclure le système d'exploitation d'un client. La disponibilité de l'hôte peut coexister avec un réseau inaccessible. La disponibilité du réseau peut coexister avec une corruption de stockage. Un SLA régional peut exclure une panne multi-région simultanée, tandis qu'une machine virtuelle déployée dans une seule région n'a pas de récupération géographique. Le succès de la sauvegarde n'est pas le succès de la restauration. La disponibilité du support ne garantit pas un temps de restauration.

Pour Outofbox Cloud, la question du SLA est directement liée aux preuves du réseau et de l'installation. Le 99,99 % s'applique-t-il à chaque Box individuelle, au pool d'hyperviseurs, au premier saut réseau, au panneau de contrôle, au stockage, ou à tous? Est-il mesuré à partir de sondes externes? Les huit régions sont-elles des périmètres de SLA séparés? Une panne d'AS141815 compte-t-elle? La maintenance planifiée à l'installation de Belagavi compte-t-elle? Quel crédit est disponible, et le seul recours du client est-il un crédit?

Tant qu'un contrat ne répond pas à ces questions, le badge est une affirmation marketing plutôt qu'une garantie de récupération quantifiée.

Comment le service peut tomber en panne

Le premier chemin de panne est l'alimentation de l'installation. Une interruption du service public devrait transférer la charge critique sur l'UPS puis sur la génération ou une autre alimentation. La visite de 2025 confirme la présence d'une alimentation de secours, mais aucune source publique ne précise l'autonomie ou la redondance. Un générateur peut ne pas démarrer, manquer de carburant, surchauffer ou ne supporter qu'une partie de la charge. Les batteries peuvent être dégradées. L'appareillage de commutation peut créer un point de défaillance commun.

Si le site a une seule alimentation électrique ou un seul chemin de distribution, plusieurs dispositifs peuvent s'éteindre ensemble même si les serveurs individuels ont des alimentations doubles.

Le deuxième chemin est le refroidissement. Les serveurs peuvent conserver l'alimentation électrique tandis que les limites thermiques forcent des arrêts ou un ralentissement. Une installation compacte a besoin de suffisamment de refroidissement pour la densité réelle des racks, pas seulement la surface nominale de la pièce. Des unités de climatisation redondantes peuvent encore partager des contrôles, des condenseurs, des pompes ou de l'alimentation. La visite éducative confirme l'équipement de refroidissement mais pas le devoir, la redondance ou la maintenance.

Un client ne peut pas déduire la résilience thermique de la présence d'une unité de refroidissement.

Le troisième chemin est l'accès réseau. Le seul voisin visible publiquement d'AS147192 signifie que la route du cloud atteint l'Internet observé via AS141815. Un deuxième amont au-delà d'AS141815 peut aider si une route de fournisseur tombe en panne, mais pas si l'interconnexion cloud-réseau, le routeur de bordure partagé, le backhaul de Belagavi ou l'entrée du bâtiment tombe en panne. L'autorisation d'origine de route protège la légitimité de l'origine, pas la disponibilité. Une route valide peut toujours être retirée, filtrée ou inaccessible.

Le quatrième chemin est l'accès de gestion, dont l'architecture est inconnue. Les noms de domaine du site web et du panneau de contrôle client pointaient vers le /23 attribué à l'entreprise lors de l'observation, mais ce fait n'identifie pas la propriété du serveur ou de l'application, l'hébergement physique, un rôle de plan de contrôle de production, ou une co-panne avec les charges de travail client. Le DNS, l'authentification, la facturation et le support deviennent des dépendances de disponibilité uniquement là où l'architecture réelle les rend tels.

Un client aurait besoin d'une description d'architecture et de procédures hors bande testées; le registre public ne fournit ni l'un ni l'autre.

Le cinquième chemin est le stockage. Les pages de tarification annoncent des quantités NVMe et des sauvegardes hebdomadaires sur certains plans de type hébergement web, mais n'expliquent pas la réplication pour les Boxes. Le NVMe local peut offrir d'excellentes performances tout en exposant une machine virtuelle à une panne au niveau de l'hôte, à moins que les données ne soient répliquées ailleurs. Un cluster de stockage répliqué peut survivre à une panne de disque ou de nœud mais pas nécessairement à une panne de bâtiment ou à une erreur d'opérateur.

Une sauvegarde hebdomadaire limite l'exposition au point de récupération uniquement si elle est réussie, isolée, conservée et restaurable. Le site ne publie pas de détails sur les tests de restauration ou l'emplacement des sauvegardes.

Le sixième chemin est le stock de matériel. Un petit fournisseur régional peut offrir un support proche et des prix attractifs, mais le temps de remplacement dépend des disques de rechange, des alimentations, de la mémoire, des cartes réseau, des commutateurs et des hôtes complets. L'entreprise ne publie pas d'inventaire des pièces ou de support fournisseur. Un composant défaillant peut être remplacé en quelques minutes si une pièce de rechange est sur site, ou en jours si elle doit être approvisionnée. La capacité annoncée dans un tableau de plans n'établit pas un stock de réparation.

Le septième chemin est le personnel et l'escalade. Le site annonce une surveillance et un support 24/7, mais les conditions publiques ne définissent pas d'objectifs de réponse ou de restauration. Une véritable chaîne d'escalade a besoin d'un incident reconnu, d'un responsable technique, d'une cadence de communication et de l'autorité pour déplacer une charge de travail ou remplacer un équipement. La taille de l'équipe d'astreinte, la séparation des opérations réseau, le modèle de contrôle d'accès et l'accès à l'installation après les heures de travail sont inconnus.

Les témoignages clients sur la page d'accueil sont des signaux de marché utiles, mais ils sont sélectionnés par l'entreprise et ne remplacent pas les statistiques d'incidents.

Le huitième chemin est une panne de facturation ou de contrat. Une machine virtuelle techniquement saine peut devenir indisponible si un compte est suspendu, un paiement contesté, une plainte pour abus mal gérée ou l'entité fournisseuse modifie ses conditions. Les conditions du site web réservent une large discrétion et limitent les garanties. Les clients ont besoin de délais de préavis, d'escalade des litiges, de droits d'exportation des données et d'une période de grâce définie. Les clients réglementés ou critiques ont également besoin de clarté sur les sous-traitants et sur l'entité juridique pouvant accéder aux données.

Le neuvième chemin est la migration. La capacité à démarrer rapidement une machine virtuelle n'est pas la même que la capacité à partir rapidement. Les images peuvent dépendre de réseaux propriétaires, de bases de données gérées, de stockage d'objets, d'instantanés ou de services d'identité. Les grands ensembles de données prennent du temps et de la bande passante à exporter. La facturation du trafic sortant, les formats d'image, la compatibilité des API et la confirmation de suppression ne sont pas décrits publiquement.

Sans une exportation testée, le client reste dépendant à la fois de la plateforme et de son équipe de support lors d'un incident.

Le dixième chemin est la géographie corrélée. Si les serveurs attestés, le plan de contrôle, l'interconnexion cloud-réseau et le personnel sont concentrés à Sadashiv Nagar, un seul événement à l'échelle du bâtiment pourrait les affecter ensemble. Le site revendique huit régions, mais aucune source publique ne permet à un client de sélectionner deux installations nommées et de vérifier qu'elles ont des opérateurs, des réseaux électriques, des zones inondables, des itinéraires de backhaul et des plans de contrôle distincts.

Le placement multi-serveurs dans une seule pièce est une ingénierie de disponibilité utile; ce n'est pas une reprise après sinistre géographique.

Ce sont des scénarios, pas des affirmations que l'un d'eux s'est produit. Ils montrent pourquoi une route actuelle et un rack photographié sont des preuves nécessaires mais insuffisantes pour la résilience. La fiabilité dépend de la façon dont les couches sont connectées et de ce que le fournisseur a testé en cas de panne.

Un langage bancaire soulève un niveau de diligence plus élevé

Outofbox Cloud annonce un cloud communautaire bancaire et dit que sa plateforme est adaptée aux charges de travail sensibles à la conformité. Ce langage ne prouve pas qu'une banque utilise le service ou que la plateforme a passé un audit particulier. Il rend néanmoins les détails manquants plus conséquents. Une institution financière réglementée ne peut pas externaliser sa responsabilité simplement en achetant un service commercialisé pour les banques.

Lesdirectives de 2023 de la Reserve Bank of India sur l'externalisation des services informatiquesincluent explicitement le cloud computing et les services de centres de données. Elles exigent des entités réglementées couvertes qu'elles effectuent une diligence raisonnable, cartographient les dépendances de la chaîne d'approvisionnement, surveillent les niveaux de service, maintiennent des arrangements de continuité des activités et de reprise après sinistre, préservent les droits d'audit et d'accès, et planifient une sortie. L'annexe cloud traite du cycle de vie des données et du mouvement des services hébergés dans le cloud. Ces devoirs incombent principalement au client réglementé, mais un fournisseur doit être en mesure de fournir les preuves et les droits contractuels dont le client a besoin.

Lesdirectives de cybersécurité de 2022 du CERT-Inimposent des obligations opérationnelles aux fournisseurs de services, centres de données, fournisseurs VPS et fournisseurs cloud. Elles incluent la synchronisation temporelle, le signalement sous six heures pour les incidents spécifiés, une exigence de journalisation glissante de 180 jours en Inde, et la conservation des informations d'enregistrement client spécifiées pendant cinq ans après l'annulation ou le retrait. Ce profil n'a pas trouvé d'attestations de conformité publiques de la part d'Outofbox Cloud. Cette absence ne prouve pas la non-conformité; ces contrôles peuvent être internes. Un client devrait demander comment les obligations sont mises en œuvre et comment elles interagissent avec les engagements en matière de confidentialité, de contrôle d'accès et de suppression.

Lapage de confidentialitéde l'entreprise ne répond pas à ces questions d'entreprise. Elle contient visiblement un « Texte suggéré » WordPress générique sur les commentaires, les cookies, les médias et les profils utilisateur. Elle n'identifie pas le nom juridique de l'entreprise, les régions des centres de données, les sous-traitants, la télémétrie du service cloud, le calendrier de conservation, le contact de sécurité, le traitement des charges de travail client ou les transferts transfrontaliers. Un accord de traitement des données signé peut fournir ces détails, mais la page publique ne doit pas être traitée comme une déclaration de confidentialité spécifique au cloud.

Pour une banque ou un autre client critique, la demande pratique est un dossier de preuves: sites et opérateurs nommés; sous-traitants; règles de localisation et de mouvement des données; certifications de sécurité et périmètre; résumés de tests d'intrusion et d'audits; historique des incidents; tests de sauvegarde et de restauration; engagements de temps de récupération et de point de récupération; topologie de l'alimentation et du réseau; contrôles d'accès du personnel; gestion des clés; preuves de suppression; et un manuel de sortie.

L'empreinte locale compacte du fournisseur pourrait être un avantage pour la résidence et le support, mais seulement si le client peut vérifier où les données et les copies résident réellement.

La localisation des données est soutenue au niveau national, pas à la résolution de huit régions

Les preuves associent fortement Outofbox Cloud à l'Inde. L'entreprise est enregistrée au Karnataka. L'APNIC marque ses ressources numériques en Inde. Les rapports physiques pointent vers Belagavi. La société de réseau associée détient une autorisation ISP pour le Karnataka. La route publique et les points de terminaison de service sont actifs. Ces faits soutiennent une identité opérationnelle centrée sur l'Inde.

Ils n'établissent pas l'emplacement de chaque charge de travail. Un pays d'enregistrement IP n'est pas une coordonnée de serveur. Un client peut être placé sur du matériel appartenant au fournisseur, sur des racks loués, sur de la capacité partenaire ou sur un autre cloud. Les sauvegardes peuvent résider ailleurs. Les huit régions annoncées sont sans nom. Le mot « mondial » sur une page produit peut décrire la portée des ventes ou l'accessibilité Internet plutôt que la géographie des centres de données.

Cela compte pour la souveraineté des données et la latence. Un client cherchant une résidence au Karnataka devrait obtenir un contrat nommant la ville et les limites de l'installation, et non se fier à l'adresse de l'entreprise. Un client cherchant une résidence en Inde devrait identifier les données primaires, les réplicas, les instantanés, les journaux et l'accès au support. Un client cherchant une reprise géographique devrait identifier un deuxième site et y tester une restauration. Les preuves qui établissent une localité ne peuvent pas être étendues pour servir de preuve pour huit.

Ce qui transformerait la revendication en preuve d'infrastructure

Outofbox Cloud pourrait améliorer considérablement l'évaluation publique sans divulguer de détails d'ingénierie sensibles. Premièrement, elle pourrait publier une liste de huit régions avec la ville, le pays, le statut de lancement, si la capacité est exploitée par l'entreprise ou par un partenaire, et quels services sont disponibles dans chacune. Une région marquée comme planifiée devrait être séparée d'une région qui accepte des charges de travail de production.

Deuxièmement, elle pourrait publier un calendrier de niveaux de service. Ce document devrait définir le composant mesuré, la méthode d'observation, les exclusions de maintenance, le processus de réclamation et les crédits. Une page de statut avec un historique des incidents et des composants au niveau régional permettrait aux clients de comparer le pourcentage avec l'historique opérationnel. Une déclaration selon laquelle les conditions générales sont remplacées par un SLA signé concilierait les clauses de non-responsabilité actuelles.

Troisièmement, elle pourrait fournir une conception de résilience de haut niveau pour le site de Belagavi: nombre d'alimentations électriques, classe de redondance UPS et générateur, autonomie minimale en carburant, redondance de refroidissement, protection incendie, enveloppe de rack et de puissance, conception de bordure réseau et date du dernier test de basculement. Les itinéraires exacts des circuits et les détails sensibles à la sécurité n'ont pas besoin d'être publics. Des résumés datés et assurés indépendamment seraient suffisants pour distinguer la capacité installée, sous tension et utilisable.

Quatrièmement, elle pourrait clarifier la frontière avec Outofbox Networks Private Limited et FAAST Networks. Les clients ont besoin de savoir qui fournit le transit, qui détient l'autorisation télécom, qui opère les équipements de bordure, si l'arrangement est un sous-traitant affilié, et ce qui se passe si cette relation d'approvisionnement change. Les données de routage rendent déjà la dépendance visible; une divulgation contractuelle la rendrait gérable.

Cinquièmement, elle pourrait publier des détails sur la portabilité: formats d'exportation d'image supportés, formats d'instantané, documentation API, tarification du trafic sortant, limites de bande passante, procédures de suppression et restauration testée vers une autre région ou un autre fournisseur. La portabilité n'est pas une fonctionnalité secondaire pour un petit cloud. Elle fait partie de la résilience car elle donne au client une voie de récupération lorsque le fournisseur, l'installation ou le contrat est le domaine de panne.

Enfin, elle pourrait dater ses affirmations de capacité. Un relevé trimestriel des hôtes en service, des pools de ressources commercialisables, de la capacité réservée et des pièces de rechange de maintenance par région serait exceptionnellement transparent. Même une déclaration moins granulaire, assurée indépendamment et clairement étiquetée, serait préférable au fait de laisser la conception de 300 serveurs d'un rapport de 2020 porter une interprétation en 2026 qu'elle ne peut pas soutenir.

La conclusion opérationnelle

Outofbox Cloud n'est pas simplement un nom dans un index d'entreprises. Elle a un système autonome visible depuis longtemps, une origine IPv4 valide et autorisée, des noms de domaine publics qui mappaient dans son /23 attribué au moment de l'observation, et des preuves indépendantes récentes d'équipement cloud physique à Belagavi. Le dossier opérationnel local est crédible, tandis que l'association DNS n'identifie pas la propriété du serveur ou l'emplacement d'hébergement.

Le dossier réseau public est également clair: AS147192 origine un /23 et atteint l'Internet observé via un seul voisin AS immédiat, la société Outofbox Networks Private Limited, juridiquement distincte mais étroitement liée.

La revendication plus large de résilience n'est pas encore attestée. Huit régions de centres de données sont annoncées mais non nommées. Un SLA de 99,99 % est affiché mais non défini publiquement. Un rapport historique donne un décompte installé et un plafond de conception, mais la capacité actuelle sous tension et utilisable est inconnue. Des racks, du refroidissement et une alimentation de secours ont été vus, mais leur enveloppe d'ingénierie et leur tolérance aux pannes sont inconnues. Une connectivité plus large derrière AS141815 existe, mais la diversité physique des routes et des installations est inconnue.

Cela laisse une lecture pratique et équitable. Outofbox Cloud peut être évaluée comme un petit fournisseur centré sur l'Inde avec une empreinte Belagavi soutenue et un réseau public en fonctionnement. Elle ne devrait pas encore être évaluée sur la base de preuves publiques comme un cloud à huit régions avec un basculement géographique démontré. Les clients peuvent combler cet écart par des contrats, des preuves de site et d'architecture, une confirmation de capacité, des tests de restauration et un véritable SLA. D'ici là, le fait d'infrastructure le plus important n'est pas la rapidité avec laquelle une Box peut être lancée.

C'est combien d'endroits indépendamment survivables peuvent maintenir cette Box en fonctionnement lorsque Belagavi, le premier saut réseau ou l'entreprise fournisseuse tombe en panne.