Resumen
- VERYCLOUD SAS ya no es solo un nombre de alojamiento sugerente. Los registros públicos franceses identifican una empresa parisina activa creada en abril de 2025, el proveedor describe una transferencia desde un proyecto anterior, y los registros RIPE conectan el nombre con AS198825, que ya operaba desde 2023.
- La huella de red es inusualmente inspeccionable: cinco prefijos IPv4 y dos IPv6 eran visibles desde AS198825 en la fecha de evidencia, cada origen observado tenía RPKI válido, y los registros de enrutamiento público mostraban dos vecinos del lado ascendente y dos del lado descendente. Eso demuestra un rol de enrutamiento activo, no la propiedad de cada dirección, diversidad de rutas físicas o disponibilidad de aplicaciones.
- El límite del servicio importa más que la cifra de disponibilidad destacada. Los términos de VeryCloud ponen las copias de seguridad ordinarias, la administración del sistema operativo, el mantenimiento de aplicaciones y gran parte del trabajo de recuperación en manos del cliente a menos que se compren servicios adicionales. Sus afirmaciones sobre la ubicación en Francia son significativas, pero los subprocesadores, los sistemas de control, los registros y las transferencias protegidas aún requieren un mapa de datos específico del servicio.
- El soporte es parte del producto, no una promesa decorativa. Los términos públicos ofrecen tickets las 24 horas para la infraestructura de VeryCloud, mientras que el historial de reseñas contiene tanto elogios por la configuración rápida como quejas más antiguas sobre la eliminación de servicios. Los compradores necesitan evidencia de tickets, pruebas de restauración y una propiedad de escalamiento clara antes de tratar un nombre en la nube enrutado como una garantía operativa.
Empiece con el desfase de fechas
Los proveedores de nube a menudo se presentan como si la marca, la empresa y la infraestructura aparecieran al mismo tiempo. La cronología pública de VeryCloud es más complicada y, por ser más complicada, más útil.
Elregistro público de empresas francésregistra una empresa activa llamada VERYCLOUD, de forma jurídica SAS, creada el 18 de abril de 2025. Indica la sede social registrada en 60 rue Francois Ier en París, el SIREN como 943 573 584, el SIRET de la sede como 943 573 584 00019 y la actividad principal declarada como telecomunicaciones inalámbricas. Estos detalles establecen una contraparte legal actual. No muestran una empresa de nube con décadas de antigüedad. Muestran una joven empresa francesa con un registro legible.
La cronología de la infraestructura comienza antes. Lapropia historia de VeryClouddice que el proyecto comenzó en 2023, obtuvo AS198825 y un IPv4 /24 en marzo de ese año, fundó la SAS en abril de 2025 y transfirió sus actividades a la empresa el 26 de abril de 2025. Elregistro de AS198825 de RIPEdata de forma independiente el objeto de sistema autónomo del 19 de abril de 2023. El objeto de organización de RIPE paraVERYCLOUD SAS, por el contrario, se creó el 29 de abril de 2025. Las fechas coinciden con la historia general del proveedor: primero la red, luego la empresa.
Eso no es inherentemente alarmante. Los proyectos se incorporan regularmente después de una fase experimental o asociativa. Sin embargo, es un punto de diligencia material. Un cliente debería preguntar qué activos, contratos, licencias, compromisos de soporte, responsabilidades, registros de monitoreo y datos de clientes se transfirieron a la SAS. El sitio web dice que las actividades se transfirieron. Las fuentes públicas consideradas aquí no incluyen un acuerdo de transferencia o un aviso al cliente que explique su alcance.
La cronología también cambia cómo se debe leer la evidencia de mercado más antigua. Una reseña de 2023 describe el proyecto anterior, no un servicio entregado por una empresa que aún no existía. Puede iluminar la historia operativa de la marca, pero no puede establecer automáticamente el rendimiento de la SAS actual. Por el contrario, la SAS no debería reclamar un registro corporativo más largo solo porque el dominio y el ASN son más antiguos. La formulación honesta es que una empresa francesa de dos años de antigüedad continúa un proyecto de alojamiento y una identidad de red que comenzaron en 2023.
Elperfil del directorio de BTWes por lo tanto un puntero inicial más que una identidad completa. Identifica un operador de infraestructura de red privada, pero el registro de empresas, el sitio web y los registros de RIPE proporcionan las conexiones decisivas: nombre legal, lugar, fechas y número de red. Para un comprador, esas conexiones convierten una marca de nube genérica en una contraparte atribuible. También exponen la primera pregunta sin respuesta: ¿qué continuó exactamente a través del límite de 2025?
El catálogo es amplio, pero la amplitud no es integración
La oferta pública de VeryCloud abarca varios modelos técnicos y comerciales. Sus términos nombran servidores virtuales KVM, servidores dedicados de metal desnudo, alojamiento web compartido, colocación, servidores de juego preconfigurados y servicios de red. El sitio web añade tránsito IP remoto y protección anti-DDoS. Un comprador puede encontrarse, por tanto, con la misma marca como inquilino de una máquina virtual, administrador de un servidor físico, cliente que coloca hardware en una instalación u operador de red que recibe rutas a través de un túnel.
No son variaciones menores de un producto. Asignan el control de manera diferente.
En un VPS, VeryCloud controla el hardware subyacente, el hipervisor y la red del proveedor; el cliente normalmente controla el sistema operativo invitado, las credenciales, las aplicaciones y los datos. En un servidor dedicado, el cliente obtiene una máquina completa y acceso de gestión de nivel inferior, pero aún depende del proveedor para la energía, la intervención física y la conectividad externa. En la colocación, el cliente puede ser propietario del servidor mientras depende de VeryCloud y de la instalación para el acceso al rack, la energía y las conexiones cruzadas.
El tránsito remoto va más allá: el equipo del cliente puede permanecer en otro lugar mientras las rutas y el tráfico filtrado llegan a través de túneles GRE, VXLAN o EoIP.
Lapágina de tránsito remotohace explícito este último modelo. Anuncia sesiones BGP IPv4 e IPv6, tablas de enrutamiento predeterminadas o completas, límites de prefijos seleccionables y contacto del equipo después de validar un pedido. La red no es solo un ingrediente oculto detrás del alojamiento web. Es en sí misma un límite de servicio vendible.
Esa amplitud crea dos trampas. La primera es asumir que una marca común implica un nivel de servicio común. El contrato de VeryCloud establece un objetivo de disponibilidad mensual del 99.99% para VPS y servidores dedicados, pero del 99.9% para alojamiento compartido. Un túnel, un servidor físico y una cuenta compartida pueden tener también diferentes acuerdos de mantenimiento, capacidad, copia de seguridad y respuesta. El formulario de pedido y las condiciones especiales importan porque la página de inicio no puede resolver cada variación.
La segunda trampa es asumir que una infraestructura común crea un único punto de responsabilidad para todo el sistema del cliente. LosTérminos de Ventade VeryCloud dicen que el soporte incluido cubre la infraestructura y los servicios del proveedor: red, hardware, disponibilidad del servidor y paneles de control. A menos que se compre un servicio gestionado, excluye la administración del sistema operativo, el mantenimiento de las aplicaciones del cliente, la depuración de código, la optimización y la recuperación de datos del cliente. Una aplicación web puede no estar disponible mientras el servidor, la red y el panel de control permanecen dentro del contrato.
Esta es la diferencia entre un catálogo de servicios y un modelo operativo integrado. El catálogo dice lo que se puede pedir. El modelo operativo dice quién vigila cada capa, quién diagnostica una falla entre capas y quién puede restaurarla. Los compradores deberían mapear esas responsabilidades antes de comparar cifras de procesador, memoria o ancho de banda. Un servidor barato puede convertirse en una ambigüedad costosa cuando una falla de la aplicación cruza el límite entre la infraestructura del proveedor y la administración del cliente.
La automatización acelera el caso ordinario
El atractivo de un proveedor de nube pequeño suele ser la inmediatez. Seleccione un plan, pague, reciba credenciales y comience. El contrato de VeryCloud distingue los servicios automatizados como VPS y alojamiento compartido, que dice que se despliegan en minutos después del pago exitoso, de las opciones de hardware dedicado y colocación que pueden requerir aprovisionamiento manual. Su cuenta contiene suscripciones, facturación y soporte. Su documentación pública proporciona guías de autoservicio. Juntas, estas superficies forman una cadena de automatización compacta.
En el caso ordinario, esta cadena elimina trabajo. La confirmación del pago puede desencadenar comprobaciones de cuenta, asignación de recursos, asignación de direcciones, creación de credenciales y un mensaje al cliente. Un servidor virtual aparece sin que un técnico ensamble un pedido personalizado. Las tareas repetitivas se vuelven lo suficientemente consistentes como para venderse a precios de entrada bajos.
Pero la automatización no elimina las decisiones; las traslada. La capacidad tiene que estar disponible en un hipervisor adecuado. La imagen seleccionada tiene que arrancar. Una dirección tiene que asignarse sin colisiones ni sorpresas de reputación. Las reglas antifraude tienen que distinguir a un comprador ordinario de un uso indebido. Un cliente que escribe mal una dirección de correo electrónico o pierde un factor de autenticación necesita una ruta de recuperación. El estado de facturación tiene que permanecer alineado con el estado del servicio para que una instancia pagada no sea tratada como vencida.
Las páginas públicas de VeryCloud muestran signos de este límite móvil. El catálogo de VPS ofrece enlaces de pedido directo y configuraciones repetidas. La página de servidor dedicado, capturada en la fecha de evidencia, mostraba algunas configuraciones no disponibles y una configuración en stock. También mostraba un precio de cero euros para esa configuración, que es claramente una razón para confirmar el pedido real en lugar de tratar una tarjeta renderizada como una cotización contractual. El estado dinámico del catálogo puede ser útil; también puede exponer datos incompletos o un error de publicación temporal.
El contrato prevé excepciones. VeryCloud se reserva la capacidad de rechazar pedidos después de comprobaciones antifraude, identidad, sanciones o disponibilidad. Dice que retrasos significativos en stock o hardware pueden llevar a un sustituto, aplazamiento o reembolso. Las credenciales llegan por correo electrónico o en el área de cliente, y los clientes tienen un período limitado para informar de falta de conformidad. Nada de esto es inusual. Significa que el servicio aparentemente de un clic está respaldado por una cola de trabajo de excepción.
Un comprador empresarial debería probar esa cola antes de depender de ella. ¿Cómo se identifica un despliegue fallido? ¿Un ticket creado automáticamente lleva las referencias de pago y servicio? ¿Quién puede revertir una suspensión errónea? ¿Un pedido aprovisionado manualmente es visible en la misma cuenta? ¿Pueden los administradores exportar una lista de instancias, direcciones, propietarios, fechas de renovación y estado de copia de seguridad? ¿Qué rastro de auditoría existe para una reconstrucción o restablecimiento de credenciales?
La mejor medida de automatización no es lo rápido que termina el caso exitoso. Es lo seguro que el servicio regresa a un estado conocido después de una falla parcial. Un proveedor puede automatizar la creación y aún así depender de un trabajo manual frágil para cancelación, migración, revisión de abuso o recuperación. El registro público de VeryCloud hace visible el frente de la cadena. Un comprador serio necesita evidencia del medio y del final.
El contrato revela la arquitectura real
Las páginas de marketing describen componentes. Los contratos revelan responsabilidad.
LosTérminos de Serviciode VeryCloud definen la cuenta del cliente, el contenido alojado y la relación de servicio. Dicen que los clientes siguen siendo responsables de las credenciales, claves API y claves SSH, con autenticación de dos factores fuertemente recomendada y obligatoria para algunos servicios sensibles. Las sospechas de compromiso deben informarse a través de un ticket, y el proveedor puede suspender una cuenta para evitar daños. Esto describe un límite de identidad en el que ambas partes tienen trabajo que hacer: el proveedor ejecuta el sistema de cuentas, mientras que el cliente gobierna quién puede usarlo.
El límite de copias de seguridad es más marcado. Los Términos de Venta establecen que, a menos que se compre expresamente un servicio de copia de seguridad gestionado, el cliente es responsable de hacer una copia de seguridad de sus datos. VeryCloud puede mantener copias de seguridad técnicas para la continuidad, pero no se prometen como un servicio de restauración bajo demanda. Al final del contrato, el cliente recibe un período de gracia de hasta siete días calendario para extraer datos, sujeto a pago, después del cual puede ocurrir la eliminación, excepto para los registros retenidos legalmente.
La asistencia para la migración se puede cotizar por separado.
Ese lenguaje debería cambiar el comportamiento de compra. Un cliente no puede inferir de forma segura que el plan de recuperación ante desastres de un proveedor incluye copias recuperables de cada VPS no gestionado. La continuidad de la infraestructura y la recuperación de datos del inquilino son cosas diferentes. La energía redundante puede mantener un hipervisor en funcionamiento; no protege contra un administrador que elimina una base de datos. Un proveedor puede reconstruir un nodo fallido; eso no demuestra que el estado de la aplicación de un cliente se pueda restaurar al momento requerido.
El SLA tiene límites similares. VeryCloud se compromete a una disponibilidad mensual objetivo, define medición y exclusiones, y ofrece créditos de servicio cuando no se alcanza el umbral. Las solicitudes deben realizarse mediante ticket dentro de los 30 días. Los créditos están limitados y son el remedio normal por incumplimiento del SLA. La responsabilidad agregada del proveedor también está limitada según los términos, mientras que la pérdida de datos sin una copia de seguridad gestionada está excluida.
El punto no es que estos términos sean únicamente restrictivos. El punto es que la arquitectura operativa está dividida. El proveedor promete ciertos resultados de infraestructura; el cliente retiene responsabilidades importantes sobre el contenido, la administración del sistema, la salud de la aplicación y la copia de seguridad a menos que compre más. Un panel que dice que el servidor está en línea puede, por lo tanto, coexistir con un error del cliente irrecuperable. Una cifra de red del 99.99% puede coexistir con un servicio de inicio de sesión roto.
Un ticket de soporte puede responderse correctamente con la conclusión de que la falla está fuera del alcance incluido.
Para una empresa, la respuesta debería ser una matriz de responsabilidades vinculada a la evidencia. Cada servicio necesita un propietario para el sistema invitado, la aplicación, los datos, la identidad, el DNS, el certificado, la monitorización, la copia de seguridad y la restauración. El pedido debería identificar qué opciones de VeryCloud cambian esas asignaciones. El cliente debería probar una restauración antes de la producción, no después de la pérdida. Lo que parece un detalle legal es en realidad el diseño del sistema escrito en prosa.
AS198825 es la prueba pública más sólida
La superficie operativa más inspeccionable de VeryCloud es su sistema autónomo. Eso importa porque las marcas de alojamiento pueden ser poco más que revendedores. Un ASN visible no prueba cada afirmación del servicio, pero le da al proveedor una identidad de red pública que otros operadores pueden observar.
El objeto RIPE para AS198825 nombra aVERYCLOUD-SAS, lo asocia con el registro de organización para VERYCLOUD SAS y registra estado asignado. Sus campos de política de enrutamiento nombran a AS62000 y AS174 para importación y exportación IPv4 e IPv6. Lavista de prefijos anunciados de RIPEstat, capturada el 15 de julio, mostraba siete rutas visibles durante todo el intervalo devuelto del 1 al 15 de julio: cinco /24 IPv4 y dos /44 IPv6.
El conjunto IPv4 era 82.22.2.0/24, 82.22.7.0/24, 82.22.77.0/24, 82.26.157.0/24 y 151.242.39.0/24. El conjunto IPv6 era 2a0c:b641:af0::/44 y 2a10:4646:2e0::/44. Unavista independiente de BGP.Toolsmostraba el mismo recuento de orígenes de cinco y dos y describía la red como activa.
Cada uno de esos pares de prefijo de origen devolvió un resultado RPKI válido en el momento de la evidencia. Para las rutas IPv4, las autorizaciones de origen de ruta coincidentes permitían un /24. Para las rutas IPv6, permitían anuncios más específicos hasta /48. Validez significa que el AS de origen observado coincidía con una autorización. Es una señal de higiene significativa porque las redes que realizan validación de origen de ruta pueden distinguir estos anuncios de un origen no autorizado.
No es un veredicto de seguridad universal. La validez de RPKI no muestra si una ruta es accesible desde todas las redes, si un enrutador está configurado correctamente, si el tráfico sigue la ruta física prevista o si una aplicación responde. Una ruta válida aún puede retirarse. Una ruta válida puede llevar a un servidor fallido. Una ruta filtrada puede causar problemas incluso cuando la información de origen es correcta. La conclusión correcta es estrecha y positiva: los orígenes observados de VeryCloud estaban autorizados en el momento de la captura.
Lavista de vecinos de RIPEstattambién hace visible parte de la forma de enrutamiento. Mostraba AS174 y AS62000 en el lado ascendente adyacente, y AS197791 y AS198339 en el lado descendente. BGP.Tools también mostraba AS62000 y AS174 como ascendentes. Esa convergencia independiente respalda la afirmación de que AS198825 no es un registro aislado.
Sin embargo, la visibilidad de vecinos no es evidencia de circuito. Dos ASN pueden alcanzarse a través de instalaciones, puertos o rutas físicas que comparten riesgo. Un recolector de enrutamiento no revela capacidad comprometida, obligaciones de soporte, proporciones de tráfico o pruebas de conmutación por error. Tampoco prueba la afirmación del sitio web de que el tráfico se rerutará en segundos después de una falla del operador. Un comprador que necesite resiliencia debería preguntar por la topología a un nivel apropiado, la separación de dominios de falla y el resultado de un ejercicio controlado de conmutación por error.
El ASN, por tanto, hace algo valioso pero limitado. Prueba que VeryCloud participa en el enrutamiento bajo su propio número y origina un conjunto medible de direcciones. Da a los clientes y operadores externos un lugar para inspeccionar rutas. No convierte la identidad de red en una garantía de servicio de extremo a extremo.
Originar direcciones no es lo mismo que poseerlas
El sitio de red de VeryCloud describe 1,280 direcciones IPv4 en asignación, coincidiendo con cinco /24. Ese cálculo es correcto para las rutas originadas por AS198825. Los registros del registro muestran por qué la palabra propiedad sería demasiado fuerte.
Cuatro de los registros IPv4 describen a VeryCloud SAS, pero su estado en RIPE esASSIGNED PA, apuntan a otro objeto de organización y se mantienen bajo un mantenedor de terceros. El espacio agregable por proveedor se delega comúnmente para su uso sin convertirse en propiedad portátil del usuario final. El quinto bloque, 151.242.39.0/24, esSUB-ALLOCATED PAy se describe públicamente como espacio de cliente privado. AS198825 lo origina, pero la propia página de red de VeryCloud no lo presenta como el grupo de direcciones de cliente propio de la empresa.
Los registros IPv6 también tienen diferentes linajes. El registro 2a0c:b641:af0::/44 nombra a VeryCloud SAS y su organización RIPE. El registro 2a10:4646:2e0::/44 permanece bajo una organización separada asociada al nombre del fundador. Ambos eran visibles desde AS198825 y ambos tenían autorizaciones de origen válidas. El uso operativo, la asignación de registro y el control legal están relacionados pero son distintos.
Esta distinción importa durante la migración o disputa. Un cliente puede recibir una dirección que sigue siendo parte de la asignación ascendente de un proveedor. Puede funcionar perfectamente durante años pero ser difícil de mover. Un cliente que anuncie su propio prefijo portátil a través de VeryCloud tiene una posición de salida diferente de uno que utiliza una dirección asignada por el proveedor.
Las referencias de la página de tránsito remoto a IPv4 e IPv6 portátiles deberían, por tanto, resolverse en el pedido: ¿de quién es el prefijo, de quién es el objeto de ruta, de quién es la ROA, de quién es el geofeed y qué sucede en la terminación?
La reputación de las direcciones añade otra dimensión. Las redes de alojamiento pueden heredar historiales de abuso de usuarios anteriores del espacio arrendado. Una ruta técnicamente válida no garantiza que cada dirección sea aceptada por proveedores de correo electrónico, fuentes de amenazas o API de terceros. Los clientes deberían probar las direcciones reales asignadas para su carga de trabajo en lugar de inferir la reputación del ASN en su conjunto.
VeryCloud merece crédito por publicar su lista de prefijos y su looking glass. Eso hace posibles las comprobaciones externas. La interpretación más madura de esas herramientas no es que la empresa posea un bloque fijo de bienes raíces digitales. Es que coordina un conjunto en capas de derechos de enrutamiento, asignaciones y rutas de clientes. La garantía proviene de mantener esos documentos actualizados, documentados y reversibles.
DNS muestra dos modelos de entrega
El registro de dominio público vincula la cronología de la marca con su red. Los registros AFNIC muestran queverycloud.frse creó el 8 de febrero de 2023, antes de la SAS, y permaneció activo en la fecha de evidencia. Sus servidores de nombres eran operados por Cloudflare. El DNS público para el sitio principal,www, el administrador de cuentas, la documentación y los nombres de estado devolvían direcciones de borde de Cloudflare tanto en IPv4 como en IPv6.
Eso significa que un lector que carga el sitio web no prueba directamente AS198825. Cloudflare termina el borde público y puede absorber, almacenar en caché o proxy el tráfico antes de que llegue a un origen. El acuerdo puede mejorar la resiliencia y la seguridad, pero separa la accesibilidad de la marca de la visibilidad de ruta del propio proveedor. Ver el sitio web a través de Cloudflare durante un incidente de AS198825 no probaría que los servidores de los clientes estuvieran sanos. No poder acceder a una página servida por Cloudflare no probaría, por sí mismo, que el sistema autónomo estuviera caído.
Otros nombres se conectan más directamente.lg.verycloud.frylg.as198825.netresolvían a 82.26.157.253, dentro de uno de los /24 observados desde AS198825. El intercambiador de correo paraverycloud.freramail.as198825.net, que resolvía a 82.26.157.251 en el mismo /24. Estos enlaces proporcionan evidencia práctica de que al menos el looking glass y las superficies de correo tocan el espacio de direcciones originado por la red.
La distinción es analíticamente útil. El estate público combina un borde externo con puntos finales de red directos. Esta es una entrega híbrida normal, pero la monitorización debería reflejarlo. Una comprobación debería observar el sitio web como lo ve un usuario a través de Cloudflare. Otra debería probar las dependencias del lado del origen. Comprobaciones separadas deberían cubrir el área de cuentas, DNS, correo, looking glass y servicios del cliente. Una única página de inicio verde no puede representar todas esas rutas.
No se devolvió ningún registro DS paraverycloud.fren la instantánea del 15 de julio. Eso es solo una observación de delegación. No significa que el DNS no esté autenticado en todas las capas, ni niega otros controles de Cloudflare. Identifica una pregunta específica: si DNSSEC no está implementado intencionalmente en el padre, se está introduciendo o se considera innecesario para este dominio. Para una empresa que vende servicios de red, una decisión documentada es más tranquilizadora que una suposición.
DNS también impone un límite a las afirmaciones de localidad. Una dirección de borde pertenece a la red de entrega, no necesariamente al país de origen. Una dirección directa revela la ruta, no el servidor físico o la base de datos detrás de ella. Los compradores deberían usar DNS como evidencia de dependencias y puntos de control, nunca como un mapa completo de ubicación de datos.
La ubicación francesa es significativa, pero necesita un sustantivo
VeryCloud dice repetidamente que los datos del cliente se alojan exclusivamente en Francia, en Telehouse 3 en Magny-les-Hameaux. El contrato es más cuidadoso: dice que los datos se alojan en Francia por defecto y prevé transferencias reguladas fuera de la Unión Europea cuando corresponda. Estas afirmaciones pueden coexistir si se refieren a diferentes categorías de datos, pero las categorías necesitan nombres.
Los datos de carga de trabajo del cliente en un VPS son una categoría. La identidad de la cuenta, las facturas, los tokens de pago, los mensajes de soporte, los informes de abuso, la telemetría de seguridad, los eventos de monitoreo y las copias de seguridad del proveedor son otras. Un host informático francés puede usar un procesador de pagos externo. Una plataforma de tickets puede procesar metadatos de soporte en otro lugar. Un sistema antifraude puede evaluar la información de la cuenta a través de otro subprocesador. Un servicio de monitoreo puede retener direcciones IP y marcas de tiempo de eventos fuera del país del servidor.
Los términos de VeryCloud reconocen la división. Para los datos del cliente procesados a través de servicios de alojamiento, el cliente actúa como controlador y VeryCloud como procesador. Para los datos de relación con el cliente, como registros, facturación, soporte y seguridad, VeryCloud actúa como controlador. El proveedor dice que hay un acuerdo de procesamiento de datos disponible y que su lista de subprocesadores está disponible a pedido. También dice que los clientes recibirán información sobre los cambios según el DPA.
Ese marco es más útil que una bandera en una tarjeta de producto, porque pregunta quién puede actuar sobre cada conjunto de datos. Un comprador debería solicitar el DPA, la lista actual de subprocesadores, las ubicaciones, el mecanismo de transferencia, los períodos de retención, el proceso de eliminación y la ruta de notificación de violación. Debería preguntar si las copias de seguridad gestionadas permanecen en Francia, si los registros del plano de control siguen la misma regla, y si el personal de soporte fuera de Francia puede acceder a los sistemas del cliente.
Lapágina de Telehouse para Magny-Les-Hameauxconfirma de forma independiente una instalación sustancial con energía redundante, generadores, arreglos de UPS, acceso vigilado y certificaciones de gestión a nivel de instalación. Eso respalda la afirmación de VeryCloud de que el sitio nombrado existe y tiene controles físicos serios.
No certifica a VeryCloud SAS. Un inquilino hereda los beneficios del edificio pero aún tiene que configurar sus racks, credenciales, red, copias de seguridad y procedimientos. Los guardias de la instalación no impiden que un administrador del cliente elimine un disco virtual. La energía redundante no demuestra que la secuencia de recuperación de un proveedor haya sido probada. Una certificación de la instalación puede cubrir el sistema de gestión del operador sin cubrir cada proceso del inquilino o carga de trabajo del cliente.
La soberanía de los datos, por tanto, no se logra diciendo Francia con suficiente frecuencia. Se logra manteniendo los derechos de decisión, el acceso, las copias y las salidas atribuibles. La ubicación de VeryCloud es un ancla creíble y comercialmente relevante. El trabajo restante es adjuntar cada sustantivo importante: datos de producción, copia de seguridad, registro, ticket, cuenta, clave e imagen de recuperación.
La disponibilidad necesita una memoria pública
VeryCloud anuncia un 99.99% de disponibilidad para servicios VPS y dedicados. Expresado en un mes de 30 días, ese objetivo permite solo unos pocos minutos de indisponibilidad contada. Pero el contrato, no el decimal, determina lo que se cuenta.
Los términos excluyen o tratan por separado el mantenimiento planificado, las fallas causadas por el cliente y las fallas fuera de la responsabilidad del proveedor. Definen la medición y los créditos de servicio, y requieren un ticket dentro de los 30 días posteriores a un incidente. Esto significa que los clientes necesitan su propio monitoreo. Sin un registro externo con marca de tiempo, puede ser difícil establecer cuándo un servicio dejó de estar disponible, qué capa falló y si el evento cumplió con la definición contractual.
VeryCloud mantiene unapágina de estado pública, que es una superficie de responsabilidad positiva. En la fecha de evidencia, la página en vivo exponía un monitor de VeryCloud a través de HetrixTools. Una instantánea de búsqueda del mismo período aún describía una página más antigua de Uptime Kuma con una lista de componentes más larga. Esa aparente transición puede simplemente reflejar un rediseño del monitoreo. También muestra por qué una página de estado debería preservar la continuidad cuando las herramientas cambian.
Un servicio de estado público útil hace más que mostrar verde o rojo. Define componentes, registra la hora de inicio y recuperación del incidente, distingue investigación de mitigación y preserva resúmenes posteriores al incidente. Los clientes deberían poder suscribirse sin unirse a un chat comunitario. El mantenimiento debería permanecer visible después de que termine. Un proveedor puede ocultar detalles sensibles mientras aún explica el servicio afectado, la causa general, la ruta de restauración y el trabajo de prevención.
Los datos de ruta pública pueden complementar ese historial, pero no reemplazarlo. RIPEstat mostró los siete prefijos visibles durante el intervalo devuelto de dos semanas. Eso respalda la continuidad de la ruta a nivel de recolector. No dice nada sobre fallas de hipervisor, latencia de almacenamiento, acceso a cuentas, tickets o una sola instancia de cliente. Del mismo modo, una página de inicio verde servida por Cloudflare no demuestra que el parque de VPS esté sano.
La jerarquía de evidencia debería, por tanto, estar en capas. Los monitores de enrutamiento global observan prefijos. Las sondas externas observan puertos y transacciones. El monitoreo de hipervisor y almacenamiento observa la infraestructura. Las comprobaciones de aplicaciones observan la tarea del usuario. Los tickets registran el impacto y la propiedad. Las pruebas de restauración demuestran la recuperabilidad. Las páginas de estado comunican una versión curada de esos hechos.
VeryCloud publica el comienzo de esa jerarquía: rutas, un looking glass y un monitor público. Antes de mover una carga de trabajo crítica, un comprador debería pedir el resto en una forma apropiadamente confidencial: cálculos de disponibilidad, historial de mantenimiento, ejemplo de comunicación de incidentes, éxito de copias de seguridad, pruebas de restauración y tiempos de escalamiento. El propósito no es atrapar al proveedor en un error decimal. Es saber si ambas partes reconocerán el mismo incidente.
Las reseñas de clientes muestran el problema del antes y el después
La página de Trustpilot de VeryCloud es más grande de lo que podría sugerir la escasa entrada del directorio. El 15 de julio mostraba 123 reseñas, una puntuación de 4.4, un 82% de valoraciones de cinco estrellas y un 11% de valoraciones de una estrella, con 56 reseñas en los 12 meses anteriores. El perfil fue reclamado en agosto de 2023, y Trustpilot dice que la empresa invita a los clientes a reseñar. También dice que la empresa no ha respondido a las reseñas negativas.
Esos números son una señal de mercado, no una auditoría de rendimiento. Trustpilot dice explícitamente que no verifica las opiniones de los revisores, aunque utiliza un cribado y puede verificar que ocurrió una interacción. Las invitaciones pueden cambiar quién responde. Una distribución de estrellas no controla el producto, la carga de trabajo, la habilidad del cliente, la antigüedad del servicio o la gravedad del incidente.
Las reseñas positivas visibles, sin embargo, identifican temas útiles para probar. Los revisores describían aprovisionamiento rápido, documentación accesible, una superficie de gestión utilizable y soporte receptivo. Esas observaciones coinciden con las afirmaciones de automatización y soporte de VeryCloud. Sugieren que la velocidad y la ayuda humana son parte del valor percibido del proveedor, no solo las especificaciones del procesador.
Las reseñas negativas visibles en la página capturada se concentraban en 2023 y alegaban servicios eliminados y problemas de reembolso. Una queja visible estaba marcada como verificada. Son alegaciones graves de usuarios individuales, no hallazgos establecidos. Su fecha es igualmente importante: se refieren al proyecto temprano, dos años antes de que se creara la SAS. Una evaluación justa ni las borra ni las atribuye mecánicamente a la empresa posterior.
La pregunta correcta es qué cambió. ¿La transferencia de 2025 trajo controles de facturación más claros, advertencias de eliminación, registros de cuentas y vías de apelación? ¿Los términos actuales y el área de cliente previenen el patrón de falla alegado en las reseñas más antiguas? ¿El proveedor ha comenzado a preservar la evidencia del estado del servicio y del pago lo suficientemente bien como para resolver disputas? ¿Responde en privado a través de tickets mientras deja las reseñas públicas sin respuesta, o la retroalimentación negativa queda sin atender?
El volumen positivo reciente puede indicar mejora, pero una puntuación no puede responder a esas preguntas de proceso. La empresa podría fortalecer la garantía respondiendo a reseñas negativas sustanciales sin revelar datos del cliente, publicando el ciclo de vida de la suspensión y eliminación, y registrando cómo se escalan las disputas sobre el estado de pago. Los clientes también pueden protegerse guardando facturas, avisos de renovación, exportaciones de tickets, identificadores de servicio y copias de seguridad independientes.
Las reseñas son más útiles cuando producen una prueba. El aprovisionamiento rápido se puede probar con una instancia de bajo riesgo. La calidad del soporte se puede probar con una pregunta técnica de preventa. La cancelación se puede probar antes de una renovación crítica. La extracción de datos se puede ensayar. Las quejas antiguas de eliminación deberían llevar a un simulacro de salida, no a un veredicto basado en un puñado de publicaciones.
La mano de obra de soporte es el límite de capacidad oculto
VeryCloud promete soporte técnico las 24 horas del día, los 7 días de la semana a través de tickets en el área de cliente, con correo electrónico o chat en algunos casos. Su página de servidor dedicado también promueve soporte en francés a través de tickets y Discord. El contrato limita el trabajo incluido a la infraestructura, hardware, red, disponibilidad del servidor y paneles de control del proveedor.
Este es un límite sensato. También significa que un pequeño número de personas capacitadas pueden estar en el punto donde convergen muchas líneas de productos. Un ticket sobre una aplicación inalcanzable puede requerir conocimiento del estado de facturación, salud del hipervisor, asignación de direcciones, visibilidad de rutas, filtrado, configuración del invitado e historial del cliente antes de que el respondedor pueda localizar la responsabilidad. La automatización puede abrir y enrutar el caso, pero el diagnóstico es trabajo humano.
El acceso las 24 horas no es lo mismo que profundidad las 24 horas. El registro público no muestra la dotación actual de soporte, el patrón de turnos, la cobertura de idiomas, la distribución de la primera respuesta o el roster de escalamiento. No dice si la persona que responde un mensaje de Discord puede hacer un cambio de enrutador, autorizar un reembolso o reemplazar hardware. No revela cómo se priorizan los incidentes simultáneos.
Para los clientes ordinarios, Discord puede ser útil. Los miembros de la comunidad responden preguntas simples, y un equipo visible puede hacer que un proveedor pequeño se sienta accesible. Para seguridad, facturación y decisiones sobre el estado del servicio, el ticket debería seguir siendo la autoridad. Los mensajes de chat pueden ser editados, perdidos en el volumen o vistos por la audiencia equivocada. Un ticket puede llevar identidad de cuenta, marcas de tiempo, archivos adjuntos y estado de escalamiento en un registro controlado.
La mano de obra local también importa en la instalación. Un respondedor remoto puede inspeccionar la telemetría, pero el hardware fallido, el cableado y las alimentaciones de energía pueden requerir manos en Magny-les-Hameaux. La división entre el personal de VeryCloud, los contratistas y el personal de Telehouse determina quién puede entrar al espacio, reemplazar un componente y confirmar la recuperación. Una promesa de soporte humano debería conectar esos roles en lugar de dejar al cliente coordinarlos.
Antes de un despliegue crítico, los compradores deberían hacer preguntas operativas que revelen capacidad sin exigir información personal: ¿Cuál es el objetivo de respuesta por gravedad? ¿Quién puede declarar un incidente mayor? ¿Hay un ingeniero de red de guardia? ¿Cómo se solicitan las intervenciones de hardware? ¿El soporte conserva un historial completo de tickets? ¿Puede un cliente nombrar múltiples contactos autorizados? ¿Hay una ruta de emergencia si el portal de cuentas no está disponible?
Las respuestas importan porque VeryCloud vende tanto automatización como intervención. Los servidores se pueden crear automáticamente, pero las excepciones se acumulan en torno a facturación, abuso, migración, enrutamiento y recuperación. El producto es confiable solo si la cola humana tiene suficiente autoridad y tiempo para resolver esas excepciones.
Un comprador debería valorar la salida, no solo la entrada
VeryCloud compite con atractivos paquetes de recursos y una historia de alojamiento francés. El precio mensual visible es solo una parte de la decisión comercial. El costo real incluye administración, copia de seguridad, monitoreo, portabilidad de direcciones, trabajo de incidentes y migración.
Un VPS no gestionado transfiere trabajo sustancial al cliente. Alguien debe parchear el sistema operativo, asegurar SSH, monitorear el espacio en disco, renovar los certificados de la aplicación, probar las copias de seguridad, responder a los informes de abuso y diagnosticar fallas de software. VeryCloud puede proporcionar una máquina virtual saludable mientras el servicio del cliente permanece vulnerable debido a una administración descuidada. Una factura de servidor baja puede ser racional si el comprador ya tiene esa capacidad. Es engañosa si la mano de obra faltante se trata como gratuita.
La economía de las copias de seguridad es especialmente fácil de subestimar. El contrato excluye la restauración ordinaria sin una opción gestionada, y la asistencia para exportación al final del contrato puede ser facturable. Un comprador debería valorar las copias independientes, el almacenamiento, la transferencia, la retención y las pruebas de restauración. Debería saber cuánto tiempo lleva una exportación completa y si el servicio permanece escribible durante la migración. Siete días de gracia posterior al contrato pueden ser suficientes para un cliente preparado y peligrosamente cortos para uno no probado.
La direccionabilidad también afecta el costo de salida. Las cargas de trabajo vinculadas a direcciones IPv4 asignadas por el proveedor pueden necesitar cambios de DNS, actualizaciones de listas de permitidos, calentamiento de reputación y comunicación con el cliente cuando se mueven. Los prefijos portátiles y las sesiones BGP pueden reducir algunas dependencias pero añaden experiencia en enrutamiento, trabajo de registro y obligaciones de seguridad. El tránsito remoto puede preservar las direcciones a través de un cambio de alojamiento solo si el cliente realmente controla los recursos relevantes y la ruta de reemplazo está lista.
La propuesta de ubicación de datos en Francia también tiene un precio. Puede simplificar la adquisición para clientes que buscan una instalación nacional y un foro legal familiar. No elimina la necesidad de evaluar subprocesadores o construir recuperación fuera de un dominio de falla. Un cliente que requiera resiliencia geográfica puede necesitar un segundo sitio francés, otra región europea o una ubicación de copia de seguridad independiente, según la política y el riesgo.
Finalmente, los remedios contractuales tienen límites económicos. Los créditos del SLA compensan parte de una tarifa mensual; rara vez igualan el costo comercial de una interrupción. Los límites de responsabilidad y las exclusiones significan que el cliente sigue siendo el asegurador de muchas consecuencias. La criticidad debería, por tanto, determinar la arquitectura. Un servidor de hobby puede aceptar un arreglo simple. Un sistema de ingresos puede necesitar DNS multi-proveedor, datos replicados, configuración portátil, monitoreo externo y un runbook probado.
VeryCloud puede seguir siendo la opción económica después de esas adiciones. El punto es comparar los costos operativos completos. El precio de entrada responde a lo que cuesta empezar. El precio de la garantía responde a lo que cuesta seguir siendo recuperable y poder irse.
Cómo sería una prueba más sólida
El registro público ya respalda varias conclusiones con confianza. VERYCLOUD es una SAS francesa activa. Presenta un catálogo de servicios coherente y términos legales actuales. AS198825 está activo y visible con orígenes IPv4 e IPv6. Las autorizaciones de origen de ruta eran válidas en la fecha de evidencia. El DNS público conecta la marca tanto con servicios servidos por Cloudflare como con direcciones directas en el espacio de AS198825. La instalación nombrada de Telehouse es real. Existe un registro no trivial de reseñas de clientes.
El siguiente nivel de garantía no requiere que la empresa publique diagramas sensibles. Requiere evidencia que pueda compartirse con un comprador bajo términos apropiados.
Para identidad y continuidad, eso significa una cuenta clara de la transferencia de 2025, la entidad contratante en las facturas, y el seguro y la situación financiera actuales cuando corresponda. Para servicios, significa una descripción definitiva del pedido que anule las tarjetas de catálogo transitorias. Para resiliencia de red, significa prefijos previstos, ROAs actuales, propiedad de dependencias, dominios de falla física y resultados recientes de conmutación por error.
Para datos, el comprador necesita el DPA, la lista de subprocesadores, las ubicaciones por servicio, el modelo de acceso, el cifrado y la propiedad de las claves, la retención, la eliminación y el diseño de la copia de seguridad. Para disponibilidad, necesita el cálculo del SLA, el rendimiento medido reciente, el historial de mantenimiento y un ejemplo de comunicación de incidentes. Para recuperación, necesita evidencia de que las copias de seguridad se monitorean y las restauraciones se han completado dentro del objetivo requerido.
Para soporte, las medidas útiles no son eslóganes sino distribuciones: primera respuesta por gravedad, tiempo hasta la propiedad técnica, tiempo hasta la restauración, casos reabiertos y escalamientos no resueltos. Un proveedor pequeño no necesita operar un centro de llamadas enorme. Necesita mostrar que el trabajo urgente llega a alguien autorizado a actuar.
El cliente tiene obligaciones recíprocas. Debe mantener contactos precisos, asegurar su cuenta, parchear lo que administra, clasificar sus datos, mantener material de recuperación independiente, monitorear transacciones y enviar tickets oportunos. El proveedor no puede restaurar una carga de trabajo que nunca se contrató para respaldar. El cliente no puede diagnosticar una red que no puede observar. La garantía es un conjunto de responsabilidades unidas, no una insignia comprada al finalizar la compra.
La evidencia pública de VeryCloud es más sólida donde las operaciones de Internet son naturalmente públicas: registro de ASN, orígenes de ruta y DNS. Es más débil donde los resultados del servicio son privados: manejo de incidentes, recuperación de almacenamiento, capacidad de soporte y configuración del cliente. Ese patrón no es inusual. Es exactamente por eso que un comprador debería usar la evidencia pública sólida para hacer mejores preguntas privadas, en lugar de tratar la ausencia de detalle público como prueba de falla o permiso para asumir éxito.
Un nombre enrutado, no un veredicto final
VERYCLOUD SAS tiene más detrás de lo que la etiqueta del directorio revela inicialmente. Hay una empresa francesa activa, una transición publicada de un proyecto anterior, un contrato definido, una reclamación de instalación real y una red que puede observarse desde el exterior. AS198825 origina cinco prefijos IPv4 y dos IPv6, con autorizaciones de origen de ruta válidas en la fecha de evidencia. Eso es una prueba sustancial para un proveedor joven.
Es prueba de identidad y participación en la red. No es prueba de que cada carga de trabajo permanecerá disponible, cada byte se mantiene dentro de una jurisdicción, cada copia de seguridad es restaurable o cada ticket urgente llega al ingeniero correcto. Las páginas de producto públicas a veces comprimen distinciones que el contrato restaura: continuidad de la infraestructura versus recuperación del cliente, alojamiento francés versus la cadena más amplia de procesadores, acceso 24/7 versus alcance administrativo incluido, y una disponibilidad objetivo versus el remedio real del cliente.
El historial de mercado mixto refuerza el punto. Los revisores recientes a menudo elogian la velocidad y el soporte, mientras que las quejas visibles del proyecto anterior plantean preguntas sobre eliminación y estado de pago. Ningún lado debería convertirse en una historia universal. Los controles actuales del proveedor deberían probarse contra los modos de falla que expone el registro anterior.
Para un cliente potencial, la secuencia sensata es directa. Verifique la SAS en el pedido. Identifique el límite exacto del servicio. Confirme la dirección y el modelo de enrutamiento. Solicite el DPA y la lista de subprocesadores. Decida quién posee cada copia de seguridad y restauración. Monitoree desde fuera. Coloque seguridad, facturación y comunicación de incidentes en tickets. Ensaye la migración antes de que sea urgente.
Esa secuencia no disminuye el valor de la red de VeryCloud. Pone la red en su lugar adecuado. Un ASN visible es una base mejor que una identidad de revendedor anónimo. Un RPKI válido es mejor que orígenes ambiguos. Un looking glass público es mejor que pedir a los clientes que confíen en un diagrama. Son señales de un operador dispuesto a exponer parte de su trabajo al escrutinio.
La garantía operativa comienza después de que esas señales se hayan leído correctamente. Surge cuando la identidad legal, las rutas, los contratos, los controles de datos, los registros de estado, las pruebas de recuperación y la autoridad humana apuntan al mismo servicio. VERYCLOUD SAS ya puede ser identificada y observada. La pregunta restante para cada comprador es si la evidencia privada detrás de un pedido específico es tan coherente como el nombre de red público.