VERYCLOUD SAS e o registro público por trás de um nome de nuvem

Resumo

• VERYCLOUD SAS não é mais apenas um nome de hospedagem sugestivo. Registros públicos franceses identificam uma empresa ativa em Paris criada em abril de 2025, o provedor descreve uma transferência de um projeto anterior, e registros RIPE conectam o nome à AS198825, que já operava desde 2023.
• A pegada de rede é incomumente inspecionável: cinco prefixos IPv4 e dois IPv6 estavam visíveis da AS198825 na data da evidência, cada origem observada tinha RPKI válido, e registros públicos de roteamento mostraram dois vizinhos upstream e dois downstream. Isso comprova um papel de roteamento ativo, não propriedade de cada endereço, diversidade de caminho físico ou disponibilidade de aplicação.
• O limite do serviço importa mais do que o índice de disponibilidade principal. Os termos da VeryCloud colocam backups comuns, administração do sistema operacional, manutenção de aplicativos e grande parte do trabalho de recuperação sobre o cliente, a menos que serviços extras sejam comprados. Suas alegações de localização francesa são significativas, mas subprocessadores, sistemas de controle, logs e transferências protegidas ainda exigem um mapa de dados específico do serviço.
• Suporte faz parte do produto, não uma promessa decorativa. Termos públicos oferecem tickets 24 horas por dia para a infraestrutura da VeryCloud, enquanto o registro de avaliações contém tanto elogios pela configuração rápida quanto reclamações antigas sobre exclusão de serviços. Os compradores precisam de evidências de tickets, testes de restauração e propriedade clara de escalação antes de tratar um nome de nuvem roteado como garantia operacional.

Comece pela discrepância de datas

Provedores de nuvem frequentemente se apresentam como se a marca, a empresa e a infraestrutura tivessem surgido no mesmo momento. A cronologia pública da VeryCloud é mais complicada e, por ser mais complicada, é mais útil.

Oregistro público de empresas francêsregistra uma empresa ativa chamada VERYCLOUD, forma jurídica SAS, criada em 18 de abril de 2025. Ele fornece a sede registrada como 60 rue Francois Ier em Paris, o SIREN como 943 573 584, o SIRET da sede como 943 573 584 00019 e a atividade principal declarada como telecomunicações sem fio. Esses detalhes estabelecem uma contraparte legal atual. Eles não mostram uma empresa de nuvem com décadas de existência. Mostram uma jovem empresa francesa com um registro legível.

A cronologia da infraestrutura começa antes. Aprópria história da VeryClouddiz que o projeto começou em 2023, obteve o AS198825 e um IPv4 /24 em março daquele ano, fundou a SAS em abril de 2025 e transferiu suas atividades para a empresa em 26 de abril de 2025. Oregistro do AS198825da RIPE data independentemente o objeto de sistema autônomo em 19 de abril de 2023. O objeto de organização do RIPE paraVERYCLOUD SAS, por outro lado, foi criado em 29 de abril de 2025. As datas se alinham com a história geral do provedor: rede primeiro, empresa depois.

Isso não é inerentemente alarmante. Projetos são regularmente incorporados após uma fase experimental ou de associação. É, no entanto, um ponto de diligência material. Um cliente deve perguntar quais ativos, contratos, licenças, compromissos de suporte, passivos, registros de monitoramento e dados de cliente foram transferidos para a SAS. O site diz que as atividades foram transferidas. As fontes públicas consideradas aqui não incluem um acordo de transferência ou um aviso ao cliente explicando seu escopo.

A cronologia também altera a forma como as evidências de mercado mais antigas devem ser lidas. Uma avaliação de 2023 descreve o projeto anterior, não um serviço entregue por uma empresa que ainda não existia. Pode iluminar o histórico operacional da marca, mas não pode estabelecer automaticamente o desempenho da SAS atual. Por outro lado, a SAS não deve reivindicar um registro corporativo mais longo apenas porque o domínio e o ASN são mais antigos. A formulação honesta é que uma empresa francesa de dois anos continua um projeto de hospedagem e identidade de rede que começou em 2023.

Operfil de diretório do BTWé, portanto, um ponto de partida, não uma identidade completa. Ele identifica um operador de infraestrutura de rede privada, mas o registro da empresa, o site e os registros do RIPE fornecem as conexões decisivas: nome legal, local, datas e número de rede. Para um comprador, essas conexões transformam uma marca de nuvem genérica em uma contraparte atribuível. Elas também expõem a primeira pergunta não respondida: o que exatamente continuou através da fronteira de 2025?

O catálogo é amplo, mas amplitude não é integração

A oferta pública da VeryCloud abrange vários modelos técnicos e comerciais. Seus termos nomeiam servidores virtuais KVM, servidores dedicados bare-metal, hospedagem web compartilhada, colocation, servidores de jogos pré-configurados e serviços de rede. O site adiciona trânsito IP remoto e proteção anti-DDoS. Um comprador pode, portanto, encontrar a mesma marca como inquilino de uma máquina virtual, administrador de um servidor físico, cliente colocando hardware em uma instalação ou operador de rede recebendo rotas através de um túnel.

Essas não são variações menores de um produto. Elas alocam controle de forma diferente.

Em um VPS, a VeryCloud controla o hardware subjacente, o hipervisor e a rede do provedor; o cliente normalmente controla o sistema operacional convidado, credenciais, aplicativos e dados. Em um servidor dedicado, o cliente ganha uma máquina inteira e acesso de gerenciamento de nível inferior, mas ainda depende do provedor para energia, intervenção física e conectividade externa. Em colocation, o cliente pode possuir o servidor enquanto depende da VeryCloud e da instalação para acesso ao rack, energia e conexões cruzadas.

O trânsito remoto vai além: o equipamento do cliente pode permanecer em outro local enquanto as rotas e o tráfego filtrado chegam através de túneis GRE, VXLAN ou EoIP.

Apágina de trânsito remototorna esse último modelo excepcionalmente explícito. Ela anuncia sessões BGP IPv4 e IPv6, tabelas de roteamento padrão ou completas, limites de prefixo selecionáveis e contato da equipe após a validação de um pedido. A rede não é apenas um ingrediente oculto por trás da hospedagem web. Ela é em si mesma um limite de serviço vendável.

Essa amplitude cria duas armadilhas. A primeira é assumir que uma marca comum implica um nível de serviço comum. O contrato da VeryCloud define uma disponibilidade mensal alvo de 99,99% para VPS e servidores dedicados, mas 99,9% para hospedagem compartilhada. Um túnel, um servidor físico e uma conta compartilhada também podem ter diferentes arranjos de manutenção, capacidade, backup e resposta. O formulário de pedido e as condições especiais importam porque a página inicial não pode resolver todas as variações.

A segunda armadilha é assumir que a infraestrutura comum cria um único ponto de responsabilidade para todo o sistema do cliente. OsTermos de Vendada VeryCloud dizem que o suporte incluído cobre a infraestrutura e os serviços do provedor: rede, hardware, disponibilidade do servidor e painéis de controle. A menos que um serviço gerenciado seja adquirido, ele exclui administração do sistema operacional, manutenção de aplicativos do cliente, depuração de código, otimização e recuperação de dados do cliente. Uma aplicação web pode ficar indisponível enquanto o servidor, a rede e o painel de controle permanecem dentro do contrato.

Esta é a diferença entre um catálogo de serviços e um modelo operacional integrado. O catálogo diz o que pode ser pedido. O modelo operacional diz quem monitora cada camada, quem diagnostica uma falha entre camadas e quem está autorizado a restaurá-la. Os compradores devem mapear essas responsabilidades antes de comparar números de processador, memória ou largura de banda. Um servidor barato pode se tornar uma ambiguidade cara quando uma falha de aplicativo cruza a fronteira entre a infraestrutura do provedor e a administração do cliente.

A automação acelera o caso comum

O apelo de um pequeno provedor de nuvem é muitas vezes a imediatidade. Selecione um plano, pague, receba credenciais e comece. O contrato da VeryCloud distingue serviços automatizados, como VPS e hospedagem compartilhada, que são implantados em minutos após o pagamento bem-sucedido, de opções de hardware dedicado e colocation que podem exigir provisionamento manual. Sua conta mantém assinaturas, faturamento e suporte. Sua documentação pública fornece guias de autoatendimento. Juntas, essas superfícies formam uma cadeia de automação compacta.

No caso comum, essa cadeia remove trabalho. A confirmação de pagamento pode acionar verificações de conta, alocação de recursos, atribuição de endereço, criação de credenciais e uma mensagem ao cliente. Um servidor virtual aparece sem que um técnico monte um pedido personalizado. Tarefas repetidas tornam-se consistentes o suficiente para serem vendidas a preços baixos de entrada.

Mas a automação não remove decisões; ela as move. A capacidade tem que estar disponível em um hipervisor apropriado. A imagem selecionada tem que inicializar. Um endereço tem que ser atribuído sem colisão ou surpresas de reputação. Regras antifraude têm que distinguir um comprador comum de um uso indevido. Um cliente que digita errado um endereço de e-mail ou perde um fator de autenticação precisa de um caminho de recuperação. O estado de faturamento tem que permanecer alinhado com o estado do serviço para que uma instância paga não seja tratada como expirada.

As páginas públicas da VeryCloud mostram sinais dessa fronteira móvel. O catálogo de VPS oferece links de pedido direto e configurações repetidas. A página de servidor dedicado, capturada na data da evidência, mostrava algumas configurações indisponíveis e uma configuração em estoque. Ela também exibia um preço de zero euro para essa configuração, o que é claramente um motivo para confirmar o pedido real em vez de tratar um cartão renderizado como uma cotação contratual. O estado dinâmico do catálogo pode ser útil; também pode expor dados incompletos ou um erro temporário de publicação.

O contrato antecipa exceções. A VeryCloud reserva-se o direito de recusar pedidos após verificações antifraude, identidade, sanções ou disponibilidade. Ela afirma que atrasos significativos de estoque ou hardware podem levar a substitutos, adiamentos ou reembolsos. As credenciais chegam por e-mail ou área do cliente, e os clientes têm um período limitado para relatar não conformidade. Nada disso é incomum. Significa que o serviço aparentemente de um clique é apoiado por uma fila de trabalho de exceção.

Um comprador empresarial deve testar essa fila antes de depender dela. Como uma implantação falha é identificada? Um ticket criado automaticamente carrega as referências de pagamento e serviço? Quem pode reverter uma suspensão equivocada? Um pedido provisionado manualmente é visível na mesma conta? Os administradores podem exportar uma lista de instâncias, endereços, proprietários, datas de renovação e status de backup? Que trilha de auditoria existe para uma reconstrução ou redefinição de credenciais?

A melhor medida da automação não é a rapidez com que o caso de sucesso termina. É o quão seguramente o serviço retorna a um estado conhecido após uma falha parcial. Um provedor pode automatizar a criação e ainda depender de trabalho manual frágil para cancelamento, migração, revisão de abuso ou recuperação. O registro público da VeryCloud torna a frente da cadeia visível. Um comprador sério precisa de evidências do meio e do fim.

O contrato revela a arquitetura real

Páginas de marketing descrevem componentes. Contratos revelam responsabilidade.

OsTermos de Serviçoda VeryCloud definem a conta do cliente, o conteúdo hospedado e o relacionamento de serviço. Eles dizem que os clientes permanecem responsáveis por credenciais, chaves de API e chaves SSH, com autenticação de dois fatores fortemente recomendada e obrigatória para alguns serviços sensíveis. Suspeitas de comprometimento devem ser relatadas através de um ticket, e o provedor pode suspender uma conta para evitar danos. Isso descreve um limite de identidade no qual ambos os lados têm trabalho a fazer: o provedor opera o sistema de contas, enquanto o cliente governa quem pode usá-lo.

O limite de backup é mais nítido. Os Termos de Venda afirmam que, a menos que um serviço de backup gerenciado seja expressamente adquirido, o cliente é responsável por fazer backup de seus dados. A VeryCloud pode manter backups técnicos para continuidade, mas eles não são prometidos como um serviço de restauração sob demanda. Ao final do contrato, o cliente recebe um período de carência de até sete dias corridos para extrair dados, sujeito a pagamento, após o qual a exclusão pode ocorrer, exceto para registros legalmente retidos. A assistência à migração pode ser orçada separadamente.

Essa linguagem deve mudar o comportamento de compra. Um cliente não pode inferir com segurança que o plano de recuperação de desastres de um provedor inclui cópias recuperáveis de cada VPS não gerenciado. Continuidade de infraestrutura e recuperação de dados do inquilino são coisas diferentes. Energia redundante pode manter um hipervisor funcionando; não protege contra um administrador excluindo um banco de dados. Um provedor pode reconstruir um nó com falha; isso não prova que o estado do aplicativo do cliente pode ser restaurado para o momento necessário.

O SLA tem limites semelhantes. A VeryCloud se compromete com a disponibilidade mensal alvo, define medição e exclusões, e oferece créditos de serviço quando o limite é perdido. As solicitações devem ser feitas por ticket dentro de 30 dias. Os créditos são limitados e são o recurso normal para uma violação de SLA. A responsabilidade agregada do provedor também é limitada pelos termos, enquanto a perda de dados sem um backup gerenciado é excluída.

O ponto não é que esses termos são unicamente restritivos. O ponto é que a arquitetura operacional é dividida. O provedor promete certos resultados de infraestrutura; o cliente retém responsabilidades importantes por conteúdo, administração do sistema, saúde do aplicativo e backup, a menos que compre mais. Um painel dizendo que o servidor está online pode, portanto, coexistir com um erro irrecuperável do cliente. Um número de 99,99% da rede pode coexistir com um serviço de login quebrado. Um ticket de suporte pode ser respondido corretamente com a conclusão de que a falha está fora do escopo incluído.

Para uma empresa, a resposta deve ser uma matriz de responsabilidades vinculada a evidências. Cada serviço precisa de um proprietário para o sistema convidado, aplicativo, dados, identidade, DNS, certificado, monitoramento, backup e restauração. O pedido deve identificar quais opções da VeryCloud alteram essas atribuições. O cliente deve testar uma restauração antes da produção, não após a perda. O que parece um detalhe legal é na verdade o design do sistema escrito em prosa.

AS198825 é a prova pública mais forte

A superfície operacional mais inspecionável da VeryCloud é seu sistema autônomo. Isso importa porque marcas de hospedagem podem ser pouco mais que revendedores. Um ASN visível não prova todas as alegações de serviço, mas dá ao provedor uma identidade de rede pública que outros operadores podem observar.

O objeto RIPE para AS198825 nomeiaVERYCLOUD-SAS, associa-o ao registro de organização da VERYCLOUD SAS e registra status atribuído. Seus campos de política de roteamento nomeiam AS62000 e AS174 para importação e exportação IPv4 e IPv6. Avisualização de prefixos anunciados do RIPEstat, capturada em 15 de julho, mostrou sete rotas visíveis durante todo o intervalo retornado de 1 a 15 de julho: cinco /24 IPv4 e dois /44 IPv6.

O conjunto IPv4 era 82.22.2.0/24, 82.22.7.0/24, 82.22.77.0/24, 82.26.157.0/24 e 151.242.39.0/24. O conjunto IPv6 era 2a0c:b641:af0::/44 e 2a10:4646:2e0::/44. Umavisualização independente do BGP.Toolsmostrou a mesma contagem de cinco e duas origens e descreveu a rede como ativa.

Cada um desses pares de prefixo de origem retornou um resultado RPKI válido no momento da evidência. Para as rotas IPv4, autorizações de origem de rota correspondentes permitiam um /24. Para as rotas IPv6, elas permitiam anúncios mais específicos até /48. Validade significa que o AS de origem observado correspondia a uma autorização. É um sinal de higiene significativo porque as redes que realizam validação de origem de rota podem distinguir esses anúncios de uma origem não autorizada.

Não é um veredito de segurança universal. A validade RPKI não mostra se uma rota é alcançável a partir de todas as redes, se um roteador está configurado corretamente, se o tráfego segue o caminho físico pretendido ou se um aplicativo responde. Uma rota válida ainda pode ser retirada. Uma rota válida pode levar a um servidor com falha. Uma rota vazada pode causar problemas mesmo quando a informação de origem está correta. A conclusão correta é estreita e positiva: as origens observadas da VeryCloud foram autorizadas no momento da captura.

Avisualização de vizinhos do RIPEstattambém torna parte da forma de roteamento visível. Ela mostrou AS174 e AS62000 no lado upstream adjacente, e AS197791 e AS198339 no lado downstream. O BGP.Tools também exibiu AS62000 e AS174 como upstreams. Essa convergência independente apoia a alegação de que a AS198825 não é um registro isolado.

No entanto, a visibilidade de vizinhos não é evidência de circuito. Dois ASNs podem ser alcançados através de instalações, portas ou caminhos físicos que compartilham risco. Um coletor de roteamento não revela capacidade comprometida, obrigações de suporte, proporções de tráfego ou testes de failover. Nem prova a alegação do site de que o tráfego será rerroteado em segundos após uma falha de operadora. Um comprador que precisa de resiliência deve perguntar sobre a topologia em um nível apropriado, separação de domínios de falha e o resultado de um exercício de failover controlado.

O ASN, portanto, faz algo valioso, mas limitado. Ele prova que a VeryCloud participa do roteamento sob seu próprio número e origina um conjunto mensurável de endereços. Dá aos clientes e operadores externos um lugar para inspecionar rotas. Não transforma a identidade de rede em garantia de serviço de ponta a ponta.

Originar endereços não é o mesmo que possuí-los

O site de rede da VeryCloud descreve 1.280 endereços IPv4 em alocação, correspondendo a cinco /24s. Essa aritmética está correta para as rotas originadas pela AS198825. Os registros mostram por que a palavra propriedade seria muito forte.

Quatro dos registros IPv4 descrevem a VeryCloud SAS, mas seu status RIPE éASSIGNED PA, apontam para outro objeto de organização e são mantidos sob um mantenedor terceiro. O espaço agregável do provedor é comumente delegado para uso sem se tornar propriedade portátil do usuário final. O quinto bloco, 151.242.39.0/24, éSUB-ALLOCATED PAe é descrito publicamente como espaço de cliente privado. A AS198825 o origina, mas a própria página de rede da VeryCloud não o apresenta como o próprio pool de endereços de cliente da empresa.

Os registros IPv6 também carregam linhagens diferentes. O registro 2a0c:b641:af0::/44 nomeia a VeryCloud SAS e sua organização RIPE. O registro 2a10:4646:2e0::/44 permanece sob uma organização separada associada ao nome do fundador. Ambos estavam visíveis da AS198825 e ambos tinham autorizações de origem válidas. Uso operacional, atribuição de registro e controle legal são relacionados, mas distintos.

Essa distinção importa durante a migração ou disputa. Um cliente pode receber um endereço que permanece parte da alocação upstream de um fornecedor. Pode funcionar perfeitamente por anos, mas ser difícil de mover. Um cliente que anuncia seu próprio prefixo portátil através da VeryCloud tem uma posição de saída diferente daquele que usa um endereço atribuído pelo provedor. As referências da página de trânsito remoto a IPv4 e IPv6 portáteis devem, portanto, ser resolvidas no pedido: de quem é o prefixo, de quem é o objeto de rota, de quem é a ROA, de quem é o geofeed e o que acontece na rescisão?

A reputação de endereço adiciona outra dimensão. Redes de hospedagem podem herdar históricos de abuso de usuários anteriores de espaço arrendado. Uma rota tecnicamente válida não garante que cada endereço seja aceito por provedores de e-mail, feeds de ameaças ou APIs de terceiros. Os clientes devem testar os endereços atribuídos reais para sua carga de trabalho, em vez de inferir reputação a partir do ASN como um todo.

A VeryCloud merece crédito por publicar sua lista de prefixos e looking glass. Isso torna possíveis verificações externas. A interpretação mais madura dessas ferramentas não é que a empresa possui um bloco fixo de propriedade digital. É que ela coordena um conjunto em camadas de direitos de roteamento, atribuições e rotas de cliente. A garantia vem de manter essas camadas documentadas, atuais e reversíveis.

DNS mostra dois modelos de entrega

O registro de domínio público conecta a cronologia da marca à sua rede. Os registros AFNIC mostram queverycloud.frfoi criado em 8 de fevereiro de 2023, antes da SAS, e permaneceu ativo na data da evidência. Seus servidores de nomes eram operados pela Cloudflare. O DNS público para o site principal,www, o gerenciador de contas, documentação e nomes de status retornaram endereços de edge da Cloudflare em IPv4 e IPv6.

Isso significa que um leitor carregando o site não testa diretamente a AS198825. A Cloudflare encerra o edge público e pode absorver, armazenar em cache ou proxy o tráfego antes que ele alcance uma origem. O arranjo pode melhorar a resiliência e a segurança, mas separa a acessibilidade da marca da visibilidade de rota do próprio provedor. Ver o site através da Cloudflare durante um incidente na AS198825 não provaria que os servidores do cliente estavam saudáveis. Não conseguir alcançar uma página na Cloudflare, por si só, não provaria que o sistema autônomo estava inativo.

Outros nomes conectam mais diretamente.lg.verycloud.frelg.as198825.netresolveram para 82.26.157.253, dentro de um dos /24s observados da AS198825. O trocador de correio paraverycloud.freramail.as198825.net, que resolveu para 82.26.157.251 no mesmo /24. Esses links fornecem evidências práticas de que pelo menos as superfícies de looking glass e correio tocam o espaço de endereço originado pela rede.

A distinção é analiticamente útil. O patrimônio público combina um edge externo com endpoints de rede diretos. Isso é híbrido normal, mas o monitoramento deve refleti-lo. Uma verificação deve observar o site como um usuário o vê através da Cloudflare. Outra deve testar as dependências do lado da origem. Verificações separadas devem cobrir a área de conta, DNS, correio, looking glass e serviços do cliente. Uma única página inicial verde não pode representar todos esses caminhos.

Nenhum registro DS foi retornado paraverycloud.frno instantâneo de 15 de julho. Isso é apenas uma observação de delegação. Não significa que o DNS não é autenticado em todas as camadas, nem nega os outros controles da Cloudflare. Ele identifica uma questão específica: se o DNSSEC está intencionalmente não implantado no pai, está sendo introduzido ou é considerado desnecessário para este domínio. Para uma empresa que vende serviços de rede, uma decisão documentada é mais reconfortante do que uma suposição.

O DNS também coloca um limite nas alegações de localidade. Um endereço de edge pertence à rede de entrega, não necessariamente ao país de origem. Um endereço direto revela a rota, não o servidor físico ou banco de dados por trás dele. Os compradores devem usar o DNS como evidência de dependências e pontos de controle, nunca como um mapa completo de localização de dados.

Localização francesa é significativa, mas precisa de um substantivo

A VeryCloud diz repetidamente que os dados do cliente são hospedados exclusivamente na França, na Telehouse 3 em Magny-les-Hameaux. O contrato é mais cuidadoso: diz que os dados são hospedados na França por padrão e fornece transferências reguladas para fora da União Europeia quando aplicável. Essas declarações podem coexistir se se referirem a diferentes categorias de dados, mas as categorias precisam de nomes.

Os dados da carga de trabalho do cliente em um VPS são uma categoria. Identidade da conta, faturas, tokens de pagamento, mensagens de suporte, relatórios de abuso, telemetria de segurança, eventos de monitoramento e backups do provedor são outras. Um host de computação francês pode usar um processador de pagamento externo. Uma plataforma de tickets pode processar metadados de suporte em outro lugar. Um sistema antifraude pode avaliar informações da conta através de outro subprocessador. Um serviço de monitoramento pode reter endereços IP e carimbos de data/hora de eventos fora do país do servidor.

Os termos da VeryCloud reconhecem a divisão. Para dados do cliente processados através de serviços de hospedagem, o cliente atua como controlador e a VeryCloud como processador. Para dados de relacionamento com o cliente, como registro, faturamento, suporte e registros de segurança, a VeryCloud atua como controladora. O provedor diz que um acordo de processamento de dados está disponível e que sua lista de subprocessadores está disponível mediante solicitação. Ele também afirma que os clientes receberão informações sobre mudanças sob o DPA.

Esse quadro é mais útil do que uma bandeira em um cartão de produto, porque pergunta quem pode agir sobre cada conjunto de dados. Um comprador deve solicitar o DPA, a lista atual de subprocessadores, locais, mecanismo de transferência, períodos de retenção, processo de exclusão e rota de notificação de violação. Deve perguntar se os backups gerenciados permanecem na França, se os logs do plano de controle seguem a mesma regra e se o pessoal de suporte fora da França pode acessar os sistemas do cliente.

Apágina da Telehouse para Magny-Les-Hameauxconfirma independentemente uma instalação substancial com energia redundante, geradores, arranjos UPS, acesso protegido e certificações de gerenciamento de nível de instalação. Isso apoia a alegação da VeryCloud de que o local nomeado existe e tem controles físicos sérios.

Não certifica a VeryCloud SAS. Um inquilino herda benefícios do edifício, mas ainda precisa configurar seus racks, credenciais, rede, backups e procedimentos. Guardas da instalação não impedem um administrador do cliente de excluir um disco virtual. Energia redundante não prova que a sequência de recuperação de um provedor foi testada. Uma certificação de instalação pode cobrir o sistema de gerenciamento do operador sem cobrir todos os processos do inquilino ou carga de trabalho do cliente.

A soberania de dados não é alcançada dizendo França com frequência suficiente. É alcançada mantendo direitos de decisão, acesso, cópias e saídas atribuíveis. A localização da VeryCloud é uma âncora credível e comercialmente relevante. O trabalho restante é anexar cada substantivo importante a ela: dados de produção, backup, log, ticket, conta, chave e imagem de recuperação.

A disponibilidade precisa de uma memória pública

A VeryCloud anuncia 99,99% de disponibilidade para serviços VPS e dedicados. Expresso em um mês de 30 dias, esse alvo permite apenas alguns minutos de indisponibilidade contada. Mas o contrato, não a decimal, determina o que é contado.

Os termos excluem ou tratam separadamente manutenção planejada, falhas causadas pelo cliente e falhas fora da responsabilidade do provedor. Eles definem medição e créditos de serviço, e exigem um ticket dentro de 30 dias de um incidente. Isso significa que os clientes precisam de seu próprio monitoramento. Sem um registro externo com carimbo de data/hora, pode ser difícil estabelecer quando um serviço ficou indisponível, qual camada falhou e se o evento atendeu à definição contratual.

A VeryCloud mantém umapágina de status pública, que é uma superfície de responsabilidade positiva. Na data da evidência, a página ao vivo expunha um monitor da VeryCloud através do HetrixTools. Um instantâneo de pesquisa do mesmo período ainda descrevia uma página mais antiga do Uptime Kuma com uma lista de componentes mais longa. Essa aparente transição pode simplesmente refletir um redesenho do monitoramento. Também mostra por que uma página de status deve preservar a continuidade quando as ferramentas mudam.

Um serviço de status público útil faz mais do que exibir verde ou vermelho. Ele define componentes, registra horários de início e recuperação de incidentes, distingue investigação de mitigação e preserva resumos pós-incidente. Os clientes devem poder se inscrever sem entrar em um chat da comunidade. A manutenção deve permanecer visível após seu término. Um provedor pode ocultar detalhes sensíveis enquanto ainda explica o serviço afetado, a causa geral, o caminho de restauração e o trabalho de prevenção.

Os dados de rota pública podem complementar esse histórico, mas não substituí-lo. O RIPEstat mostrou todos os sete prefixos visíveis através do intervalo de duas semanas retornado. Isso apoia a continuidade da rota no nível do coletor. Não diz nada sobre falhas de hipervisor, latência de armazenamento, acesso à conta, tickets ou a instância de um único cliente. Da mesma forma, uma página inicial verde na Cloudflare não prova que o estate de VPS está saudável.

A hierarquia de evidências deve, portanto, ser em camadas. Monitores de roteamento global observam prefixos. Sondas externas observam portas e transações. O monitoramento de hipervisor e armazenamento observa a infraestrutura. As verificações de aplicativos observam a tarefa do usuário. Os tickets registram impacto e propriedade. Os testes de restauração provam a capacidade de recuperação. As páginas de status comunicam uma versão selecionada desses fatos.

A VeryCloud publica o início dessa hierarquia: rotas, um looking glass e um monitor público. Antes de mover uma carga de trabalho crítica, um comprador deve pedir o resto de forma apropriadamente confidencial: cálculos de disponibilidade, histórico de manutenção, exemplo de comunicação de incidente, sucesso de backup, testes de restauração e tempos de escalação. O objetivo não é pegar o provedor em um erro decimal. É saber se ambos os lados reconhecerão o mesmo incidente.

Avaliações de clientes mostram o problema antes e depois

A página do Trustpilot da VeryCloud é maior do que a entrada esparsa do diretório pode sugerir. Em 15 de julho, mostrava 123 avaliações, pontuação 4,4, 82% de cinco estrelas e 11% de uma estrela, com 56 avaliações nos últimos 12 meses. O perfil foi reivindicado em agosto de 2023, e o Trustpilot disse que a empresa convida os clientes a avaliar. Também disse que a empresa não havia respondido a avaliações negativas.

Esses números são um sinal de mercado, não uma auditoria de desempenho. O Trustpilot diz explicitamente que não verifica as opiniões dos revisores, embora use triagem e possa verificar se uma interação ocorreu. Convites podem mudar quem responde. Uma distribuição de estrelas não controla produto, carga de trabalho, habilidade do cliente, idade do serviço ou gravidade do incidente.

As avaliações positivas visíveis, no entanto, identificam temas úteis a testar. Os revisores descreveram provisionamento rápido, documentação acessível, uma superfície de gerenciamento utilizável e suporte responsivo. Essas observações estão alinhadas com as alegações de automação e suporte da VeryCloud. Sugerem que velocidade e ajuda humana fazem parte do valor percebido do provedor, não apenas especificações de processador.

As avaliações negativas visíveis na página capturada estavam concentradas em 2023 e alegavam serviços excluídos e problemas de reembolso. Uma reclamação visível foi marcada como verificada. Essas são alegações sérias de usuários individuais, não conclusões estabelecidas. Sua data é igualmente importante: dizem respeito ao projeto inicial, dois anos antes da criação da SAS. Uma avaliação justa não as apaga nem as atribui mecanicamente à empresa posterior.

A pergunta certa é o que mudou. A transferência de 2025 trouxe controles de faturamento mais claros, avisos de exclusão, registros de conta e rotas de recurso? Os termos atuais e a área do cliente impedem o padrão de falha alegado nas avaliações mais antigas? O provedor começou a preservar evidências de estado de serviço e pagamento bem o suficiente para resolver disputas? Ele responde privadamente através de tickets enquanto deixa avaliações públicas sem resposta, ou o feedback negativo está sendo ignorado?

O volume positivo recente pode indicar melhora, mas uma pontuação não pode responder a essas perguntas processuais. A empresa poderia fortalecer a garantia respondendo a avaliações negativas substantivas sem divulgar dados do cliente, publicando o ciclo de vida para suspensão e exclusão, e registrando como as disputas de estado de pagamento são escaladas. Os clientes também podem se proteger mantendo faturas, avisos de renovação, exportações de tickets, identificadores de serviço e backups independentes.

As avaliações são mais úteis quando produzem um teste. O provisionamento rápido pode ser testado com uma instância de baixo risco. A qualidade do suporte pode ser testada com uma pergunta tecnicamente específica de pré-venda. O cancelamento pode ser testado antes de uma renovação crítica. A extração de dados pode ser ensaiada. Reclamações mais antigas sobre exclusão devem levar a um exercício de saída, não a um veredito baseado em um punhado de postagens.

A mão de obra de suporte é o limite de capacidade oculto

A VeryCloud promete suporte técnico 24 horas por dia, 7 dias por semana através de tickets na área do cliente, com e-mail ou chat em alguns casos. Sua página de servidor dedicado também promove suporte em francês através de tickets e Discord. O contrato restringe o trabalho incluído à infraestrutura do provedor, hardware, rede, disponibilidade do servidor e painéis de controle.

Este é um limite sensato. Também significa que um pequeno número de pessoas qualificadas pode estar no ponto onde muitas linhas de produto convergem. Um ticket sobre um aplicativo inacessível pode exigir conhecimento do estado de faturamento, saúde do hipervisor, atribuição de endereço, visibilidade de rota, filtragem, configuração do convidado e histórico do cliente antes que o respondedor possa localizar a responsabilidade. A automação pode abrir e encaminhar o caso, mas o diagnóstico é trabalho humano.

Acesso 24 horas não é o mesmo que profundidade 24 horas. O registro público não mostra o número atual de funcionários de suporte, padrão de turnos, cobertura de idiomas, distribuição de primeira resposta ou escalação. Não diz se a pessoa que responde a uma mensagem do Discord pode fazer uma alteração no roteador, autorizar um reembolso ou substituir hardware. Não divulga como incidentes simultâneos são priorizados.

Para clientes comuns, o Discord pode ser útil. Membros da comunidade respondem a perguntas simples, e uma equipe visível pode fazer um pequeno provedor parecer acessível. Para decisões de segurança, faturamento e estado de serviço, o ticket deve permanecer autoritativo. Mensagens de chat podem ser editadas, perdidas no volume ou vistas pelo público errado. Um ticket pode transportar identidade da conta, carimbos de data/hora, anexos e status de escalação em um registro controlado.

A mão de obra local também importa na instalação. Um respondedor remoto pode inspecionar telemetria, mas hardware com falha, cabeamento e alimentação podem exigir mãos em Magny-les-Hameaux. A divisão entre funcionários da VeryCloud, contratados e pessoal da Telehouse determina quem pode entrar no espaço, substituir um componente e confirmar a recuperação. Uma promessa de suporte humano deve conectar esses papéis em vez de deixar o cliente coordená-los.

Antes de uma implantação crítica, os compradores devem fazer perguntas operacionais que revelem capacidade sem exigir informações pessoais: Qual é o objetivo de resposta por gravidade? Quem pode declarar um incidente grave? Existe um engenheiro de rede de plantão? Como as intervenções de hardware são solicitadas? O suporte retém um histórico completo de tickets? Um cliente pode nomear vários contatos autorizados? Existe um caminho de emergência se o portal da conta estiver indisponível?

As respostas importam porque a VeryCloud vende automação e intervenção. Servidores podem ser criados automaticamente, mas as exceções se acumulam em torno de faturamento, abuso, migração, roteamento e recuperação. O produto é confiável apenas se a fila humana tiver autoridade e tempo suficientes para resolver essas exceções.

Um comprador deve precificar a saída, não apenas a entrada

A VeryCloud compete com pacotes de recursos atraentes e uma história de hospedagem francesa. O preço mensal visível é apenas uma parte da decisão comercial. O custo real inclui administração, backup, monitoramento, portabilidade de endereço, trabalho de incidente e migração.

Um VPS não gerenciado transfere trabalho substancial para o cliente. Alguém deve corrigir o sistema operacional, proteger SSH, monitorar espaço em disco, renovar certificados de aplicativos, testar backups, responder a relatórios de abuso e diagnosticar falhas de software. A VeryCloud pode fornecer uma máquina virtual saudável enquanto o serviço do cliente permanece vulnerável através de administração negligenciada. Uma conta de servidor baixa pode ser racional se o comprador já tiver essa capacidade. É enganosa se a mão de obra ausente for tratada como gratuita.

A economia de backup é especialmente fácil de subestimar. O contrato exclui a restauração comum sem uma opção gerenciada, e a assistência de exportação no final do contrato pode ser cobrada. Um comprador deve precificar cópias independentes, armazenamento, transferência, retenção e teste de restauração. Deve saber quanto tempo leva uma exportação completa e se o serviço permanece gravável durante a migração. Sete dias de carência pós-contrato podem ser suficientes para um cliente preparado e perigosamente curtos para um não testado.

O endereçamento também afeta o custo de saída. Cargas de trabalho vinculadas a endereços IPv4 atribuídos pelo provedor podem precisar de alterações de DNS, atualizações de listas de permissão, aquecimento de reputação e comunicação com o cliente quando movidas. Prefixos portáteis e sessões BGP podem reduzir algumas dependências, mas adicionam conhecimento de roteamento, trabalho de registro e obrigações de segurança. O trânsito remoto pode preservar endereços através de uma mudança de hospedagem apenas se o cliente realmente controlar os recursos relevantes e o caminho de substituição estiver pronto.

A proposta de localização de dados francesa também tem um preço. Pode simplificar a aquisição para clientes que buscam uma instalação doméstica e foro legal familiar. Não elimina a necessidade de avaliar subprocessadores ou construir recuperação fora de um domínio de falha. Um cliente que requer resiliência geográfica pode precisar de um segundo local francês, outra região europeia ou um local de backup independente, dependendo da política e do risco.

Finalmente, os recursos contratuais têm limites econômicos. Os créditos SLA compensam parte de uma taxa mensal; raramente correspondem ao custo comercial de uma interrupção. Limites de responsabilidade e exclusões significam que o cliente permanece o segurador de muitas consequências. A criticidade deve, portanto, determinar a arquitetura. Um servidor de hobby pode aceitar um arranjo simples. Um sistema de receita pode precisar de DNS multi-provedor, dados replicados, configuração portátil, monitoramento externo e um runbook testado.

A VeryCloud ainda pode ser a escolha econômica após essas adições. O ponto é comparar os custos operacionais completos. O preço de entrada responde quanto custa começar. O preço de garantia responde quanto custa permanecer recuperável e sair.

Como seria uma prova mais forte

O registro público já suporta várias conclusões com confiança. VERYCLOUD é uma SAS francesa ativa. Ela apresenta um catálogo de serviços coerente e termos legais atuais. AS198825 está ativo e visível com origens IPv4 e IPv6. As autorizações de origem de rota eram válidas na data da evidência. O DNS público conecta a marca a serviços na Cloudflare e endereços diretos no espaço AS198825. A instalação Telehouse nomeada é real. Existe um registro não trivial de avaliações de clientes.

O próximo nível de garantia não exige que a empresa publique diagramas sensíveis. Exige evidências que possam ser compartilhadas com um comprador sob termos apropriados.

Para identidade e continuidade, isso significa um relato claro da transferência de 2025, a entidade contratante nas faturas e seguro e situação financeira atuais, quando relevante. Para serviços, significa uma descrição de pedido definitiva que substitui cartões de catálogo transitórios. Para resiliência de rede, significa prefixos pretendidos, ROAs atuais, propriedade de dependência, domínios de falha física e resultados recentes de failover.

Para dados, o comprador precisa do DPA, lista de subprocessadores, locais por serviço, modelo de acesso, criptografia e propriedade de chaves, retenção, exclusão e design de backup. Para disponibilidade, precisa do cálculo do SLA, desempenho medido recente, histórico de manutenção e um exemplo de comunicação de incidente. Para recuperação, precisa de evidências de que os backups são monitorados e as restaurações foram concluídas dentro do objetivo exigido.

Para suporte, as medidas úteis não são slogans, mas distribuições: primeira resposta por gravidade, tempo até a propriedade técnica, tempo até a restauração, casos reabertos e escalações não resolvidas. Um pequeno provedor não precisa operar um vasto call center. Precisa mostrar que o trabalho urgente chega a alguém autorizado a agir.

O cliente tem obrigações recíprocas. Deve manter contatos precisos, proteger sua conta, corrigir o que administra, classificar seus dados, manter material de recuperação independente, monitorar transações e enviar tickets oportunos. O provedor não pode restaurar uma carga de trabalho que nunca foi contratada para fazer backup. O cliente não pode diagnosticar uma rede que não pode observar. A garantia é um conjunto de responsabilidades unidas, não um distintivo comprado no checkout.

As evidências públicas da VeryCloud são mais fortes onde as operações da internet são naturalmente públicas: registro ASN, origens de rota e DNS. São mais fracas onde os resultados do serviço são privados: tratamento de incidentes, recuperação de armazenamento, capacidade de suporte e configuração do cliente. Esse padrão não é incomum. É exatamente por isso que um comprador deve usar as fortes evidências públicas para fazer melhores perguntas privadas, em vez de tratar a ausência de detalhes públicos como prova de falha ou permissão para assumir sucesso.

Um nome roteado, não um veredito final

VERYCLOUD SAS tem mais por trás do que o rótulo fino do diretório inicialmente revela. Há uma empresa francesa ativa, uma transição publicada de um projeto anterior, um contrato definido, uma alegação de instalação real e uma rede que pode ser observada externamente. A AS198825 origina cinco prefixos IPv4 e dois IPv6, com autorizações de origem de rota válidas na data da evidência. Isso é prova substancial para um jovem provedor.

É prova de identidade e participação em rede. Não é prova de que toda carga de trabalho permanecerá disponível, todo byte permanecerá dentro de uma jurisdição, todo backup será restaurável ou todo ticket urgente chegará ao engenheiro certo. As páginas de produto público às vezes comprimem distinções que o contrato restaura: continuidade de infraestrutura versus recuperação do cliente, hospedagem francesa versus a cadeia mais ampla de processadores, acesso 24/7 versus escopo administrativo incluído e uma disponibilidade alvo versus o recurso real do cliente.

O registro de mercado misto reforça o ponto. Revisores recentes frequentemente elogiam velocidade e suporte, enquanto reclamações visíveis do projeto anterior levantam questões sobre exclusão e estado de pagamento. Nenhum lado deve ser transformado em uma história universal. Os controles atuais do provedor devem ser testados contra os modos de falha que o registro mais antigo expõe.

Para um cliente em potencial, a sequência sensata é direta. Verifique a SAS no pedido. Identifique o limite exato do serviço. Confirme o modelo de endereço e roteamento. Solicite o DPA e a lista de subprocessadores. Decida quem possui cada backup e restauração. Monitore externamente. Coloque segurança, faturamento e comunicação de incidentes em tickets. Ensaie a migração antes que seja urgente.

Essa sequência não diminui o valor da rede da VeryCloud. Ela coloca a rede em seu devido lugar. Um ASN visível é uma base melhor do que uma identidade de revendedor anônimo. RPKI válido é melhor do que origens ambíguas. Um looking glass público é melhor do que pedir aos clientes que confiem em um diagrama. Esses são sinais de um operador disposto a expor parte de seu trabalho ao escrutínio.

A garantia operacional começa depois que esses sinais foram lidos corretamente. Ela emerge quando identidade legal, rotas, contratos, controles de dados, registros de status, testes de recuperação e autoridade humana apontam para o mesmo serviço. VERYCLOUD SAS já pode ser identificada e observada. A questão restante para cada comprador é se a evidência privada por trás de um pedido específico é tão coerente quanto o nome de rede público.