Hosting PrestaShop: requisitos del servidor y rendimiento

El alojamiento es el suelo sobre el que se asienta su tienda

Hemos ejecutado PrestaShop en prácticamente todos los niveles de alojamiento que existen: servidores compartidos baratos con cPanel heredados de clientes, VPS en Hetzner y OVH, máquinas dedicadas en centros de datos y el TrueNAS de oficina que aloja la propia mypresta.rocks. Después de más de diez años haciendo esto, nuestra postura es sencilla: ninguna cantidad de caché, optimización de imágenes o ajuste de módulos salvará a una tienda atascada en un alojamiento mal dimensionado o mal configurado. Acierta primero con el suelo y todo lo que va encima resultará más fácil.

Esta página tiene una opinión clara a propósito. Es lo que le enviaríamos a un cliente que pregunta «¿en qué debería alojar?» antes de firmar nada.

Tipos de alojamiento, por orden de cuándo son realmente adecuados

Alojamiento compartido barato (entre 3 y 15 $/mes aproximadamente)

Tu tienda comparte un servidor con cientos de otras. Obtienes cPanel o DirectAdmin, una configuración de PHP bloqueada y ningún acceso root. Los buenos (los hemos visto) te permiten elegir un PHP reciente, activar OPcache y no sobrevenden los discos. Los malos hacen justo lo contrario.

Lo que obtienes: factura mensual baja, correo incluido y otra persona que parchea el sistema operativo.
Lo que renuncias: vecinos ruidosos que hunden los tiempos de respuesta de forma aleatoria, sin SSH en los planes de entrada, sin Redis, sin Varnish, versiones de PHP que tú no eliges y una IP compartida que otro inquilino puede dejar en lista negra en tu nombre.

Aceptable para una tienda recién creada con menos de 500 productos, poco tráfico y sin presión de tiempo para optimizar. No aceptable para nada que estés intentando hacer crecer.

VPS (gestionado o no gestionado, 5-60 $/mes)

RAM dedicada, CPU dedicada, disco dedicado, acceso root. Aquí es donde viven la mayoría de las tiendas de nuestros clientes, y es donde pondríamos la tuya.

VPS gestionado: el proveedor parchea el sistema operativo y se encarga de las actualizaciones de seguridad. Tú te encargas de PrestaShop. Un panel de control o un servicio gestionado suele añadir entre 5 y 20 $/mes sobre el precio del VPS sin extras.
VPS no gestionado: una máquina Debian o Ubuntu en blanco con SSH. Más barata, pero tú eres responsable de cada línea de configuración de nginx y de cada actualización del kernel.

Para el 90 % de las tiendas con las que trabajamos, un VPS gestionado en el rango de 15-30 $/mes supera al alojamiento compartido en todas las dimensiones que importan.

Servidor dedicado (80-300+ $/mes)

Una máquina física entera, sin la sobrecarga del hipervisor. Excesivo para una tienda con 2.000 productos. Es la decisión acertada cuando superas los 50.000 productos con tráfico serio: ahí es donde trasladamos a los clientes de un VPS en la nube a algo como un dedicado de Hetzner, porque la relación precio-rendimiento se vuelve ridícula a tu favor.

VPS en la nube

Facturación por horas, aprovisionamiento rápido, snapshots y una API. 2 GB / 2 vCPU se sitúa en la franja de 5-15 $/mes entre los proveedores que merece la pena usar, y los proveedores con sede en la UE rebajan de forma fiable a los de EE. UU. para especificaciones equivalentes.

Alojamiento «PrestaShop gestionado»

Máquinas preconfiguradas con soporte específico para PS. El argumento de venta resulta atractivo si nunca has tocado un servidor. La realidad es que suele ser infraestructura revendida con un sobreprecio, y el soporte conoce el panel de control de la tienda, no tus módulos concretos.

El alojamiento PS gestionado se gana su dinero cuando de verdad no tienes ninguna intención de aprender a manejar un servidor. Para cualquier otra persona, un VPS gestionado con una pila LEMP sensata rinde mejor y cuesta menos.

Requisitos mínimos, por versión de PrestaShop

PrestaShop 1.7

PHP: 7.1-7.4 • MySQL: 5.5+ (se recomienda 5.7) • RAM: 2 GB como mínimo, 4 GB sensato
Extensiones: curl, gd, intl, mbstring, zip, xml, json, openssl

PrestaShop 8.x

PHP: 7.2-8.1 (8.1 es la que usamos en nuestros despliegues) • MySQL: 5.6+ • RAM: 4 GB como mínimo
Extensiones: la lista de 1.7 más fileinfo e iconv

PrestaShop 9.x

PHP: 8.1-8.4 (en producción ejecutamos 8.2) • MySQL: 8.0+ o MariaDB 10.5+ • RAM: 4 GB como mínimo, 8 GB si tienes tráfico real
Extensiones: la lista de 8.x, con los requisitos de Symfony 6.4 aplicándose por encima

Trata estos números como «la tienda se instalará», no como «la tienda rendirá». La fila inicial de 2 GB que aparece más abajo corresponde a tiendas pequeñas con PrestaShop 1.7; usa al menos 4 GB para PrestaShop 8 o 9. Un catálogo de 5.000 productos con 50 módulos y tráfico real necesita entre 4 y 8 GB de RAM independientemente de la versión que tengas sobre el suelo.

Pantalla de Información del panel de administración de PrestaShop con la configuración de PHP, MySQL y servidor

Guía de dimensionamiento

Tamaño de la tienda	Productos	Visitantes diarios	RAM	CPU	Disco
Inicial	<500	<200	2 GB	1 núcleo	20 GB SSD
Pequeña	500-2K	200-1K	4 GB	2 núcleos	40 GB SSD
Mediana	2K-10K	1K-5K	8 GB	4 núcleos	80 GB SSD
Grande	10K+	5K+	16 GB+	4-8 núcleos	160 GB+ SSD

Un recordatorio sobre el disco: 5.000 productos con 5 imágenes cada uno, regeneradas en los 7 tipos de imagen de PrestaShop, consumen entre 10 y 20 GB antes de que hayas añadido nada más. Planifica el disco en consecuencia.

Lo que realmente marca la diferencia

Todos los proveedores anuncian núcleos, RAM y ancho de banda. En nuestra experiencia, este es el orden en el que las cosas importan de verdad.

1. Versión de PHP y OPcache

PHP 8.1 es aproximadamente entre un 20 y un 40 % más rápido que 7.4 con el mismo código, y OPcache resulta ser la mayor ganancia por encima de eso. Sin OPcache, PrestaShop recompila cientos de archivos PHP en cada petición. Con él, el bytecode compilado viene directamente de la memoria.

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

Si un proveedor no te permite activar OPcache, o sigue sirviendo PHP 7.x en 2026, márchate. No hay ninguna ventaja.

2. E/S de disco: SSD o NVMe, nunca discos mecánicos

PrestaShop lee cientos de archivos por página. La lectura aleatoria de un HDD ronda los 5-15 ms, la de un SSD los 0,1 ms. Solo eso supone una diferencia de 3x en el tiempo real de página. No desplegaremos una tienda en HDD. Tú tampoco deberías.

3. Configuración de MySQL

Una página típica de PS lanza entre 100 y 300 consultas. El único ajuste que más importa es innodb_buffer_pool_size: controla qué parte de tus datos vive en la RAM. Entre el 50 y el 70 % del total de RAM en un servidor de base de datos dedicado, entre el 25 y el 40 % en una máquina combinada de aplicación y base de datos. Antes de ajustar en torno a una base de datos sobrecargada, usa Database Cleanup o auditorías SQL equivalentes para recortar carritos abandonados, registros y estadísticas obsoletas.

4. RAM

Cada proceso de trabajo de PHP-FPM usa entre 30 y 80 MB de memoria residente. Diez procesos suponen entre 300 y 800 MB solo para PHP, y luego añade MySQL, Redis, el propio OPcache y el sistema operativo. 2 GB van justos antes de haber servido una sola petición.

5. HTTP/2

Multiplexa todo sobre una única conexión. Entre un 20 y un 40 % más rápido en páginas que cargan entre 60 y 80 recursos, que es la mayoría de páginas de PrestaShop. Necesita HTTPS, que de todos modos ya necesitabas.

Alojamiento compartido: los muros con los que se topará

El compartido puede funcionar para las tiendas más pequeñas, pero te toparás con estos muros más o menos en este orden:

Sin SSH. No puedes ejecutar Composer por CLI, comandos de consola ni ninguno de los scripts de limpieza en los que normalmente nos apoyaríamos.
Límites de cron. Muchos alojamientos compartidos limitan el cron a cada 15 minutos. El mantenimiento de PrestaShop quiere más.
memory_limit limitado. 128-256 MB es lo normal en los planes baratos. Las importaciones grandes fallan en silencio al alcanzarlo.
Sin Redis. Quedas atascado en la caché del sistema de archivos, sobre un almacenamiento compartido que ya está ocupado.
IP compartida. El hábito de spam de un vecino deja tu IP en lista negra, y los correos de confirmación de pedido dejan de llegar. Cubrimos la solución en nuestra guía de entregabilidad de correo.

Si vas a contratar compartido de todos modos, prioriza el acceso SSH, un panel de control que te permita elegir la versión de PHP, soporte para OPcache y un límite de memoria que puedas elevar. Y lee siempre el precio de renovación: el número de entrada es marketing.

2,99 $/mes se renueva a 10,99 $ un año después. Todos los sitios de reseñas de compartido barato pasan esto por alto. Nosotros no.

VPS: la opción acertada para la mayoría de tiendas

Por qué acabamos siempre aquí

Acceso root. Instala Redis, Varnish, toda la pila.
CPU y RAM dedicadas. Ningún vecino a quien culpar a las 2 de la tarde del Black Friday.
Control total de PHP-FPM y OPcache.
SSH y cron sin restricciones.
nginx, no Apache, salvo que elijas lo contrario.
Snapshots antes de actualizaciones arriesgadas: tres clics para volver atrás.

Qué comprobar de verdad antes de contratar

Almacenamiento SSD o NVMe. Si la ficha técnica no lo dice, asume HDD y descártalo.
Precio justo. 2 GB / 2 vCPU a 5-15 $/mes es lo normal. 30 $ es pagar de más.
Ubicación del centro de datos. Las tiendas de la UE quieren centros de datos en la UE. La latencia es real, el RGPD lo es aún más.
Snapshots baratos. La única característica que se paga sola la primera vez que la actualización de un módulo sale mal.
Documentación. Vas a pasar tiempo en su documentación. Si es pobre, eso te dice algo.

Si nunca has gestionado una máquina Linux, paga el extra por el servicio gestionado o por un panel de control. Un VPS mal configurado superará al alojamiento compartido en los benchmarks y rendirá peor en la vida real porque nadie parcheó el kernel.

Pila LEMP de base

# Debian 12 / Ubuntu 22.04
apt install nginx php8.2-fpm php8.2-mysql php8.2-curl \\
    php8.2-gd php8.2-intl php8.2-mbstring php8.2-xml \\
    php8.2-zip php8.2-opcache mariadb-server redis-server -y
mysql_secure_installation

¿Nunca has gestionado un servidor Linux? Empieza con un VPS gestionado o un panel. Un VPS de bricolaje estropeado es peor que el alojamiento compartido. Nuestra guía de fortalecimiento de la seguridad cubre qué hay que blindar una vez que esté en marcha.

Dedicado y nube: cuando el VPS no basta

Sube de nivel cuando tengas más de 50.000 productos, más de 5.000 visitantes diarios sostenidos, una multitienda con cinco o más tiendas compartiendo la máquina, o un requisito real de disponibilidad del 99,99 %.

Una máquina dedicada de 64 GB / NVMe de un proveedor europeo puede situarse en 40-60 EUR/mes: más capacidad de la que la mayoría de las tiendas usarán jamás, pero la diferencia de precio-rendimiento frente a un VPS en la nube con la misma especificación es difícil de rebatir.

El orden de escalado, cuando de verdad necesites escalar: lleva primero MySQL a su propio servidor (el mayor salto individual), luego pon Redis en su propia instancia y después piensa en un balanceador de carga con varios servidores de aplicación; y llegado ese punto también necesitarás almacenamiento compartido y sesiones en Redis, así que no te saltes pasos.

Configuración del servidor para PrestaShop

nginx, no Apache

Apache es la opción por defecto porque el alojamiento compartido lo usa, no porque encaje mejor. nginx usa E/S orientada a eventos (10-30 MB por proceso frente a 300-800 MB de Apache prefork), sirve archivos estáticos sin pasar por PHP y trae una caché FastCGI lista para usar.

Si estás atado a Apache, ejecuta mpm_event con PHP-FPM, nunca mpm_prefork con mod_php. Esto último es el despliegue de PrestaShop más lento que hemos visto en el mundo real.

Ajustes de PHP-FPM

pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10
pm.max_requests = 500
php_admin_value[memory_limit] = 512M
php_admin_value[max_execution_time] = 300

La fórmula que usamos para pm.max_children: (RAM en MB - huella de MySQL - SO) / 50 MB por proceso. En una máquina de 4 GB: (4000 - 1500 - 500) / 50 = 40. Ponemos entre 20 y 30 para dejar margen, porque un pool de FPM saturado significa 502 en la cara del cliente.

Ajuste de MySQL

[mysqld]
innodb_buffer_pool_size = 2G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2
tmp_table_size = 64M
max_heap_table_size = 64M
slow_query_log = 1
long_query_time = 1

Activa el registro de consultas lentas el primer día. Una sola consulta mala ejecutándose 200 veces por página supera cualquier diagnóstico de «servidor lento» que hayamos hecho, y el registro es como la encuentras. Nuestra guía de rendimiento repasa qué hacer una vez que tengas identificados a los culpables.

Redis para sesiones y caché

PrestaShop pone las sesiones y la caché en disco de forma predeterminada. Mueve ambas a Redis y las páginas de administración dejarán de bloquearse por el bloqueo de sesiones del sistema de archivos, que es la causa más común de los tickets de «el panel de administración va lentísimo» que abrimos. Redis te cuesta entre 50 y 100 MB de RAM y lo devuelve de inmediato.

SSL/TLS: no es opcional

Toda tienda necesita HTTPS. Google penaliza el HTTP en el posicionamiento, los navegadores lo señalan y ningún proveedor de pago funcionará sin él. El debate ha terminado.

Let's Encrypt

Gratis, automático, renovación cada 90 días. Certbot lo instalas una vez y te olvidas de él:

apt install certbot python3-certbot-nginx -y
certbot --nginx -d yourshop.com -d www.yourshop.com

SSL de Cloudflare

Gratis a través de su proxy, con una trampa: usa siempre Full (Strict). El modo Flexible envía texto plano entre Cloudflare y tu origen, lo que anula todo el propósito. Establece X-Forwarded-Proto para que PrestaShop sepa que está detrás de HTTPS aunque el salto al origen sea más bien HTTP.

Forzar HTTPS

Actívalo en Parámetros de la tienda → General, luego añade la redirección del servidor:

# Nginx
server {
    listen 80;
    server_name yourshop.com;
    return 301 https://yourshop.com$request_uri;
}

# Apache (.htaccess)
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

CDN: cuándo y cómo

Si sirves una sola región desde un servidor local, la CDN no te aporta mucha velocidad. Lo que sí te aporta es la caché de los recursos estáticos y una capa gratuita contra ataques DDoS.

El plan gratuito de Cloudflare cubre la mayoría de tiendas: CDN global, SSL gratis, DDoS básico, HTTP/2, Brotli. Configúralo en Parámetros avanzados → Rendimiento → Servidores multimedia.

Cachea de forma agresiva: imágenes, CSS, JS, fuentes.
Nunca cachees: administración, carrito, proceso de compra, mi cuenta, cualquier cosa que toque una cookie de PrestaShop.

Nunca actives «Cache Everything» para todo el dominio. Lo hemos visto: un cliente ve el carrito de otro cliente porque el proceso de compra se cacheó en el edge. Cachea solo recursos estáticos y patrones de URL concretos.

Copias de seguridad: los snapshots del proveedor no son una estrategia

Las copias del proveedor suelen ser semanales, se ejecutan sobre la misma infraestructura y tienen una probabilidad no nula de no restaurarse cuando las necesites. Eso es una manta de seguridad. Si el proveedor tiene una mala noche, las copias se van con la tienda. Si un ransomware cifra tus archivos, las versiones cifradas se respaldan diligentemente. Y probablemente quieras una base de datos de hace dos horas, no del martes pasado.

Lo que quieres, como mínimo: volcados automáticos diarios de la base de datos más copias de los archivos, almacenadas fuera del servidor de producción, conservadas durante 30 días y con una restauración de prueba cada mes. Programa esos trabajos en un lugar visible; MPR Cron Manager es la opción del lado de PrestaShop cuando quieres que las tareas de copia de seguridad estén controladas en lugar de ocultas en líneas anónimas del crontab. Nuestra guía de copias de seguridad tiene el procedimiento.

Migrar entre alojamientos

Aprovisiona el nuevo servidor con la misma versión de PHP y las mismas extensiones.
Vuelca la base de datos: mysqldump -u root -p prestashop_db | gzip > backup.sql.gz
Sincroniza los archivos: rsync -avz /var/www/html/prestashop/ newserver:/var/www/html/prestashop/
Importa la base de datos en el nuevo servidor.
Actualiza las credenciales en app/config/parameters.php.
Corrige los permisos: chown -R www-data:www-data, directorios 755, archivos 644.
Limpia la caché: rm -rf var/cache/*
Prueba vía /etc/hosts: apunta tu portátil a la nueva IP y recorre el proceso de compra y la administración antes que nadie.
Baja el TTL de DNS a 300 segundos 24 horas antes del cambio.
Sincronización final de la base de datos justo antes de cambiar el DNS, para no perder los últimos pedidos.

Dónde fallan las migraciones

Propiedad de los archivos. El usuario web tiene que ser el propietario de los archivos. cache, img, upload y download deben tener permisos de escritura.
.htaccess ausente. Las interfaces gráficas de migración tienden a saltarse los archivos ocultos. Apache también necesita AllowOverride All para respetarlo.
Desajuste de la URL base. Si el dominio ha cambiado, actualiza ps_shop_url o se romperán todos los enlaces.
Salto de versión de PHP. Pasar de 7.4 a 8.1 rompe cualquier módulo que siga llamando a funciones obsoletas.

Nunca cambies el DNS antes de haber probado vía /etc/hosts. Hemos visto dos migraciones romper el proceso de compra en producción porque nadie hizo clic en «comprar» en el nuevo servidor primero.

Señales de alarma: márchese cuando vea estas

Técnicas

Sin SSH. No puedes desplegar, no puedes depurar, no puedes ejecutar ninguna de las herramientas que de verdad arreglan problemas.
PHP 7.x en 2026. Fin de vida. Vulnerabilidades conocidas que no se van a parchear.
Sin OPcache. De 3 a 5 veces más lento que el mismo código con OPcache activado. No hay razón para ello.
Almacenamiento HDD. Si no dicen SSD o NVMe por escrito, asume HDD.
php.ini bloqueado. No puedes ejecutar PrestaShop correctamente sin elevar al menos memory_limit.

De negocio

«Ilimitado» lo que sea. Nada es ilimitado. Estrangulan a los inquilinos ruidosos en lugar de decirlo.
Marcas de un grupo holding. Cinco hosts «distintos» propiedad del mismo grupo, todos sobre la misma chatarra sobrevendida, con logotipos diferentes.
Sin SLA de disponibilidad. No confían lo suficiente en su propia infraestructura como para ponerle un número.
El soporte responde en días. Una caída a las 2 de la madrugada necesita minutos, no «el siguiente día laborable».
Facturación anual forzada. Cuentan con que no te vayas cuando te des cuenta de que fue un error.

El alojamiento más barato es el que se mantiene en pie durante el Black Friday. Ahorrar 5 $/mes en un host que te hace perder 5.000 $ en conversiones a lo largo de un fin de semana no es ahorrar nada.

Lista de comprobación previa a la compra

Cada línea de aquí importa. Ve marcándolas antes de meter una tarjeta.

Servidor

La versión de PHP coincide con la de tu PrestaShop
Todas las extensiones de PHP requeridas disponibles (intl, mbstring, gd como mínimo)
php.ini es configurable (memory_limit, ajustes de OPcache)
MySQL o MariaDB en una versión que PrestaShop admita de verdad
SSD o NVMe por escrito
Acceso SSH
Frecuencia de cron sin restricciones

Rendimiento

OPcache activado y configurable
4 GB+ de RAM en el plan que estás eligiendo, o 2 GB para una tienda pequeña que empieza con PrestaShop 1.7
HTTP/2 activado
Redis o Memcached disponible

Fiabilidad

SLA de disponibilidad del 99,9 % o mejor
Opciones de copia de seguridad automáticas y manuales
Respuesta de soporte crítico medida en horas, no en días
Centro de datos cerca de tus clientes

Precio

Precio de renovación (no el de entrada) comprobado
Facturación mensual disponible
Límites de ancho de banda o transferencia entendidos
Sin cláusula que te impida migrar a otro sitio

En qué le pondríamos, según la etapa

Tienda recién creada: VPS en la nube con al menos 4 GB de RAM para PrestaShop 8 o 9, o 2 GB para una tienda pequeña con PrestaShop 1.7, más una CDN gratuita y Let's Encrypt. Supera de calle a la mayoría del compartido de 15 $/mes.
Tienda en crecimiento: VPS gestionado a 15-30 $/mes. Paga a alguien para mantener el SO parcheado mientras tú te centras en vender.
Consolidada (más de 1.000 visitantes al día): VPS con 8-16 GB de RAM, MariaDB ajustada, Redis activado, nginx con caché FastCGI. Con 15-40 $/mes llegas ahí.
Catálogo grande o tráfico intenso: servidor dedicado (un dedicado europeo barato supera al VPS en la nube a esta escala) o una arquitectura en la nube debidamente separada. 50-100+ $/mes y vale cada céntimo.

Configura la monitorización de disponibilidad el primer día: UptimeRobot es gratis para 50 monitores y suficientemente bueno. Una vez resuelto el alojamiento, el resto del trabajo de optimización tiene un sitio sólido donde aterrizar.

Lecturas relacionadas

Optimización del rendimiento de PrestaShop: acelere su tienda: qué ajustar una vez resuelto el alojamiento
Refuerzo de seguridad de PrestaShop: la lista completa: blindaje a nivel de servidor
Solución de problemas de PrestaShop: corregir pantallas blancas y errores 500: cuando el host es el problema y necesitas demostrarlo
Copias de seguridad de PrestaShop: copias reales, no mantas de seguridad: el procedimiento que usamos nosotros mismos
Performance Revolution: uno de nuestros módulos; combina bien con un VPS bien dimensionado