Resumen
- dmgcloud está vinculado públicamente a Digital Media Growing Cloud, S.L., una sociedad limitada madrileña con CIF B01871664, un rastro en el Registro Mercantil de 2020, un objeto social declarado en torno a hosting, telecomunicaciones, consultoría, programación y servicios informáticos, y un sitio web activo que vende servicios VPS y hosting.
- El registro técnico es más concreto que una página de marca simple: el AS204555 está asignado en RIPE como
dmgcloud, pertenece a ORG-DMGC2-RIPE, es visible en RIPE Stat con tres anuncios /24 de IPv4 y se encuentra detrás de una identidad LIR española de RIPE. - El límite de la garantía sigue siendo importante: las páginas de servicio público demuestran una oferta de VPS y hosting, pero la localidad de los datos, el personal de soporte, el control de las instalaciones, el manejo de abusos y los compromisos de resiliencia aún requieren confirmación a nivel de contrato antes de que el nombre en la nube pueda tratarse como prueba operativa.
Lo primero que hay que resistir con dmgcloud es que el nombre hace demasiado trabajo. Es corto, con forma de infraestructura y seguro. Suena como una plataforma en la nube antes de que uno se pregunte si hay una empresa detrás, si esa empresa es española en un sentido legal, si la oferta de servicio es real y no ornamental, si los recursos de red están activos, y si un cliente puede entender quién responde cuando algo se rompe. Un nombre en la nube no es evidencia por sí mismo. Es una invitación a seguir el registro.
El registro le da a dmgcloud más sustancia que una etiqueta de hosting suelta. La página de directorio público identifica a dmgcloud como una empresa privada y operador de red asociado con recursos ASN/IP, con AS204555 como el número de sistema autónomo visible. Esa entrada de directorio es estrecha más que expansiva: lista un ASN, marca el nombre legal y de visualización como dmgcloud, y da la geografía de recursos de red como global mientras que el campo de geografía ordinaria no está resuelto. Eso importa porque enmarca el primer problema analítico. El directorio sabe que hay una identidad de recurso de red.
No resuelve, por sí solo, la identidad corporativa española, el modelo de servicio orientado al cliente ni los compromisos operativos detrás del nombre.
La identidad española más sólida aparece en las páginas legales y de privacidad de la empresa y en los registros comerciales españoles. El sitio web presenta a la entidad responsable como Digital Media Growing Cloud, S.L., con CIF B01871664 y una dirección en Calle Zurbano 45, Piso 1, 28010 Madrid. El aviso legal dice que la empresa está inscrita en el Registro Mercantil de Madrid con el mismo rastro de registro que aparece en la evidencia pública de la empresa: tomo 40910, folio 15, hoja M-725683.
La publicación BORME del 24 de septiembre de 2020 registra la entrada de constitución de DIGITAL MEDIA GROWING CLOUD SL, sitúa el inicio de operaciones el 26 de agosto de 2020, da la misma dirección de Zurbano, registra un capital de 3.000 euros y enumera un objeto social que comienza con el procesamiento de datos, hosting y actividades relacionadas.
Ese objeto no es una línea decorativa. Es el nexo entre la empresa y la marca. BORME enumera procesamiento de datos, hosting y actividades relacionadas; otras actividades de telecomunicaciones; consultoría informática; programación informática; y otros servicios de TI. Cinco Dias, basándose en datos de empresa de Iberinform, presenta por separado a la empresa como una sociedad limitada con NIF B01871664, la dirección de Zurbano, CNAE 6310 sobre infraestructura informática, procesamiento de datos, hosting y actividades relacionadas, y una dirección web que apunta a dmgcloud.com.
La redacción varía ligeramente entre registros, pero la dirección es consistente: esto no es un caparazón de medios genérico que compró un dominio en la nube. El rastro público de la empresa permite a un lector razonable conectar la marca con una empresa española de tecnología y hosting.
Esa conexión aún debe mantenerse precisa. El sitio web utiliza la marca DMG Cloud y el nombre legal de la empresa Digital Media Growing Cloud, S.L. La entrada del directorio utiliza dmgcloud como nombre legal, que es una etiqueta de recurso público más flexible en lugar del nombre corporativo español completo. BORME y las páginas legales proporcionan el ancla de identidad más estricta. Por lo tanto, un comprador, par, analista o respondedor de incidentes debe tratar a Digital Media Growing Cloud, S.L. como la contraparte legal a verificar, y a dmgcloud o DMG Cloud como el nombre del servicio y la red. Esa distinción no es pedantería.
Decide qué identificador fiscal, nombre de contrato, contacto de soporte, contacto de abuso y registro de registro deben verificarse cuando la marca se usa como señal de confianza.
La prueba de servicio es inusualmente visible para un nombre en la nube pequeño. El sitio web público no es meramente una página de mantenimiento. Ofrece un área de cliente, una tienda, una base de conocimientos, un enlace de estado de la red y documentos legales. La página de inicio comercializa infraestructura en la nube de alto rendimiento y nombra productos VPS para Windows, Linux, OPNsense y RustDesk, junto con hosting cPanel y una categoría de paquete separada.
Muestra planes VPS Linux a 35, 60 y 105 euros al mes con dos, cuatro y ocho vCores; cuatro, ocho y dieciséis gigabytes de RAM; 100 gigabytes de almacenamiento NVMe; y tráfico predeterminado de 100 Mb/s descrito como ilimitado. Muestra planes VPS Windows a precios mensuales más altos con la misma escalera de recursos amplia y licencias de Windows Server incluidas por vCore.
Esas tarjetas de plan importan porque mueven el registro de la identidad al comercio. Un lector ya no está tratando solo con una empresa española cuyo objeto incluye hosting. El sitio publica un vocabulario de servicio seleccionable, una escalera de precios, variantes de sistema operativo, reclamos de almacenamiento y ancho de banda, y una superficie de control del cliente. Eso no prueba la calidad completa de la infraestructura, pero sí prueba que la oferta pública es lo suficientemente concreta para ser inspeccionada. Es prueba de servicio, no solo clasificación sectorial.
La base de conocimientos refuerza esa prueba. DMG Cloud dice que su infraestructura VPS utiliza virtualización KVM, clústeres SSD SAS y NVMe, CPUs Intel Xeon Gold y RAM reciente. Enumera sistemas operativos compatibles que incluyen Windows Server 2016, 2019, 2022 y 2025, CentOS 7, AlmaLinux 9, AlmaLinux 10, otros sistemas Linux bajo petición y opciones de VPS firewall basadas en pfSense para casos de uso de filtrado.
Dice que el servicio está diseñado como autoservicio: a través del área de cliente, los clientes pueden encender, apagar, reiniciar, reinstalar el sistema operativo, configurar reglas de firewall del centro de datos y cancelar el servicio. Estos son los ingredientes ordinarios de un negocio de VPS en lugar de un lenguaje abstracto de "nube".
Los reclamos de ancho de banda y ubicación también son públicos. La base de conocimientos dice que el ancho de banda predeterminado de VPS es de 100 Mb/s e ilimitado, con personalización disponible para proyectos que necesitan más. Otro artículo dice que los servidores se encuentran en dos ubicaciones principales: España, con Madrid marcada como MAD2, y Estados Unidos, con Miami marcada como NAP. Se dice a los clientes que pueden elegir la ubicación preferida en el momento del contrato según las necesidades de latencia.
Esa única entrada de FAQ es una de las piezas de evidencia más importantes en todo el registro porque complica el lenguaje de soberanía de datos de la página de inicio. La empresa es española, y una ubicación de servicio es Madrid, pero la geografía de servicio público no es solo España.
La página de inicio se inclina hacia la soberanía, el rendimiento y la automatización. Dice que la plataforma opera bajo estándares europeos y GDPR, presenta "soberanía de datos completa" como un punto de venta, y comercializa aprovisionamiento rápido, seguridad perimetral, aislamiento de contenedores, copias de seguridad automatizadas, discos NVMe y conectividad de red de baja latencia. Esos son reclamos comunes en el mercado de VPS, pero no carecen de significado.
Describen la historia de garantía que la empresa quiere que los clientes escuchen: implementar rápidamente, controlar el servidor, mantener los datos protegidos, usar reglas europeas y confiar en una red rápida. La pregunta de diligencia es cuánto de esa historia es visible de forma independiente.
En cuanto a la localidad, la respuesta es mixta de una manera útil. El registro legal español es sólido. La dirección de Madrid aparece en el sitio web, BORME, el registro de organización de RIPE y la evidencia del directorio empresarial. La lista de miembros de RIPE incluye a Digital Media Growing Cloud, S.L. como un registro de Internet local con sede en España. La FAQ del servicio identifica a Madrid como una de dos ubicaciones de implementación.
La página de privacidad establece que los datos personales pueden almacenarse en servidores seguros en España, en Europa o fuera de Europa donde se dice que se aplican salvaguardas de transferencia. En conjunto, el registro respalda "empresa española con una ubicación de servicio en España y reclamos de cumplimiento europeo". No respalda "todos los datos del cliente siempre permanecen en España" sin que el cliente elija esa ubicación y obtenga los términos contractuales relevantes.
Esa distinción es donde la soberanía de datos a menudo sale mal. La soberanía no es un eslogan impreso junto al GDPR. Es una cadena de decisiones: qué entidad legal firma el contrato, dónde se ejecuta el servicio principal, dónde se almacenan las copias de seguridad y las instantáneas, quién administra el hipervisor, qué subcontratistas pueden acceder a los sistemas, qué procesos de abuso y cumplimiento de la ley se aplican, qué tribunal tiene jurisdicción y qué sucede durante una restauración, migración o cancelación. Los materiales públicos de DMG Cloud responden parte de esa cadena.
Identifican una empresa española, tribunales de Madrid en los términos, España y Miami como opciones de implementación, un programa de retención de copias de seguridad y el canal de correo electrónico para soporte. No publican un acuerdo detallado de procesamiento de datos, descripción de instalaciones, lista de subprocesadores, historial de estado, informe de auditoría o garantía de residencia específica del cliente en el material revisado.
Esto no es una acusación. Es un límite. Muchos proveedores de infraestructura pequeños venden servicios VPS directos con menos papeleo público que una nube empresarial grande. Sus clientes pueden aceptar eso porque el producto es simple, el precio es claro y la relación es directa. Pero cuando un nombre en la nube se usa dentro de un directorio de proveedores, una discusión de hosting soberano o una revisión de carga de trabajo sensible, el umbral aumenta. Una FAQ pública puede probar que existe un servicio.
No puede sustituir un contrato cuando el problema es la custodia, la exposición regulatoria, el tiempo de restauración o el acceso administrativo.
La evidencia de recurso de red es el otro lado del registro, y es más concreta que el escaparate promedio de VPS pequeño. RIPE asigna AS204555 con el as-namedmgcloud. El objeto aut-num apunta a ORG-DMGC2-RIPE, el objeto de organización de RIPE para DIGITAL MEDIA GROWING CLOUD, SL. Importa de AS174 y AS12479 y exporta AS204555 a esos mismos upstreams. El estado es asignado, el mantenedor incluye el mantenedor final de RIPE NCC y el mantenedor LIR de la empresa, y el objeto fue creado y modificado por última vez el 20 de junio de 2022. Eso es un registro de sistema autónomo real, no un reclamo de marketing extraído.
El objeto de organización agrega el puente corporativo. ORG-DMGC2-RIPE nombra a DIGITAL MEDIA GROWING CLOUD, SL, da el país ES, enumera el número de registro B01871664, clasifica la organización como un LIR, proporciona la dirección de Zurbano en Madrid, da un número de teléfono, asigna el mismo handle de rol para el contacto administrativo y técnico, y apunta a un contacto de abuso. El rol de abuso publica un buzón eninfo@dmgtic.com, mientras que las páginas legales y de servicio apuntan repetidamente el soporte ordinario del cliente asupport@dmgcloud.com. Por lo tanto, hay dos pistas de responsabilidad visibles: un correo electrónico de soporte de servicio en los términos del sitio web y un buzón de abuso de RIPE en el registro de red.
Esa dualidad es útil e imperfecta. Es útil porque un operador de red con recursos públicos debería exponer un canal de abuso distinto de un ticket de cliente general. Es imperfecta porque el buzón de abuso usa un dominio diferente,dmgtic.com, en lugar del dominio de la marca pública en la nube. Eso puede ser completamente normal si las operaciones tecnológicas de DMG usan más de un dominio, pero sigue siendo una pregunta de diligencia debida. Un cliente o par debe confirmar que el buzón de abuso, el buzón de soporte, el rol de RIPE, el número de teléfono y la empresa legal se asignan a la misma autoridad operativa. El registro público sugiere el mapa. No explica el modelo de personal detrás de él.
RIPE Stat muestra que AS204555 fue anunciado en el momento de consulta del 14 de julio de 2026. Sus datos de prefijos anunciados para la ventana de dos semanas que terminan ese día enumeran tres prefijos /24 de IPv4: 193.176.100.0/24, 154.62.78.0/24 y 94.125.143.0/24. La vista de estado de enrutamiento muestra que todos los peers RIS de IPv4 en el conjunto de consultas ven el recurso, sin visibilidad IPv6, tres prefijos IPv4 anunciados, 768 direcciones IPv4, cero /48s IPv6 y tres vecinos observados. También registra una ruta vista por primera vez más antigua para 185.17.96.0/22 en febrero de 2018.
En español sencillo, dmgcloud tiene una superficie de enrutamiento IPv4 visible en tiempo presente y ningún anuncio IPv6 público en esa vista de RIPE.
Esa evidencia cambia la lectura de la empresa. Sin el ASN, DMG Cloud podría leerse como una tienda VPS de estilo revendedor que usa la plataforma de otra persona. Con AS204555, la empresa tiene una identidad de recurso de número de Internet bajo su propia organización RIPE. Eso no prueba que sea dueña de cada máquina, cada rack o cada dirección IP que anuncia. Muestra que la marca no es solo una envoltura de facturación. Tiene visibilidad de enrutamiento en vivo, relaciones con upstreams, una identidad LIR de RIPE y un objeto de organización mantenido por el registro. Para un perfil de servicio en la nube, eso es significativo.
El detalle del recurso también aboga por la precaución. Tres /24s y 768 direcciones IPv4 anunciadas son suficientes para una operación pequeña de VPS y hosting, pero no son la huella de un gran operador regional o plataforma hiperscala. El objeto aut-num muestra dependencia ascendente en lugar de una postura de interconexión grande. PeeringDB no expuso una entrada de red coincidente para AS204555 en el conjunto de evidencia congelado.
Vistas de terceros como IPinfo y bgp.tools proporcionan contexto público corroborante, incluidos peers y rangos IP, pero el punto autoritativo sigue siendo la visibilidad de RIPE: IPv4 en vivo, sin IPv6, un conjunto de recursos modesto y un nombre AS que coincide con la marca.
Esa modestia no es un defecto. Los proveedores de nube pequeños a menudo compiten precisamente ofreciendo atención local, productos más específicos, relaciones directas con el cliente y control VPS simple. Un AS pequeño con unos pocos /24s puede ser perfectamente apropiado para ese modelo. El error sería permitir que la palabra "nube" infle el registro a algo que la evidencia pública no muestra.
No hay prueba pública aquí de un tejido de nube privada multirregión, un banco de soporte empresarial formal, una línea de tiempo de incidentes pública, un catálogo de instalaciones neutrales al operador, controles auditados o una estrategia de peering amplia. Hay prueba de una empresa española, un AS en vivo, un escaparate VPS, términos de servicio, una ruta de soporte y dos geografías de implementación.
El modelo de producto también es más limitado de lo que el lenguaje de "nube de infraestructura" puede sugerir. Los términos de DMG Cloud definen VPS como un servidor virtual privado proporcionado por la empresa e infraestructura como los servidores físicos y las redes que soportan esas instancias VPS. También hacen que el cliente sea responsable de la administración, instalación de software y seguridad. Eso está más cerca de una relación VPS no gestionada o autogestionada que de una operación de nube totalmente gestionada.
El cliente obtiene control del servidor y puede obtener copias de seguridad, opciones de firewall y respuesta de soporte. El cliente aún asume la administración del sistema operativo, la seguridad de las aplicaciones, la configuración del software y la disciplina de las copias de seguridad.
Esa división de responsabilidad es una de las cosas más saludables del registro porque contrarresta la sobreinterpretación. Las páginas de servicio público no dicen "gestionamos todo por usted". Dicen que el cliente puede controlar el VPS y debe administrarlo. Los términos prohíben el spam, los ataques informáticos, la minería de criptomonedas no aprobada y las licencias de software ilegales, y permiten la suspensión en ciertos casos de mal uso. Establecen que la activación del servicio sigue al contrato confirmado y la entrega de credenciales. Dicen que el pago puede ser con tarjeta, transferencia bancaria o PayPal.
Dicen que los períodos no utilizados no se reembolsan después de la cancelación y que los datos se eliminan irreversiblemente después de la cancelación. Estas son las mecánicas de un negocio de hosting, no un folleto tecnológico vago.
La promesa de soporte es específica pero limitada. Los términos garantizan un 99.5 por ciento de disponibilidad mensual del servicio y describen créditos compensatorios cuando la disponibilidad cae por debajo de ese nivel. La FAQ da el objetivo de respuesta de soporte como 24 a 48 horas y repite la escalera de compensación: 10 por ciento de crédito por debajo del 99.5 y por encima del 99.0 por ciento de disponibilidad, 20 por ciento por debajo del 99.0 y por encima del 95.0 por ciento, y 50 por ciento por debajo del 95.0 por ciento. Los términos dicen que los clientes pueden contactar al soporte a través desupport@dmgcloud.com. La navegación pública incluye enlaces de ticket y estado, pero tanto el contacto como las rutas de estado del servidor observadas en el pase redirigieron al inicio de sesión. Eso significa que un posible cliente puede ver el lenguaje del SLA pero no un panel de estado público en vivo ni un historial de incidentes abierto.
Para muchos compradores de VPS, eso puede ser suficiente. Una respuesta de soporte de 24 a 48 horas no es inusual para infraestructura de bajo costo, especialmente cuando los clientes autogestionan el servidor. Para cargas de trabajo sensibles, no es suficiente por sí solo.
Un comprador que depende del servicio para operaciones de producción debe saber si los incidentes urgentes reciben un manejo más rápido, si hay soporte fuera del horario laboral, cómo se priorizan los tickets, qué objetivo de restauración se aplica a las copias de seguridad, qué fallas califican para créditos, cómo se calcula la medida de disponibilidad mensual y si los créditos son el único recurso. Los términos públicos comienzan esa conversación. No la completan.
El lenguaje de las copias de seguridad tiene la misma forma. La FAQ dice que DMG Cloud realiza copias de seguridad incrementales diarias para la recuperación ante desastres, conservando las últimas siete copias de seguridad diarias, dos semanales y una mensual. La página de inicio comercializa copias de seguridad automatizadas e instantáneas. Sin embargo, los términos advierten que la empresa no puede garantizar la integridad al 100% de los datos almacenados en servicios VPS porque fallos de hardware, ataques, errores de software y otros factores pueden afectar la disponibilidad.
Recomiendan que los clientes mantengan copias de seguridad adicionales fuera de las proporcionadas por DMG Cloud. Esa es una asignación de riesgo de VPS sensata, pero debe leerse claramente: la disponibilidad de copias de seguridad es una característica de soporte, no una garantía de que el riesgo de datos del cliente ha desaparecido.
Los reclamos de seguridad también están acotados. El sitio dice que utiliza filtrado automático, aislamiento estricto y seguridad perimetral. La FAQ dice que la protección anti-DDoS es básica e integrada, y que los clientes pueden configurar sus propias reglas de firewall a nivel de centro de datos para cada servicio. La página de privacidad establece que la empresa aplica medidas técnicas y organizativas y utiliza TLS para el sitio web. Estas son representaciones útiles, pero no una auditoría de seguridad independiente.
Un cliente que maneja datos sensibles aún necesitaría documentación de seguridad, responsabilidades de control de acceso, límites de parcheo, prácticas de registro, detalles de cifrado de copias de seguridad y compromisos de respuesta a incidentes. Las páginas públicas dicen lo suficiente para identificar la postura de seguridad, no lo suficiente para certificarla.
La cuestión laboral subyace a todo esto. Los registros públicos establecen la responsabilidad corporativa y de red, pero no revelan cuántas personas están disponibles para soporte, cómo se cubren los turnos o quién tiene autoridad durante un incidente de red o instalaciones. La evidencia de directorio al estilo Kompass sugiere un perfil de empresa española pequeña. El handle de rol de RIPE se nombra genéricamente como "CEO", no como un centro de operaciones de red detallado. La ruta de soporte pública del sitio web apunta a tickets vinculados al inicio de sesión y un correo electrónico de soporte.
Nada de eso es inusual para un proveedor compacto. Sin embargo, significa que el soporte local debe tratarse como una cuestión de responsabilidad, no como una suposición de marketing.
El soporte laboral local es más que una dirección española. Es la disponibilidad de personas que puedan interpretar un ticket, cambiar el enrutamiento, restaurar una copia de seguridad, responder a un informe de abuso, escalar a un upstream, diagnosticar un problema de hipervisor, hablar con un cliente y tomar una decisión cuando un tribunal, regulador o par de red pide acción. DMG Cloud tiene superficies de contacto público para soporte y abuso, una entidad legal española y un rastro de recurso RIPE.
Lo que no es público es la plantilla, el modelo de cobertura, la cadena de escalamiento, la relación con las instalaciones o la separación entre soporte ordinario y respuesta de emergencia. Para hosting de bajo riesgo, eso puede no ser un obstáculo. Para garantía, es la siguiente pregunta.
El lado de las instalaciones también se infiere en su mayoría en lugar de documentarse. La FAQ nombra a Madrid MAD2 y Miami NAP como ubicaciones de servicio, pero el conjunto de evidencia pública no incluye una página detallada de instalaciones de DMG Cloud que describa los centros de datos físicos, los cross-connects upstream, el diseño de energía, las certificaciones, los términos de manos remotas o los socios de colocación. El objeto de red muestra los upstreams AS174 y AS12479. La superficie de enrutamiento muestra tres prefijos IPv4 visibles para los recolectores de RIPE. Esos son pistas de red, no pruebas de instalaciones.
Ayudan a explicar la accesibilidad. No le dicen al cliente dónde se encuentra cada host físico, qué proveedor controla el edificio o quién realiza la intervención de hardware.
Aquí es también donde la palabra "centros de datos" en la FAQ debe leerse con cuidado. DMG Cloud dice que los clientes pueden configurar reglas de firewall a nivel de centro de datos, y el artículo de ubicación del servicio nombra los sitios de Madrid y Miami. Esas declaraciones son útiles porque describen la superficie de control presentada al cliente. No revelan, por sí mismas, el propietario del centro de datos subyacente, la relación contractual con ese propietario, el diseño de energía y refrigeración, ni el modelo de acceso físico. Un comprador de VPS puede no necesitar esos detalles.
Un comprador que hace un reclamo de soberanía, resiliencia o subcontratación regulada generalmente los necesita. La redacción pública prueba que el servicio tiene controles orientados al centro de datos; no prueba la operación independiente de las instalaciones.
La misma precaución se aplica a "Madrid" como señal de localidad. Madrid en la FAQ es una opción de servicio, no una garantía automática adjunta a cada cuenta. La existencia de Miami NAP como la otra ubicación nombrada significa que un cliente puede hacer una elección de geografía que cambie la historia legal y operativa. Una implementación en Madrid puede respaldar un argumento de localidad española si las copias de seguridad, el acceso de soporte y los subprocesadores están alineados.
Una implementación en Miami puede ser perfectamente legítima por razones de latencia o mercado, pero debilita cualquier reclamo de que el servicio es español por defecto en un sentido de residencia de datos. El punto no es que una ubicación sea mejor. El punto es que la ubicación debe ser seleccionada, documentada y mantenida.
Hay una brecha similar entre la responsabilidad del registro y la responsabilidad del cliente. La responsabilidad de RIPE está construida para Internet: quién tiene el AS, quién mantiene el objeto, quién recibe el correo de abuso, qué rutas son visibles. La responsabilidad del cliente está construida para el servicio: quién responde los tickets, quién restaura los datos, quién acredita el tiempo de inactividad, quién tiene acceso al panel de control, quién aprueba los cambios de emergencia. dmgcloud tiene respuestas visibles en ambas categorías, pero las respuestas se encuentran en diferentes lugares públicos.
El rol de abuso de RIPE apunta a un buzón. Los términos y la página de privacidad apuntan a los usuarios ordinarios a otro. Los enlaces del área de cliente y estado existen, pero un observador no conectado no puede inspeccionar el flujo de trabajo de tickets ni el historial público de incidentes. Eso es suficiente para establecer una superficie; no es suficiente para auditar el modelo operativo.
La escala financiera no es pública en la evidencia congelada de la manera en que lo fue para algunos registros de empresas más grandes, por lo que el artículo no debe inferir el número de empleados o la solidez del balance más allá de las pistas del directorio y el registro. Lo que se puede decir es más limitado: la empresa se constituyó con capital ordinario de pequeña empresa, las páginas de negocios de terceros la tratan como una sociedad limitada española en actividades relacionadas con hosting, y el objeto de organización de RIPE posteriormente le dio el estatus de LIR.
Esa secuencia es consistente con un pequeño proveedor de infraestructura que construye un papel de recurso de red más explícito después de la constitución. No es prueba de profundidad de personal, reservas de efectivo, propiedad de hardware o capacidad de soporte empresarial. Esos requerirían otros documentos.
Esa restricción protege el análisis de un error común en la diligencia debida en la nube: convertir cada registro visible en un reclamo de capacidad. Un número de identificación fiscal prueba que se puede identificar una empresa. Un objeto BORME prueba un área de actividad permitida. Un sitio web prueba una oferta. Un TOS prueba términos de servicio. Una organización RIPE prueba la responsabilidad de recursos numéricos. Una ruta en vivo prueba el anuncio. Un correo electrónico de soporte prueba una ruta de contacto. Ninguno de esos hechos individuales prueba los demás.
El valor del registro de dmgcloud es que muchos de los hechos coinciden; el riesgo es pretender que la línea ya es una cadena de garantía completa.
Eso importa porque "nube" colapsa varias capas diferentes en una sola palabra minorista. Está la capa legal: Digital Media Growing Cloud, S.L. en Madrid. Está la capa de servicio: VPS, hosting, firewall y opciones de sistema operativo. Está la capa de red: AS204555 y tres /24 anunciados. Está la capa de geografía: opciones de ubicación Madrid y Miami. Está la capa de soporte: correo electrónico de soporte, tickets de inicio de sesión, lenguaje de respuesta de 24 a 48 horas y contacto de abuso de RIPE.
Está la capa de instalaciones: implícita por los nombres de ubicación del centro de datos y la operación de red, pero no expandida públicamente. La garantía depende de cómo se alineen esas capas.
El caso más fuerte para dmgcloud es que esas capas son al menos lo suficientemente visibles para separarse. Muchos nombres de infraestructura pequeños ni siquiera superan ese listón. Aquí, un lector puede identificar la empresa legal española, el número de identificación fiscal, la entrada del registro, la oferta de servicio, los términos, el correo electrónico de soporte, el programa de copias de seguridad, la tabla de créditos SLA, la organización RIPE, el ASN, los prefijos anunciados actuales, la política de upstream y la falta de IPv6 público. Eso es un expediente público significativo.
Permite a un analista decir que la empresa tiene una huella real española y de recursos de red en lugar de solo un nombre que suena a nube.
El caso más débil es que varias de esas capas invitan a más confianza de la que pueden soportar de manera segura. "Soberanía de datos completa" suena más amplio que un modelo de servicio con ubicaciones tanto en Madrid como en Miami y un lenguaje de privacidad que permite almacenamiento en España, Europa o fuera de Europa con salvaguardas. "Nube de alto rendimiento" suena más amplio que la prueba pública de una cartera VPS modesta. "Estado de la red" suena transparente, pero la ruta de estado observada públicamente requería inicio de sesión.
"Soporte y SLA" suena operativamente completo, pero una ventana de respuesta de 24 a 48 horas y una tabla de créditos no explican la escalación urgente. "AS204555" suena a control de red, pero el registro público aún no muestra un perfil de PeeringDB, IPv6, detalles de instalaciones ni un looking glass público.
Por lo tanto, la lectura correcta no es ni un rechazo escéptico ni una aceptación fácil. dmgcloud no debe tratarse como un cascarón vacío. Sus registros legales, de servicio y de enrutamiento son demasiado específicos para eso. Tampoco debe tratarse como un atajo de garantía operativa. La evidencia pública prueba un negocio con forma de proveedor con recursos de red en vivo y una oferta VPS definida. No prueba que todos los requisitos del cliente en torno a resiliencia, soberanía, cumplimiento, horas de soporte, custodia de datos o control de instalaciones estén satisfechos.
Esta distinción es importante para los directorios porque las categorías son pegajosas. Una vez que una empresa se clasifica bajo servicio en la nube, los lectores pueden importar suposiciones de proveedores de nube más grandes: resiliencia multizona, páginas de estado público, procesos de incidentes documentados, grandes mesas de soporte, paquetes de cumplimiento publicados, documentos formales de seguridad blanca y manejo maduro de abusos. La evidencia de dmgcloud apunta a un proveedor más pequeño y más específico.
La categoría aún puede ser correcta, pero el lector necesita la nota de alcance: operador español de VPS y hosting con AS204555, identidad pública madrileña, opciones de ubicación Madrid y Miami, control de autoservicio y documentación de garantía pública limitada.
También es importante para los clientes que comparan proveedores locales. Una empresa española con su propia identidad LIR de RIPE puede ser atractiva cuando la alternativa es un revendedor anónimo o una plataforma global con soporte distante. El registro legal madrileño de DMG Cloud, el número de registro de RIPE, la dirección española, el teléfono local en RIPE, el correo electrónico de soporte y los documentos en español reducen la primera barrera de responsabilidad. Si algo sale mal, al menos hay una entidad legal y un propietario de recursos numéricos a los que señalar.
Pero la responsabilidad local solo se vuelve operativa cuando el cliente sabe quién es responsable de cada capa de servicio y con qué rapidez actúan.
El registro BORME da un buen ejemplo de por qué la identidad pública es necesaria pero insuficiente. Nos dice que la empresa comenzó operaciones en agosto de 2020, tenía un capital de 3.000 euros, enumeró actividades de hosting y TI y nombró administradores. Eso es suficiente para mostrar el nacimiento y el propósito corporativo. No nos dice si la empresa ahora opera su propio hardware, alquila capacidad, utiliza socios o ha cambiado el énfasis operativo desde 2020. El registro RIPE llena una pieza posterior al mostrar el estatus LIR creado en 2022 y la asignación AS en junio de 2022. El sitio web llena la pieza orientada al cliente.
La línea de tiempo resultante es coherente, pero sigue siendo un esquema público, no un historial operativo completo.
Lo mismo es cierto para la evidencia de enrutamiento. Que AS204555 esté activo en RIPE Stat es una señal más fuerte que un ASN inactivo. Los tres anuncios /24 visibles muestran accesibilidad IPv4 actual. Las líneas de importación y exportación upstream muestran dependencia de grandes redes upstream. La ausencia de visibilidad IPv6 debe notarse porque los compradores de infraestructura moderna esperan cada vez más soporte IPv6, especialmente para servicios en la nube y hosting. Pero nada de eso cuenta toda la historia del servicio. BGP prueba el anuncio de ruta.
No prueba la satisfacción del cliente, la confiabilidad de las copias de seguridad, la disponibilidad del soporte, la seguridad física ni la localidad contractual de los datos.
Para los compradores de software empresarial y automatización, el modelo de autoservicio crea tanto valor como riesgo. El aprovisionamiento automatizado, el control instantáneo y las reglas de firewall gestionadas por el cliente pueden hacer que los servicios VPS pequeños sean eficientes. Reducen el tiempo de espera y dan a los usuarios control directo sobre las acciones básicas del ciclo de vida. También acercan los errores al cliente.
Si el cliente controla el sistema operativo, el firewall, el proceso de reinstalación y la pila de aplicaciones, entonces la propia competencia del cliente se convierte en parte de la confiabilidad del servicio. Los términos de DMG Cloud reconocen eso al asignar la administración y seguridad del VPS al cliente. El servicio puede ser una superficie de automatización útil, pero no un sustituto de operaciones gestionadas a menos que un acuerdo separado lo diga.
La lectura de soberanía de datos debe ser igualmente práctica. Un comprador que necesita hosting español debe confirmar la selección de Madrid MAD2 al realizar el pedido, confirmar si las copias de seguridad permanecen en la misma jurisdicción, confirmar si algún subcontratista de soporte o infraestructura fuera de España puede acceder a los datos del cliente y obtener términos de procesamiento de datos consistentes con la carga de trabajo. Un comprador que elige Miami por latencia para usuarios estadounidenses no debe luego reclamar localidad exclusivamente española basándose en la entidad legal.
La FAQ pública es refrescantemente clara de que hay dos ubicaciones. La tarea de diligencia es hacer que la elección de ubicación sea contractualmente duradera.
La lectura de responsabilidad de soporte debe hacer un conjunto diferente de preguntas. ¿El soporte es solo por correo electrónico y ticket, o hay una ruta telefónica de emergencia? ¿El objetivo de respuesta de 24 a 48 horas se aplica a todos los incidentes o solo a los tickets ordinarios? ¿Las interrupciones de red se tratan de manera diferente a los problemas de configuración del cliente? ¿El buzón de abuso de RIPE se monitorea continuamente? ¿Los informes de abuso van al mismo personal que gestiona la infraestructura del cliente? ¿Hay una página de estado pública o solo para clientes con historial de incidentes?
¿Los créditos SLA son automáticos o el cliente debe solicitarlos? El registro público nombra la superficie de soporte; no muestra el ritmo operativo detrás de ella.
La lectura de recursos de red debe preguntar si los prefijos anunciados se utilizan para servicios del cliente, infraestructura interna o ambos. Debe confirmar si 193.176.100.0/24, 94.125.143.0/24 y 154.62.78.0/24 son todos parte del entorno orientado al cliente. Debe preguntar por qué la vista de RIPE Stat no ve ningún anuncio IPv6 y si IPv6 está disponible a través de otro mecanismo. También debe confirmar si la mezcla de upstream en el objeto RIPE coincide con el enrutamiento actual, ya que el texto de la política de aut-num puede retrasarse con respecto a la realidad operativa. Estas son preguntas normales para cualquier AS pequeño.
No son banderas rojas. Son cómo la evidencia de recursos se convierte en garantía de servicio.
Lo más interesante de dmgcloud es que se encuentra en la brecha entre dos tipos de confianza. Una es la confianza documental: registro de empresa, número de identificación fiscal, aviso legal, términos, organización RIPE, ASN, prefijos, correo electrónico de soporte. La otra es la confianza operativa: capacidad, profundidad de soporte, historial de incidentes, resiliencia de instalaciones, custodia de datos, restauración de copias de seguridad, manejo de abusos y evidencia del cliente. El primer tipo es público y bastante sólido aquí. El segundo tipo es parcialmente público y parcialmente faltante.
Un perfil cuidadoso debe preservar esa asimetría en lugar de aplanarla en "nube verificada" o "proveedor no probado".
Esa asimetría también protege a la empresa de expectativas injustas. Un pequeño proveedor de VPS no debe ser juzgado como si tuviera el aparato de divulgación de un hiperescalador. Si DMG Cloud vende planes VPS autogestionados a precios mensuales modestos, es razonable que algunos detalles de soporte, estado y cumplimiento se encuentren detrás del área de cliente o el proceso de contrato. Pero los sistemas de categorías públicas y las revisiones de proveedores aún deben mostrar los límites.
Los lectores deben saber que el AS en vivo y el registro español son reales, mientras que la capa de garantía pública sigue siendo más delgada de lo que sugiere la marca.
Por lo tanto, la entrada del directorio puede ser refinada por el registro externo en lugar de reemplazada por él. La afirmación central de la entrada de que dmgcloud está asociado con AS204555 es correcta. El perfil más amplio debe agregar que la entidad legal española detrás del servicio es Digital Media Growing Cloud, S.L., CIF B01871664, con un registro en Madrid y un rastro de dirección.
Debe agregar que el sitio web público vende productos VPS y hosting, proporciona artículos de base de conocimientos sobre KVM, ancho de banda, copias de seguridad, controles DDoS, ubicaciones de servidores y respuesta de soporte, y publica términos bajo la ley española. También debe agregar las advertencias: los campos de geografía pública no deben dejarse solo como "global" cuando la FAQ del servicio nombra Madrid y Miami; la garantía pública no debe implicar residencia de datos en toda España; y la responsabilidad de soporte debe permanecer sin resolver hasta que la evidencia de escalamiento orientada al cliente esté disponible.
La frase "antes de que el nombre se convierta en garantía operativa" es el estándar correcto porque dmgcloud tiene suficiente evidencia para ser tentador. Un nombre de empresa madrileña más un escaparate en la nube más un ASN en vivo puede sentirse completo. No está completo. Es un punto de partida bien formado. La siguiente capa es la verificación: contraparte firmada, ubicación seleccionada, geografía de copias de seguridad, horas de soporte, manejo de abusos, mecánica del SLA, dependencias upstream, disponibilidad IPv6, operador de instalaciones y términos de procesamiento de datos.
Esas preguntas deben hacerse antes de que una carga de trabajo, revisión de proveedor o entrada de directorio convierta la marca en una garantía.
La conclusión responsable es estrecha y positiva. dmgcloud no es solo un nombre que suena a nube. Tiene una identidad pública española a través de Digital Media Growing Cloud, S.L.; tiene prueba de servicio a través de un escaparate VPS y hosting; tiene prueba de recursos de red a través de AS204555 y tres anuncios /24 IPv4 actuales; y tiene señales de responsabilidad de soporte a través de contactos legales, de soporte y de abuso de RIPE. Pero la garantía operativa requiere más que esos hechos públicos. El registro español prueba la empresa. El sitio web prueba la oferta. El registro BGP prueba la accesibilidad en vivo.
El cliente aún tiene que probar los términos bajo los cuales la localidad, la resiliencia, el soporte y la responsabilidad se vuelven realmente ejecutables.