Outofbox Cloud promete oito regiões de data center; evidência pública ainda aponta para uma pegada em Belagavi

Resumo

• Outofbox Cloud tem uma rota pública atual: AS147192 origina 103.174.148.0/23, e essa rota esteve visível para 325 de 326 pares IPv4 do RIPE RIS na observação de 15 de julho de 2026.
• A evidência física concentra-se em Sadashiv Nagar, Belagavi. Um relatório local de 2020 descreveu mais de 100 servidores instalados e capacidade para quase 300, enquanto uma visita universitária de setembro de 2025 descreveu racks, refrigeração e alimentação de emergência no mesmo local. Nenhuma fonte comprova a capacidade atual energizada, utilizável ou sobressalente do site.
• A alegação de oito regiões de data center da empresa não vem acompanhada nas páginas públicas de produto de oito nomes de cidades, operadores de instalação, projetos de energia, números de capacidade ou histórico de status região a região. Seus próprios termos também negam operação ininterrupta ou sem erros apesar de uma alegação separada de SLA de 99,99%.
• AS147192 tem um vizinho observado, AS141815, registrado na Outofbox Networks Private Limited, juridicamente distinta de OUTOFBOX CLOUD PRIVATE LIMITED. Essa rede tem conectividade de upstream e de intercâmbio mais ampla, mas a diversidade de rota lógica além do primeiro salto não estabelece entradas de fibra, condutos, prédios, alimentação elétrica de utilidade ou domínios de falha diversos para Outofbox Cloud.

Oito regiões são anunciadas; uma localidade é comprovada

O enunciado mais importante no site de produto da Outofbox Cloud não é o preço de uma máquina virtual pequena. É a alegação, na páginaBoxesda empresa, de que os clientes podem implantar em oito regiões de data center. Essa mesma página usa a frase de marketing "global availability" e anuncia um tempo de inicialização de 55 segundos e um SLA de disponibilidade de 99,99%. Esses itens são proposições mensuráveis, mas não são evidência de uma malha operacional global. Eles pressupõem mais que uma vitrine web: capacidade instalada suficiente de computação, armazenamento e endereçamento para aceitar um pedido; um plano de controle capaz de posicionar a carga; uma instalação com energia ativa; uma trilha roteável; equipe de suporte; e, se a palavra "regiões" for usada em seu sentido normal de infraestrutura, locais de operação geograficamente distinguíveis.

A evidência pública não permite ao leitor enumerar oito desses locais. Nenhuma lista de oito cidades aparece ao lado da alegação. A página não identifica proprietários de instalações, parceiros de colocation, entradas de utilidade, contagens de racks, envelopes de energia, certificações, datas de comissionamento ou endpoints de status regional. Um cliente pode encontrar mais detalhes após criar uma conta, e contratos privados podem conter isso.

A alegação pública, contudo, não pode ser tratada como prova de que existem oito instalações operacionalmente independentes, de que todas aceitam implantações ou de que a carga pode ser transferida entre elas.

O que pode ser comprovado é uma pegada menor com sinais operacionais reais. Aentrada do diretório BTWidentifica a empresa objeto deste perfil. Registros da APNIC associam essa empresa a um sistema autônomo e a uma atribuição IPv4 portátil. O site da empresa e contatos de registry apontam para Sadashiv Nagar, Belagavi, Karnataka. Material local independente descreve servidores, racks, refrigeração e energia de backup ali. No momento da observação, os nomes de domínio públicos da empresa e de controle de cliente também resolviam para endereços dentro desse bloco IPv4 atribuído. A observação DNS estabelece apenas uma associação de endereço; as evidências física e de roteamento, consideradas separadamente, apoiam uma operação local real. Nenhuma delas sustenta um mapa de oito sites.

Essa distinção não é pedantismo. Um cliente que escolha um provedor regional pode valorar apoio local, residência de dados na Índia e menor latência a partir de Karnataka. Esses benefícios podem ser substanciais mesmo se a plataforma estiver concentrada em uma cidade. O risco surge quando uma plataforma compacta é comercializada com linguagem que o leitor pode interpretar como geografia de hipersescala. A avaliação correta não é nem "não existe infraestrutura" nem "oito regiões estão comprovadas". É que a presença em Belagavi é suportada, enquanto a geografia além dela permanece desconhecida na evidência pública.

A empresa, a marca anterior e o operador de rede não são intercambiáveis

OUTOFBOX CLOUD PRIVATE LIMITED é uma empresa privada indiana. Um registro corporativo atual derivado do MCA publicado peloIndiaFilingsfornece o número de identificação corporativa U72900KA2021PTC149665, data de incorporação em 19 de julho de 2021, status de arquivamento ativo conforme atualização de novembro de 2025, e escritório registrado na Fourth Floor, Oneness, Sadashiv Nagar, Belagavi. Ele lista Ajit Kumar S Patil e Gowdesh Singangouda Patil como diretores. Como essa página republica informações de registro em vez de ser o registro em si, o estado de arquivamento atual deve ser confirmado contra os dados mestres do Ministério de Assuntos Corporativos antes de um contrato material.

A marca Outofbox Cloud é anterior a essa empresa. Umrelatório local de fevereiro de 2020 preservadodescreveu OutofBox.cloud como um serviço lançado de Belagavi e o chamou de subsidiária integral da FAAST Networks. O documento dizia que o serviço rodava em ambiente OpenStack customizado, tinha mais de 100 servidores na época e podia acomodar perto de 300 servidores físicos. O relatório também descreveu o site como o primeiro data center da marca. Essas declarações tratam de uma operação de 2020 e de uma relação de marca anterior à incorporação da OUTOFBOX CLOUD PRIVATE LIMITED em julho de 2021. Elas têm valor histórico, não um certificado atual de propriedade.

Uma segunda pessoa jurídica é importante para a história de rede. A APNIC registra AS141815 paraOutofbox Networks Private Limited, enquanto AS147192 pertence a Outofbox Cloud. Os registros usam o mesmo endereço de rua em Sadashiv Nagar e o mesmo número de telefone, mas domínios de e-mail de contato de rede diferentes. Fontes corporativas indicam diretores sobrepostos, e o relatório de 2020 descreve uma relação de grupo. Ainda assim, duas companhias privadas são duas pessoas jurídicas. A autorização telecom, contratos, circuitos e espaço de endereçamento da empresa de rede não podem ser automaticamente contabilizados como ativos ou obrigações da empresa de nuvem.

Essa fronteira torna-se especialmente importante em uma falha ou saída. Se um cliente compra computação da Outofbox Cloud, mas o primeiro caminho de rede visível é fornecido pela Outofbox Networks, o cliente precisa saber qual empresa assina o contrato de serviço, quem é dono ou locatário dos servidores, quem mantém o contrato de locação do data center, quem emite as faturas de banda, quem emprega a equipe de operações de rede e qual entidade é responsável pela restauração. Diretores compartilhados, marca, endereço ou número de telefone podem facilitar coordenação. Eles não substituem direitos contratuais.

O site público atual às vezes mistura as camadas de produto e infraestrutura. Ele anuncia nuvem pública, virtual private cloud, nuvem privada, balanceamento de carga, Kubernetes gerenciado, serviços de plataforma, hospedagem orientada para SAP, comunidade bancária em nuvem, servidores dedicados e colocation. Alguns serviços podem ser entregues diretamente; outros podem depender de infraestrutura afiliada ou fornecedores. As páginas públicas não publicam uma matriz de titularidade serviço a serviço.

Este perfil, portanto, atribui os produtos ao marketing da empresa e os recursos numéricos aos seus titulares registados, sem assumir que toda camada pertence à mesma entidade.

O que é comprovado fisicamente em Belagavi

O mais forte evidência física recente não é um mapa de marketing. É um relato de setembro de 2025 do Department of Artificial Intelligence and Data Science do Angadi Institute of Technology and Management. Oregistro de atividadedo departamento diz que estudantes visitaram Outofbox Cloud Private Limited em Sadashiv Nagar, Belagavi, em 22 de setembro. Ele descreve gestão de máquinas virtuais, virtual private clouds e firewalls, e depois identifica servidores físicos e virtuais, racks de servidores, refrigeração, energia reserva, roteadores, switches, firewalls e sistemas de armazenamento na montagem de data center. O departamento também publicou o relato em seuboletim informativo de 2025-26.

Isso é uma corroboração significativa. Indica que equipamentos associados à empresa eram fisicamente visíveis no local nomeado há menos de um ano antes deste artigo. É mais útil para localizar do que um banco de dados de geolocalização de IP, porque uma visita institucional trata de um lugar real em vez de uma inferência por latência de rede ou dados de registro. OBelagavi Technology Companies Associationtambém descreve Outofbox Cloud como localmente hospedada e sediada na Índia, embora esse perfil associativo seja promocional e não divulgue seu método de verificação.

A evidência ainda tem limites. O relato da faculdade não informa a sala exata do prédio, área útil, número de racks, densidade por rack, serviço de utilidade, topologia de UPS, autonomia de bateria, potência do gerador, autonomia de combustível, carga térmica de refrigeração, supressão de incêndio, aprovação de ocupação ou operador da instalação. Não diz se os sistemas vistos carregavam cargas de produção de clientes, funcionavam como laboratório de treinamento ou combinavam ambas as funções. Não identifica rótulos de propriedade dos equipamentos.

O endereço compartilhado aparece em registros de empresa e recursos como contato administrativo; um endereço administrativo não é, por si só, certidão de instalação.

O artigo de 2020 fornece números, mas não o estado atual. "Mais de 100 servidores" é uma alegação de equipamento instalado em um momento. "Quase 300 servidores físicos" é uma alegação de desenho ou capacidade de espaço. Não informa quantos racks, tomadas de energia ou quilowatts estavam energizados. Não mostra quantos servidores permanecem em serviço em 2026, quantos estão prontos para clientes, que proporção está reservada, ou se houve migração posterior de carga para outro local.

A frase "máquinas virtuais virtualmente ilimitadas" desse relatório deve ser entendida como linguagem promocional: cada máquina virtual ainda consome CPU, memória, armazenamento, rede, energia e refrigeração finitas.

Nenhum registro público localizado para este perfil identifica uma segunda instalação Outofbox Cloud com evidência física comparável. Não foi encontrado nenhum cadastro público de saneamento de energia, conexão de utilidade, aprovação de gerador, certificado de não objeção contra incêndio, licença de data center em nível predial ou documentação ambiental que possa ser atrelada com segurança ao piso de produção da empresa de nuvem. A ausência em busca pública não prova que documento ou aprovação não exista. Significa apenas que o leitor não pode usá-lo para quantificar o site ou validar a alegação de oito regiões.

O mapa, portanto, deve ser desenhado com conservadorismo. Belagavi é uma localidade operacional suportada e local de contato registrado. Mumbai é uma localização lógica de troca apoiada para AS141815 na NIXI, não prova que Outofbox Cloud tenha servidores em Mumbai. Rótulos de Bengaluru e Chennai retornados por ferramentas comerciais de localização de IP são estimativas de medição, não endereços de instalação. As demais regiões anunciadas permanecem desconhecidas até a empresa publicar nomes de cidades e a base legal ou operacional de cada uma.

Catálogo de produtos não é inventário

A página depreços atualda Outofbox Cloud torna o serviço economicamente tangível. Ela lista configurações que vão de um plano pequeno de 2 CPU, 2 GB de memória e 100 GB NVMe por ₹630 por mês até combinações maiores de computação e memória. A página Boxes descreve instâncias de uso geral, otimizadas para CPU, para memória e para armazenamento, e diz que alguns planos usam hyper-threads dedicados. Esses detalhes mostram o que a empresa oferece para vender. Eles não revelam o número ou geração de hosts físicos, a política de oversubscription, replicação de armazenamento, inventário de peças sobressalentes ou regras de colocação por trás dos planos.

A distinção entre catálogo e capacidade importa mais em pico ou falha. Um plano pode permanecer visível quando nenhum host adequado tem memória sobrando. Um painel de controle pode aceitar um pedido enquanto o cumprimento de hardware é adiado. Um vCPU nominalmente dedicado pode ficar isolado no scheduler ainda que compartilhe soquete, canais de memória, controladores de armazenamento, switches top-of-rack e alimentação elétrica. A capacidade NVMe pode ser local de um host, replicada entre hosts, suportada por cluster de armazenamento ou restaurada por serviço de backup separado. A tabela pública de plano não resolve essas possibilidades.

A página inicial diz que a plataforma tem mais de 40 clientes e mais de 500 implantações de nuvem. São contadores de primeira parte, sem data, definição ou auditoria. Uma "implantação" pode ser uma máquina virtual ativa, um lançamento de aplicação, uma ação de provisionamento histórico, um ambiente de teste ou um projeto de cliente. Isso não pode ser convertido em servidores instalados ou capacidade vendida. Tampouco 512 endereços IPv4 atribuídos impõem uma regra de um endereço por servidor: endereços podem servir hipervisores, máquinas virtuais, NAT, balanceadores de carga, roteadores, reservas ou atribuições de cliente.

O site também anuncia balanceamento de carga. Um balanceador pode distribuir requisições entre vários servidores, mas não prova redundância geográfica. Os servidores por trás dele podem compartilhar rack, switch top-of-rack, UPS, circuito de refrigeração, entrada do prédio e roteador upstream. Da mesma forma, uma virtual private cloud oferece isolamento lógico, não uma nuvem fisicamente separada. Uma oferta de private cloud pode rodar em hardware dedicado dentro de instalação compartilhada. Cada recurso é útil, mas cada um trata de uma camada de falha diferente.

Para que a capacidade seja adequada à decisão, o provedor precisaria ligar os planos a uma envoltória operacional: pools de hosts disponíveis por região, regras de alocação de CPU e memória, durabilidade de armazenamento, compromissos de portas de rede, prazos de provisionamento, reserva de manutenção e o ponto no qual a capacidade "disponível" está de fato energizada e implantável. Nenhum desses valores é público. A conclusão segura é que produtos específicos estão comercializados e os endpoints de serviço estão ativos, enquanto inventário instalado e disponível permanece desconhecido.

A rede pública é real, compacta e visível

A evidência operacional pública mais clara é AS147192. O registro de sistema autônomo daAPNICnomeia OOBCLOUD-AS-IN e OUTOFBOX CLOUD PRIVATE LIMITED, marca o registro como ativo e mostra data de registro de 13 de outubro de 2021. Oregistro de endereços da APNICatribui 103.174.148.0 até 103.174.149.255 como espaço IPv4 portátil para a empresa. Isso é um /23 com 512 endereços. O registro de recurso não tem bloco IPv6 correspondente.

Ostatus de roteamentodo RIPE NCC em 15 de julho de 2026 encontrou um prefixo IPv4 originado, 512 endereços, sem prefixo IPv6 e um vizinho observado. A rota ficou visível para 325 dos 326 pares IPv4 no Routing Information Service do RIPE, o que é forte evidência de ampla visibilidade pública de rota nesse momento. É evidência de alcançabilidade, não de pegada operacional global. Oresultado de announced-prefixesmostra 103.174.148.0/23 continuamente na janela de observação de 1 a 15 de julho.

A visibilidade tem histórico em vez de ser um artefato de um dia. Ohistórico de roteamentomostra AS147192 originando o /23 de novembro de 2021 até a janela atual de consulta, sujeito aos limiares de amostragem e visibilidade do sistema coletor. Oresultado de validação de origem de rotaera válido, com uma autorização de origem de rota permitindo AS147192 originar o /23 e prefixos até /24. A validade de RPKI reduz uma classe de erro de origem; ela não fornece uptime, capacidade ou proteção contra erro de operador autorizado.

Na observação, os registros A do site público da empresa e do hostname de controle de cliente apontavam para endereços dentro do /23 atribuído a OUTOFBOX CLOUD PRIVATE LIMITED: o site principal para 103.174.148.253 e mycloud.outofbox.cloud para 103.174.148.14. Isso estabelece apenas uma associação pontual entre esses nomes de domínio e esse intervalo atribuído.

Não estabelece quem possui ou opera os servidores ou aplicações que respondem, onde estão fisicamente hospedados, se algum endereço era anycast, se algum hostname fazia parte de plano de controle de produção, ou se qualquer serviço compartilhava domínio de falha com as cargas dos clientes.

O perfil noPeeringDBé informativo principalmente pelo que não documenta. A entrada autorreferenciada descreve escopo Ásia-Pacífico, faixa de tráfego 100-1000 Mbps e 512 endereços IPv4. Ela lista zero conexões públicas de exchange e zero instalações, e não é materialmente atualizada desde outubro de 2022. O PeeringDB é voluntário; campos zero podem significar informação não divulgada ou desatualizada, e não necessariamente ausência física. Eles, porém, não podem ser usados para sustentar oito regiões.

A rede pública, portanto, é genuína e compacta. Tem rota estável, autorização de origem válida e pontos de serviço vivos. Porém, toda a superfície pública de origem é um bloco IPv4 com nenhuma declaração IPv6 visível e um único vizinho imediato observado. A evidência de rota apoia estado operacional mais fortemente do que o site sozinho. Ela também define uma dependência lógica estreita que merece exame.

Um vizinho imediato, depois uma rede mais ampla

Oobservador de vizinhos de AS147192do RIPE identifica apenas AS141815 do lado esquerdo dos caminhos coletados. Um segundo relatório baseado em coletores chega ao mesmo topo de rede básico. Isso não prova que haja somente um circuito físico. Links privados, sessões de backup, rotas ocultas por política e conexões com baixa visibilidade de coletor podem não aparecer. O que prova é que a rota pública disponível aos coletores examinados não mostrou diversidade independente de primeiro salto.

AS141815 é registrada para Outofbox Networks Private Limited. A lista de autorizações de ISP de 2026 da Department of Telecommunications daDOTregistra essa empresa, não Outofbox Cloud Private Limited, com autorização Category B para Karnataka e o mesmo endereço de Sadashiv Nagar. Essa é uma distinção jurídica relevante: a empresa de rede tem a autorização de ISP divulgada, enquanto a empresa de nuvem detém o ASN de nuvem visível e o bloco de endereços. O registro público não mostra o acordo entre companhias sob o qual trânsito ou instalações são fornecidos.

Além desse primeiro vizinho, AS141815 tem mais opções de rota. Oresultado atual de vizinhos do RIPEpara AS141815 mostra quatro vizinhos observados: AS45117, AS9730, AS137085 e AS147192 da empresa de nuvem. O status de roteamento mostra quatro /24 IPv4 originados e sem IPv6 visível. O PeeringDB lista umaconexão operacional de 1 Gbps no NIXI Mumbaipara AS141815. A existência de múltiplas adjacências externas além de AS141815 pode melhorar escolha de rota e recuperação de falha de upstream.

Ainda assim, não prova redundância física para a nuvem. Dois AS upstreams podem chegar por duas fibras no mesmo cabo, um único handoff de operadora, uma única vala de rua, uma única entrada de prédio ou um roteador. Um porto em internet exchange em Mumbai pode ser alcançado por um único backhaul de Belagavi. O ASN da nuvem pode conectar-se ao ASN da rede por um único cross-connect ou um único equipamento. Nenhuma fonte pública identifica provedores de circuito, locais de handoff, reflectores de rota, pares de edge-router, caminhos de fibra, comutação de proteção ou resultados testados de failover.

A distinção entre diversidade lógica e física também vale para geografia. NIXI Mumbai é um ponto de troca onde AS141815 tem uma porta; não é evidência de que Outofbox Cloud opere computação ou armazenamento em Mumbai. Uma rota pode atravessar Mumbai enquanto a carga permanece em Belagavi. Reciprocamente, um provedor pode alugar computação em outro local sem anunciar essa origem por AS147192. Mapas de rede e caminhos AS mostram alcançabilidade de pacotes, não propriedade de servidor.

Para um cliente, a pergunta útil não é simplesmente "quantos upstreams?". A pergunta é: qual falha remove o acesso a essa carga específica? Responder isso exige um caminho da máquina virtual ao host e ao switch top-of-rack, à borda da instalação, ao handoff cloud-network, às rotas de longa distância e aos provedores upstream. O roteamento público revela o meio da cadeia no nível de ASN. As pontas rack e engenharia civil permanecem desconhecidas.

Capacidade histórica não é capacidade atual utilizável

A figura de mais de 100 servidores de 2020 é o único número público localizado de equipamentos instalados para este perfil. O número de "quase 300" no mesmo relatório descreve quantos servidores físicos o primeiro data center poderia receber. Mesmo que ambos fossem precisos ao serem publicados, representam estados diferentes. Equipamento instalado não é espaço de projeto. Equipamento energizado não é necessariamente operacional. Equipamento operacional não é necessariamente disponível para um novo cliente. Equipamento disponível pode estar reservado ou não atender à combinação de CPU, memória, armazenamento e rede de uma carga.

Nenhuma fonte de 2026 informa a contagem atual de servidores. Nenhuma fonte informa megawatts, kilowatts, contagem de racks, densidade por rack ou alocação de utilidade. Nenhuma fonte informa módulos UPS, capacidade de gerador, duração de bateria, armazenamento diesel, redundância de resfriamento, eficiência de uso de energia (PUE) ou supressão de incêndio. Nenhuma fonte identifica desenho N, N+1, 2N ou redundância distribuída.

A visita de 2025 dos estudantes confirma que havia soluções de refrigeração e energia reserva; não especifica capacidade, condição de manutenção ou capacidade de suportar carga completa de produção durante falha prolongada de utilidade.

O texto de "oito regiões de data center" também não traz um denominador de capacidade. Uma região pode significar uma instalação full-operada pela empresa, um rack locado, capacidade arrendada de outra nuvem, um site de borda ou um rótulo selecionável no painel. Essas formas criam obrigações e modos de falha diferentes. Sem nomes de regiões e divulgação do operador, a capacidade instalada não pode ser atribuída à empresa, e a localização dos dados do cliente não pode ficar estabelecida.

Espaço de endereço também é fácil de superinterpretar. Um /23 dá à organização 512 endereços IPv4, não 512 servidores. Um único servidor pode hospedar muitas máquinas virtuais com endereços privados atrás de poucos endereços públicos. Um cliente pode receber vários endereços públicos. Alguns endereços servem rede, broadcast, gateway, administração, reserva ou funções antiabuso. A contagem IPv4 é um limite superior útil para certos produtos de endereço público, mas não é computação, armazenamento, energia ou número de clientes.

As configurações anunciadas também não dão sinal de estoque. Um plano com 32 núcleos mostrado on-line é uma oferta, não prova de que exista um host correspondente livre. A empresa pode operar scheduler compartilhado, provisionar manualmente, manter hardware sobressalente ou comprar capacidade de parceiros. As páginas públicas não afirmam nada sobre isso. Os termos não publicam prazo de atendimento. Um comprador em potencial deve pedir confirmação de capacidade datada para a região e configuração selecionadas, incluindo se os recursos estão instalados, energizados, testados e imediatamente atribuíveis.

A conclusão defensável de capacidade, portanto, é estreita. Capacidade instalada histórica: mais de 100 servidores, reportada em 2020 e não auditada de forma independente. Capacidade de projeto histórica: quase 300 servidores físicos no primeiro local de Belagavi, reportada em 2020. Presença física atual: racks, servidores, refrigeração e energia reserva observados em visita educacional de 2025. Capacidade atual instalada, energizada, utilizável, vendida, reservada e sobressalente: desconhecida.

O selo de 99,99% precisa de relógio, escopo e reparo

A página Boxes anuncia um SLA de disponibilidade de 99,99%. Se medido em um ano de 365 dias sem exclusões, 0,01% de indisponibilidade equivale a cerca de 52,6 minutos. Se medido mensalmente, dá cerca de 4,4 minutos em um mês de 30 dias. Acordos de SLA reais definem período de medição, componente medido, o que conta como indisponível, exclusões de manutenção, responsabilidades do cliente, janelas de reclamação e créditos de serviço. Uma porcentagem sem esses termos não informa a que remédio segue uma falha de host, armazenamento, rede ou plano de controle.

OsTermos e Condiçõespúblicos da empresa aumentam a incerteza. Eles dizem que a empresa busca disponibilidade e segurança, mas não garante operação ininterrupta ou sem erros, e limitam responsabilidade por impossibilidade de uso dos serviços. Um contrato de serviço assinado separadamente pode substituir ou complementar esses termos do site. Não foi localizado nenhum calendário público de SLA, tabela de créditos ou histórico de status que reconcilie a porcentagem de marketing com o aviso de isenção.

O escopo é crucial. A disponibilidade de computação pode excluir o sistema operacional do cliente. A disponibilidade de host pode coexistir com rede inacessível. A disponibilidade de rede pode coexistir com corrupção de armazenamento. Um SLA regional pode excluir falha simultânea multi-região, enquanto uma máquina virtual implantada em uma única região não tem recuperação geográfica. Sucesso de backup não é sucesso de restauração. Disponibilidade de suporte não garante tempo de restauração.

Para Outofbox Cloud, a questão de SLA está diretamente ligada à evidência de rede e instalação. O SLA de 99,99% aplica-se a cada Box individual, ao pool de hipervisores, ao primeiro salto de rede, ao painel de controle, ao armazenamento ou a todos eles? É medido a partir de sondas externas? As oito regiões têm escopos de SLA separados? Uma falha da AS141815 conta? A manutenção planejada na instalação de Belagavi conta? Qual crédito está disponível e o único remédio do cliente é um crédito? Até um contrato responder essas perguntas, o selo permanece alegação de marketing, não garantia quantitativa de recuperação.

Como o serviço pode falhar

O primeiro caminho de falha é energia da instalação. Uma interrupção de utilidade deveria transferir a carga crítica para UPS e depois para geração ou outra fonte. A visita de 2025 dá suporte à presença de energia de backup, mas nenhuma fonte pública informa autonomia ou redundância. Um gerador pode falhar na partida, acabar combustível, superaquecer ou suportar apenas parte da carga. Baterias podem degradar. Chaves de comutação podem criar ponto único de falha. Se o local tiver um único alimentador ou distribuição, múltiplos dispositivos podem ficar fora do ar ao mesmo tempo, mesmo quando servidores têm dupla fonte.

O segundo caminho é refrigeração. Servidores podem manter energia elétrica enquanto limites térmicos forçam desligamento ou throttling. Uma instalação compacta precisa de refrigeração para a densidade real de rack, não só para a área nominal da sala. Unidades de ar-condicionado redundantes ainda podem compartilhar controles, condensadores, bombas ou energia. A visita educacional confirma equipamentos de refrigeração, mas não ciclo, redundância ou manutenção. O cliente não pode inferir resiliência térmica apenas pela existência de uma unidade de refrigeração.

O terceiro caminho é acesso de rede. O fato de AS147192 ter um vizinho imediato público significa que a rota da nuvem chega à internet observada por meio de AS141815. Um segundo upstream além de AS141815 pode ajudar se um roteador de provedor falhar, mas não se a saída cloud-to-network, o uplink de Belagavi, o backhaul ou a entrada do prédio falhar. A autorização de origem de rota protege a legitimidade da origem, não a disponibilidade. Uma rota válida ainda pode ser retirada, filtrada ou ficar inacessível.

O quarto caminho é o acesso de gestão, cuja arquitetura é desconhecida. O site e o domínio de controle do cliente apontaram para o /23 atribuído durante a observação, mas esse fato não identifica propriedade de servidor ou aplicação, hospedagem física, papel de plano de controle de produção ou cofalha com as cargas dos clientes. DNS, autenticação, faturamento e suporte tornam-se dependências de disponibilidade onde a arquitetura real os torna assim. Um cliente precisaria de uma descrição arquitetural e de procedimentos de redundância fora de banda; o registro público não fornece nenhum dos dois.

O quinto caminho é armazenamento. As páginas de preços anunciam quantidades NVMe e backups semanais em alguns planos de estilo web hosting, mas não explicam replicação para Boxes. NVMe local pode oferecer excelente desempenho enquanto expõe uma máquina virtual a falha no host, a menos que os dados sejam replicados fora. Um cluster de armazenamento replicado pode sobreviver a falha de drive ou nó, mas não necessariamente a uma interrupção de prédio ou erro operacional. Backup semanal reduz exposição de ponto de recuperação apenas se for bem-sucedido, isolado, mantido e restaurável.

O site não publica testes de restauração nem detalhes de localização do backup.

O sexto caminho é estoque de hardware. Um provedor regional pequeno pode oferecer bom suporte e preços atrativos, mas o tempo de reposição depende de discos, fontes, memória, placas de rede, switches e hosts completos sobressalentes. A empresa não publica inventário de peças ou suporte de fornecedor. Um componente com falha pode ser trocado em minutos se houver peça no local, ou em dias se precisar comprar de fora. O catálogo de plano não estabelece estoque de reparo.

O sétimo caminho é pessoas e escalonamento. O site anuncia monitoramento e suporte 24/7, mas os termos públicos não definem metas de resposta ou restauração. Uma cadeia real de escalonamento precisa de incidente reconhecido, dono técnico, cadência de comunicação e autoridade para mover carga ou substituir equipamentos. O tamanho da equipe de plantão, a separação de operações de rede, o modelo de controle de acesso e acesso noturno ao data center são desconhecidos. Testemunhos de clientes na home page são sinais de mercado úteis, mas são selecionados pela empresa e não substituem estatísticas de incidente.

O oitavo caminho é falha de faturamento ou contrato. Uma máquina virtual tecnicamente saudável pode ficar indisponível se a conta for suspensa, se houver disputa de pagamento, se uma reclamação de abuso for mal conduzida ou se a entidade fornecedora mudar termos. Os termos do site reservam discricionariedade ampla e limitam garantias. Clientes precisam de prazos de aviso, fluxo de disputa, direitos de exportação de dados e período de carência definido. Clientes regulados ou críticos também precisam de clareza sobre subcontratados e qual entidade legal pode acessar dados.

O nono caminho é migração. A capacidade de inicializar uma máquina virtual rapidamente não é o mesmo que a capacidade de sair rapidamente. Imagens podem depender de rede proprietária, bancos gerenciados, object storage, snapshots ou serviços de identidade. Grandes volumes demandam tempo e largura de banda para exportação. Cobrança de egress, formatos de imagem, compatibilidade de API e confirmação de exclusão não são descritos publicamente. Sem uma exportação testada, o cliente permanece dependente da plataforma e da equipe de suporte durante incidente.

O décimo caminho é geografia correlata. Se os servidores comprovados, plano de controle, handoff cloud-network e equipe estão concentrados em Sadashiv Nagar, um evento em escala de prédio pode afetá-los conjuntamente. O site alega oito regiões, mas nenhuma fonte pública permite ao cliente selecionar duas instalações nomeadas e verificar que tenham operadores, redes elétricas, zonas de inundação e rotas de backhaul e planos de controle separados. Multi-servidor em um mesmo ambiente ajuda na engenharia de disponibilidade; não é recuperação de desastre geográfica.

Esses são cenários, não alegações de que qualquer deles já tenha ocorrido. Eles mostram por que uma rota atual e um rack fotografado são necessários, porém insuficientes como evidência de resiliência. A confiabilidade depende de como as camadas estão conectadas e do que o provedor testou em falha.

Linguagem de setor bancário impõe padrão maior de diligência

Outofbox Cloud anuncia uma banking community cloud e diz que sua plataforma é adequada para cargas sensíveis de compliance. Essa linguagem não prova que um banco use o serviço ou que a plataforma tenha passado em auditoria específica. Ela torna as lacunas mais consequentes. Uma instituição financeira regulada não pode apenas terceirizar responsabilidade por comprar um serviço de marketing para bancos.

Asdiretrizes do RBI de 2023 sobre terceirização de serviços de TIincluem explicitamente computação em nuvem e serviços de data center. Elas exigem que entidades reguladas cobertas façam due diligence, mapeiem dependências de cadeia, monitorem níveis de serviço, mantenham continuidade de negócio e arranjos de recuperação de desastre, preservem direitos de auditoria e acesso e planejem saída. O apêndice em nuvem trata do ciclo de vida dos dados e movimentação de serviços em nuvem. Essas obrigações recaem principalmente sobre o cliente regulado, mas o provedor deve ser capaz de fornecer evidências e direitos contratuais que o cliente necessita.

Asdiretrizes de cibersegurança da CERT-In de 2022impõem obrigações operacionais a prestadores de serviço, data centers, VPS e provedores de nuvem. Elas incluem sincronização de tempo, notificação em até seis horas para incidentes especificados, requisito móvel de logs de 180 dias dentro da Índia e retenção de informações de cadastro de cliente por cinco anos após cancelamento ou retirada. Este perfil não localizou atestações públicas de conformidade de Outofbox Cloud. Essa ausência não prova não conformidade; esses controles podem ser internos. Um cliente deve perguntar como as obrigações são implementadas e como interagem com privacidade, controle de acesso e compromissos de exclusão.

A página deprivacidadenão responde essas questões empresariais. Ela contém texto de "Suggested text" visivelmente genérico do WordPress sobre comentários, cookies, mídia e perfis de usuário. Não identifica nome jurídico da empresa, regiões de data center, subcontratados, telemetria de serviço em nuvem, cronograma de retenção, contato de segurança, tratamento de cargas de clientes ou transferências transfronteiriças. Um acordo de processamento de dados assinado pode fornecer esses detalhes, mas a página pública não deve ser tratada como declaração de privacidade específica de nuvem.

Para um banco ou cliente crítico, o pedido prático é um pacote de evidências: sites e operadores nomeados; subcontratados; regras de localização e movimento de dados; certificações e escopo de segurança; resumos de pentest e auditoria; histórico de incidentes; testes de backup e restauração; compromissos de ponto e tempo de recuperação; topologia de energia e rede; controles de acesso de equipe; gerenciamento de chaves; evidências de exclusão; e um runbook de saída. A pegada local compacta pode ser uma vantagem para residência e suporte, mas só se o cliente puder verificar onde dados e cópias realmente residem.

A localidade dos dados é suportada em nível de país, não em resolução de oito regiões

A evidência associa fortemente Outofbox Cloud à Índia. A empresa está registrada em Karnataka. A APNIC marca seus recursos numéricos na Índia. Os relatórios físicos apontam para Belagavi. A empresa de rede associada mantém autorização de ISP em Karnataka. A rota pública e os endpoints de serviço estão ativos. Esses fatos apoiam uma identidade operacional centrada na Índia.

Eles não estabelecem o local de cada carga. O país de registro de um IP não é uma coordenada de servidor. Um cliente pode ser colocado em hardware próprio do provedor, racks alugados, capacidade de parceiro ou outra nuvem. Backups podem ficar em outro local. As oito regiões anunciadas não são nomeadas. A palavra "global" numa página de produto pode descrever alcance comercial ou alcançabilidade de internet, e não geografia de data center.

Isso importa para soberania e latência de dados. Um cliente que busca residência em Karnataka deve obter um contrato que nomeie a cidade e a fronteira da instalação, não depender do endereço da empresa. Um cliente que busca residência de dados na Índia deve identificar dados primários, réplicas, snapshots, logs e acesso de suporte. Um cliente que busca recuperação geográfica deve identificar um segundo site e testar restauração nele. A evidência que estabelece uma localidade não pode ser esticada para sustentar oito regiões.

O que transformaria a alegação em evidência de infraestrutura

Outofbox Cloud poderia melhorar materialmente a avaliação pública sem divulgar detalhes sensíveis de engenharia. Primeiro, poderia publicar uma lista de oito regiões com cidade, país, status de lançamento, se a capacidade é operada pela própria empresa ou por parceiro, e quais serviços estão disponíveis em cada. Uma região marcada como planejada deve ficar separada daquela que recebe cargas de produção.

Segundo, poderia publicar um calendário de SLA de serviço. Esse documento deveria definir componente medido, método de observação, exclusões de manutenção, processo de reclamação e créditos. Uma página de status com incidentes históricos e componentes por região permitiria ao cliente comparar a porcentagem com histórico operacional. Uma declaração de que os termos são suplantados por SLA assinado reconciliaria o aviso atual.

Terceiro, poderia disponibilizar um desenho de resiliência de alto nível para Belagavi: número de entradas de utilidade, redundância de UPS e gerador, autonomia mínima de combustível, redundância de refrigeração, proteção contra incêndio, envelope de rack e energia, desenho de borda de rede e data do último teste de failover. Rotas de circuito e detalhes de segurança não precisam ser públicos. Resumos independentes e datados seriam suficientes para diferenciar capacidade instalada, energizada e utilizável.

Quarto, poderia esclarecer a fronteira com Outofbox Networks Private Limited e FAAST Networks. Clientes precisam saber quem fornece trânsito, quem detém autorização telecom, quem opera equipamento de borda, se o arranjo é subcontratação afiliada e o que ocorre se essa relação de suprimento mudar. O dado de rota já torna essa dependência visível; a divulgação contratual tornaria o risco gerenciável.

Quinto, poderia publicar detalhes de portabilidade: formatos de exportação de imagem suportados, formatos de snapshot, documentação de API, preço de egress, limites de banda, procedimentos de exclusão e restauração testada para outra região ou provedor. Portabilidade não é recurso secundário para uma nuvem pequena. Ela integra resiliência porque oferece ao cliente um caminho de recuperação quando a instalação, infraestrutura ou contrato vira o domínio de falha.

Por fim, poderia datar suas alegações de capacidade. Uma declaração trimestral de hosts em operação, recursos vendáveis, recursos utilizáveis e reserva de manutenção por região traria transparência incomum. Mesmo um resumo menos granular, atestado de forma independente e claramente rotulado, seria melhor do que permitir que o número de 300 servidores de projeto de 2020 carregue uma interpretação de 2026 que ele não suporta.

A conclusão operacional

Outofbox Cloud não é apenas um nome em um índice empresarial. Ela possui um sistema autônomo de longa visibilidade pública, origem IPv4 validamente autorizada, nomes de domínio públicos mapeados para seu /23 atribuído no momento da observação e evidência física recente de equipamentos em Belagavi. O caso local operacional é crível, enquanto a associação DNS não identifica titularidade de servidor ou local de hospedagem. O caso de rede público também é claro: AS147192 origina um /23 e alcança a internet observada por meio de um vizinho imediato AS, a juridicamente distinta, porém conectada, Outofbox Networks Private Limited.

A alegação maior de resiliência ainda não está evidenciada. Oito regiões de data center são anunciadas, mas não nomeadas. Um SLA de 99,99% é exibido, mas não publicamente definido. Um relatório histórico fornece contagem instalada e teto de projeto, mas a capacidade atual energizada e utilizável é desconhecida. Racks, refrigeração e energia de backup foram vistos, mas não seu envelope de engenharia e tolerância a falha. Existe conectividade mais ampla atrás de AS141815, mas a diversidade física de rota e instalação é desconhecida.

Isso deixa uma leitura prática e justa. Outofbox Cloud pode ser avaliada como um provedor pequeno e centrado na Índia, com pegada pública suportada em Belagavi e rede operacional ativa. Ainda não deve ser avaliada apenas por evidência pública como uma nuvem de oito regiões com failover geográfico demonstrado. Os clientes podem fechar essa lacuna com contratos, evidência de site e arquitetura, confirmação de capacidade, testes de restauração e um SLA real. Até lá, o fato de infraestrutura mais importante não é quão rápido um Box pode inicializar. É quantos locais independentemente sobreviventes podem manter esse Box em funcionamento se Belagavi, o primeiro hop de rede ou a empresa fornecedora falharem.