Hosting en Madrid con discos NVMe, PHP 8.2, Redis y SSL incluido, en un CPD Tier III. Desde 55 €/año sin IVA y migración gratuita.
La tarifa de alojamiento web de Aclass se compone de cuatro planes publicados: 55 €/año, 65 €/año, 125 €/año y 195 €/año, todos sin IVA y sin permanencia. Los cuatro se ejecutan sobre la misma plataforma física en nuestro CPD de Madrid, con almacenamiento NVMe, panel Plesk y certificado SSL incluido. Lo que cambia entre un plan y otro no es la calidad del servidor: es el reparto de espacio en disco, el número de webs alojadas, la transferencia mensual y el número de bases de datos.
Conviene leer la tabla buscando primero el recurso que su proyecto agota antes. Una web corporativa con textos, fotografías optimizadas y un formulario consume muy poco disco y se queda cómoda en el plan de entrada durante años. Una tienda online con catálogo grande, variantes y facturas almacenadas consume disco y base de datos a un ritmo mucho mayor, y un portal con descargas o vídeo agota primero la transferencia mensual. Elegir por precio sin mirar cuál de esas tres cosas se agota primero es la causa habitual de una ampliación precipitada a los seis meses.
El cambio de plan dentro de la tarifa se hace sin migrar datos, sin cambiar la dirección IP y sin ventana de corte: la cuenta sigue en el mismo servidor y solo se amplían sus límites. Por eso recomendamos empezar por el plan que cubre el consumo real de hoy con un margen razonable, no por el que cubriría el escenario más optimista de tráfico dentro de tres años. Si el crecimiento llega, la ampliación es inmediata.
Los precios se publican siempre sin IVA ni ningún otro impuesto aplicable. Cuando una especificación concreta no está documentada, aparece marcada como dato pendiente en lugar de rellenarse con una cifra aproximada: preferimos una tabla incompleta y verificable a una tabla completa e inventada. Si necesita el detalle exacto de la copia programada o de cualquier límite de un plan, se lo confirmamos por escrito antes de contratar. Y si su proyecto necesita más que un plan de alojamiento compartido, nuestros servidores VPS desde 36 €/mes son el paso natural dentro de la misma infraestructura.
| Característica | 55 €/año | 65 €/año | 125 €/año | 195 €/año |
|---|---|---|---|---|
| Precio anual sin IVA | 55 €/año | 65 €/año | 125 €/año | 195 €/año |
| Espacio en disco NVMe | 3 GB NVMe | 5 GB NVMe | 10 GB NVMe | 20 GB NVMe |
| Dominios alojados | 1 web alojada | 2 webs alojadas | Múltiples webs alojadas | Múltiples webs alojadas |
| Cuentas de correo | Cuentas de correo ilimitadas | Cuentas de correo ilimitadas | Cuentas de correo ilimitadas | Cuentas de correo ilimitadas |
| Bases de datos | 1 base de datos MySQL/MariaDB | 2 bases de datos MySQL/MariaDB | Bases de datos ilimitadas | Bases de datos ilimitadas |
| Transferencia | 200 GB/mes | 300 GB/mes | 400 GB/mes | 1 TB/mes |
| Versión de PHP | PHP 8.2 (versión seleccionable) | PHP 8.2 (versión seleccionable) | PHP 8.2 (versión seleccionable) | PHP 8.2 (versión seleccionable) |
| SSL incluido | SSL Let's Encrypt incluido | SSL Let's Encrypt incluido | SSL Let's Encrypt incluido | SSL Let's Encrypt incluido |
| Soporte | Soporte técnico en español | Soporte técnico en español | Soporte técnico en español | Soporte técnico en español |
La calculadora interactiva combina el plan elegido, el número de dominios extra (de 0 a 20) y los años de contratación (de 1 a 3), y devuelve el total del periodo y su equivalente mensual. Todos los precios se muestran sin IVA ni ningún otro impuesto aplicable.
La ubicación física del servidor sigue siendo determinante para tres cosas que un proveedor no puede compensar con marketing: el tiempo que tarda el primer byte en llegar al navegador de un visitante español, la jurisdicción a la que están sometidos los datos y la capacidad real de dar una respuesta técnica cuando algo falla. Alojar en un centro de datos de Madrid resuelve las tres a la vez, y esa es la diferencia principal frente a un plan idéntico servido desde Fráncfort, Dublín o Virginia.
La búsqueda de alojamiento web en Madrid suele venir motivada por un problema concreto: una web lenta cuyo hosting está en otro continente, una auditoría de protección de datos que pregunta dónde se almacena la información o un soporte que contesta en inglés y con doce horas de desfase. Los tres tienen la misma solución.
La latencia es el tiempo que tarda un paquete en ir y volver entre el visitante y el servidor. Desde operadores nacionales hacia nuestro CPD de Madrid ese valor se mantiene por debajo de 5 ms, mientras que un servidor en Europa central suele situarse entre 30 y 45 ms y uno en la costa este de Estados Unidos supera con facilidad los 100 ms. Ese retardo no se paga una vez: se paga en cada conexión TLS, en cada petición de la página y en cada llamada al carrito, de modo que el efecto acumulado sobre el tiempo de carga percibido es muy superior a la cifra aislada.
Cuando el servidor está en Madrid, la respuesta a la pregunta de dónde residen los datos es directa y verificable, sin cadenas de subencargados ni transferencias internacionales que documentar. Eso simplifica el registro de actividades de tratamiento, evita cláusulas contractuales tipo y reduce el trabajo de una auditoría de cumplimiento. Para sectores con datos sensibles —sanitario, jurídico, educativo o administración— esta trazabilidad deja de ser una preferencia y pasa a ser un requisito que hay que poder acreditar por escrito.
Buena parte de la oferta de hosting en España es reventa: el proveedor comercializa capacidad de un tercero y, cuando aparece una incidencia de hardware o de red, solo puede abrir un ticket y esperar. En nuestro caso la plataforma es propia y el equipo que atiende el soporte es el mismo que administra los servidores, lo que acorta el diagnóstico y elimina un intermediario en la cadena de escalado. La ficha técnica del centro de datos, con su ubicación y su nivel de certificación, se entrega por escrito a cualquier empresa que lo solicite antes de contratar.
Esa propiedad de la infraestructura tiene una consecuencia práctica que rara vez se explica en las páginas de producto: cuando hace falta una intervención física —sustituir un disco, ampliar memoria en un nodo o revisar un enlace de red— la realiza nuestro personal en el mismo edificio, dentro de la ventana acordada y sin depender del calendario de un tercero. Es la misma razón por la que podemos aceptar peticiones que un revendedor no puede atender, como una configuración de red específica o una restauración fuera de horario.
Si en lugar de alojar una sola web va a gestionar las de varios clientes, la opción adecuada no es contratar planes sueltos sino un hosting reseller en marca blanca , que reparte el espacio en cuentas independientes bajo su propio panel y sus servidores de nombres.
El rendimiento de una web dinámica se decide en tres capas: la velocidad a la que el disco entrega los ficheros y las consultas, la eficiencia con la que el intérprete de PHP ejecuta el código y el número de consultas que la base de datos se ahorra gracias a la caché. Un plan de alojamiento puede ser excelente en una capa y mediocre en las otras dos, y el resultado que percibe el visitante siempre lo marca la más lenta.
Nuestra plataforma trabaja las tres a la vez: almacenamiento NVMe con más de 500.000 IOPS, PHP 8.2 con OPcache activado y Redis disponible como caché de objetos, sobre MariaDB ajustada para cargas de CMS. Es la razón por la que una misma instalación de WordPress responde de forma distinta según dónde esté alojada, aunque el tema y los plugins sean idénticos.
Un SSD SATA está limitado por la interfaz a unos 550 MB/s y a una cola de comandos corta. Un disco NVMe habla directamente por PCIe, con colas mucho más profundas, y supera holgadamente los 3.000 MB/s de lectura secuencial. En una web, sin embargo, lo que importa no es la lectura secuencial sino las operaciones aleatorias pequeñas: cargar cientos de ficheros PHP, leer índices de la base de datos y escribir sesiones. Ahí es donde el NVMe marca la diferencia real, y donde una web con muchos plugins deja de esperar al disco. La consulta habitual de alojamiento web SSD se resuelve en nuestra plataforma con un escalón por encima: todo el almacenamiento es NVMe, no SSD SATA.
PHP 8.2 ejecuta el mismo código bastante más rápido que las ramas 7.x que todavía se encuentran en muchos alojamientos antiguos, y además recibe parches de seguridad. Con OPcache, el bytecode compilado se guarda en memoria y deja de recompilarse en cada petición. Con Redis como caché de objetos, las consultas repetidas de WordPress o PrestaShop se sirven desde memoria en lugar de golpear la base de datos. La versión de PHP es seleccionable desde el panel, de modo que una aplicación heredada que aún no soporta la rama 8 puede convivir con proyectos actualizados.
La base de datos suele ser el cuello de botella silencioso de una web con años de historia: tablas de opciones cargadas de datos autocargados, tablas de metadatos sin índices adecuados y registros de plugins que nadie ha limpiado. Nuestro stack usa MariaDB con la configuración de memoria y caché ajustada para cargas de CMS, pero ningún ajuste del servidor sustituye a una limpieza de la instalación. Por eso, cuando detectamos consultas lentas en una migración, lo indicamos en el informe de traspaso junto con la tabla concreta que las provoca; puede ampliar este punto en nuestra guía de mantenimiento de WordPress.
"Alto rendimiento" es hoy un adjetivo sin prueba en prácticamente todo el sector del alojamiento web: se afirma en todas las páginas y no se documenta en casi ninguna. Nuestra posición es la contraria: publicamos lo que hemos medido, con el método de medida al lado, y dejamos marcado como pendiente lo que todavía no tenemos documentado con herramienta, fecha y configuración de prueba. Una cifra sin método es una afirmación comercial, no un dato.
La tabla siguiente separa las tres columnas que hacen falta para que un benchmark sea útil: qué se mide, qué resultado se obtiene y cómo se ha obtenido. Sin la tercera columna, la segunda no se puede reproducir ni comparar entre proveedores, que es exactamente el problema que tiene el visitante cuando intenta elegir entre dos ofertas que dicen lo mismo.
Los dos valores que hoy publicamos —más de 500.000 IOPS de almacenamiento y latencia inferior a 5 ms dentro de España— corresponden a la plataforma física sobre la que se ejecutan tanto el alojamiento web como los servidores virtuales. Las dos métricas pendientes, el TTFB medido desde Madrid y el LCP de una instalación limpia de WordPress, dependen del contenido concreto de cada web, por lo que las publicaremos con la configuración exacta del banco de pruebas en lugar de con una cifra genérica que ningún cliente pueda reproducir en su propio sitio.
Conviene además interpretar bien qué mide cada indicador. El TTFB describe cuánto tarda el servidor en empezar a responder y depende sobre todo de la ejecución de PHP y de la base de datos; el LCP describe cuándo el visitante ve el elemento principal de la página y depende también del tamaño de las imágenes, de las fuentes tipográficas y de los scripts de terceros que cargue la web. Un alojamiento rápido mejora el primero de forma directa y el segundo solo en parte: la otra parte está en el propio sitio, y por eso desconfiamos de cualquier proveedor que prometa una puntuación concreta de rendimiento sin haber visto la web que va a alojar.
| Métrica | Resultado |
|---|---|
| IOPS del almacenamiento NVMe | Más de 500.000 IOPS |
| Latencia media de red al CPD | Inferior a 5 ms dentro de España |
La mayoría de las webs que alojamos funcionan sobre un gestor de contenidos, y cada uno estresa el servidor de una manera distinta. Nuestro stack de hosting CMS está preparado para los cinco gestores más extendidos en el mercado español, con las extensiones de PHP que cada uno necesita, los límites de memoria adecuados y la caché de objetos disponible desde el primer día, sin que haya que abrir un ticket para activarla.
Es el gestor más común y también el más sensible al número de plugins activos. Con OPcache y Redis, una instalación con veinte plugins deja de repetir trabajo en cada visita. Complementamos el alojamiento con recomendaciones de seguridad en WordPress para reducir la superficie de ataque.
Las tiendas online concentran su carga en la base de datos y en el disco: catálogos con miles de referencias, imágenes en varias resoluciones y procesos de pedido que escriben en cada paso. Son los proyectos que antes agotan el espacio y la transferencia de un plan, y los que más se benefician del NVMe.
Ambos siguen presentes en portales institucionales y corporativos con estructuras de contenido complejas. Su requisito habitual no es potencia bruta, sino una versión de PHP concreta y determinadas extensiones activas, algo que se configura por cuenta desde el panel sin afectar al resto de webs alojadas.
El panel Plesk permite instalar cualquiera de estos gestores en unos minutos, con la base de datos creada y el certificado emitido. Todos los planes incluyen certificado SSL con renovación automática; si necesita validación de organización o extendida, nuestra guía de certificados SSL explica cuándo compensa dar ese salto.
Cada cuenta dispone además de acceso por SFTP, gestor de bases de datos, tareas programadas y correo, de modo que el traslado de un proyecto existente no obliga a renunciar a ninguna pieza de su funcionamiento actual. Si su equipo trabaja con entornos de pruebas, el panel permite clonar el sitio a un subdominio, validar allí las actualizaciones del gestor y sus extensiones, y publicar los cambios solo cuando la revisión es correcta.
Migramos su web sin coste desde cualquier proveedor. El proceso empieza con un inventario de lo que hay: ficheros, bases de datos, cuentas de correo, tareas programadas, certificados y registros DNS. Ese inventario es la parte que más incidencias evita, porque los problemas de una migración casi nunca están en copiar la web: están en la cuenta de correo que nadie recordaba o en la tarea programada que genera las facturas cada noche.
Después replicamos el sitio en nuestra plataforma y lo probamos con el dominio todavía apuntando al proveedor antiguo, de modo que se puede verificar el funcionamiento completo —navegación, formularios, pasarela de pago y envío de correo— antes de tocar nada en producción. Solo cuando esa verificación es correcta se cambian los registros DNS, reduciendo previamente el TTL para acortar la propagación; el detalle de cada tipo de registro está en la guía de registros DNS.
La ventana de corte real suele limitarse al tiempo de sincronizar los últimos cambios de la base de datos, habitualmente minutos y programada fuera del horario comercial. Durante las horas siguientes ambos entornos permanecen activos para no perder ningún correo mientras se propaga el cambio. Al terminar entregamos una verificación con las URL comprobadas, el estado del certificado y los envíos de correo probados. Si además de alojamiento necesita rehacer la web, nuestro grupo cuenta con un equipo especializado en diseño y desarrollo web .
El plazo habitual de una migración estándar es de uno a tres días laborables desde que recibimos los accesos, y depende sobre todo del tamaño de la base de datos y del número de cuentas de correo que haya que trasladar con su historial. Las webs con integraciones externas —pasarelas de pago, sistemas de facturación o conectores con un ERP— requieren una comprobación adicional de las IP autorizadas en cada servicio, porque el cambio de servidor implica una dirección nueva que hay que dar de alta antes del corte.
El compromiso de disponibilidad de la plataforma es de un 99,9% de uptime, con monitorización continua de los servicios y actuación proactiva cuando una métrica se sale del rango normal. Ese porcentaje no se sostiene con vigilancia manual: se sostiene con hardware redundante, con alimentación y refrigeración protegidas en el CPD y con un procedimiento de escalado que pone a un técnico de sistemas delante del problema sin pasar por un centro de llamadas.
En el plano de la seguridad, cada cuenta de alojamiento está aislada de las demás, de forma que una web comprometida no puede leer ni modificar los ficheros de otra en el mismo servidor. El cortafuegos filtra el tráfico no legítimo y limita los intentos de acceso repetidos, que son la vía habitual de los ataques de fuerza bruta contra los paneles de administración de los CMS. El acceso a ficheros se realiza por SFTP y el certificado SSL viene incluido en todos los planes, con renovación automática para evitar caducidades inadvertidas.
Las actualizaciones del sistema operativo, del servidor web y de los intérpretes las aplicamos nosotros; las de su CMS, sus plugins y su tema siguen siendo responsabilidad de quien mantiene la web, y son la causa más frecuente de una infección. Para la protección del dato trabajamos con copias de seguridad gestionadas en un servicio especializado, y para la infraestructura de ficheros compartidos entre sedes puede interesarle nuestro cloud NAS.
Un plan de alojamiento compartido cubre sin problemas la mayoría de webs corporativas y tiendas pequeñas. Se queda corto cuando aparece alguna de estas tres señales: la web necesita software que no forma parte del stack del panel, el consumo sostenido de procesador supera lo que una cuenta compartida puede garantizar, o el proyecto exige acceso administrativo al sistema para instalar servicios propios. Ese es el momento de pasar a un servidor virtual, no antes.
Hay una cuarta señal, menos evidente pero igual de válida: la responsabilidad operativa. En un plan de alojamiento el mantenimiento del sistema es nuestro y el cliente solo se ocupa de su web; en un servidor virtual la frontera se desplaza y aparecen decisiones de administración —parches, servicios, cortafuegos— que alguien tiene que asumir, sea su equipo o el nuestro en la modalidad gestionada. Elegir VPS sin resolver esa pregunta suele salir más caro que quedarse en un plan de alojamiento bien dimensionado.
El salto no obliga a cambiar de proveedor ni de centro de datos: los servidores VPS desde 36 €/mes se ejecutan sobre la misma plataforma de Madrid, con la misma cabina NVMe y el mismo equipo de soporte. Si quiere el análisis completo de las diferencias entre alojamiento, máquina virtual, clúster y hardware exclusivo, la comparativa de cloud, VPS y dedicado lo desarrolla criterio a criterio.
| Criterio | Hosting | VPS |
|---|---|---|
| Recursos | Compartidos con otras cuentas del mismo servidor, con límites por cuenta | vCPU, memoria y disco reservados para su máquina |
| Acceso al sistema | Panel Plesk, FTP/SFTP y base de datos; sin acceso root | Acceso administrativo completo al sistema operativo |
| Software instalable | El stack web disponible en el panel (PHP, MariaDB, Redis) | Cualquier servicio: colas, contenedores, motores no estándar |
| Escalado | Cambio de plan dentro de la tarifa publicada | Ampliación de vCPU, memoria y disco sobre la misma máquina |
| Precio de partida sin IVA | 55 €/año | 36 €/mes |
Antes de contratar, lo sensato es revisar tres datos de su web actual: cuánto ocupa, cuánta transferencia consume al mes y qué versión de PHP necesita. Con eso elegimos juntos el plan correcto y planificamos la migración sin coste ni interrupción del servicio. Le atendemos en español, desde Madrid y con el mismo equipo que administra los servidores. Puede ver el resto de servicios en el hub de infraestructura IT o escribirnos para una consulta gratuita sin compromiso. Y si su proyecto necesita administrar su propio sistema operativo, el paso natural es un VPS en Madrid.
Si su web todavía está en un proveedor extranjero, el traslado no tiene coste y la diferencia se nota desde el primer día en el tiempo de respuesta para visitantes españoles y en la rapidez con la que se resuelve cualquier incidencia. Y si aún no tiene dominio propio, puede registrarlo en el mismo paso desde nuestro registro de dominios, con los DNS ya apuntando a la cuenta de alojamiento. Si el proyecto es de venta online, en la página de tiendas online explicamos qué infraestructura necesita cada tipo de comercio electrónico.
NVMe con más de 500.000 IOPS
CPD en Madrid, latencia < 5 ms
Uptime 99,9% y SSL incluido