Hosting para Laravel y Aplicaciones PHP Modernas [2026]

Laravel tiene requisitos de servidor que el hosting compartido estándar no puede cubrir. Necesita PHP 8.2+ con extensiones específicas, acceso a Composer, control sobre la configuración del servidor web, y — en producción real — procesos en background para queues y el scheduler. La buena noticia: tienes más opciones que nunca para desplegarlo sin ser sysadmin.

Requisitos técnicos de Laravel 11 (2026)

Antes de elegir servidor, confirma que cumple estos requisitos mínimos:

El acceso SSH no es negociable. Sin él, no puedes ejecutar php artisan migrate, composer install, ni gestionar colas. El hosting compartido estándar queda descartado para cualquier proyecto Laravel serio.

El problema con el hosting compartido para Laravel

El hosting compartido (cPanel, Plesk) no es compatible con Laravel en la mayoría de casos, por varias razones concretas:

1. El document root de Laravel es /public, no la raíz del dominio. En cPanel, el dominio principal apunta a public_html/. Para que Laravel funcione, necesitas que apunte a public_html/proyecto/public/ — algo que muchos hostings compartidos no permiten cambiar para el dominio principal.

2. Sin acceso a cron a nivel de sistema. Laravel Scheduler requiere una entrada en crontab: * * * * * cd /ruta/proyecto && php artisan schedule:run >> /dev/null 2>&1. Algunos hostings solo permiten cron jobs cada 15 minutos como mínimo, lo que rompe el scheduler.

3. Sin control de procesos. Queue workers (php artisan queue:work) son procesos persistentes. En hosting compartido se matan automáticamente después de X segundos. Supervisor, pm2 o equivalentes no están disponibles.

Excepción real: Proyectos Laravel muy simples (sin colas, sin scheduler, sin websockets) pueden funcionar en hostings que ofrecen SSH, Composer y permiten redireccionar el document root. Webempresa y Raiola Networks lo permiten, pero es una excepción, no la norma.

Opción 1: VPS no gestionado — máximo control, máxima responsabilidad

La ruta clásica: un VPS Linux (Ubuntu 24.04 LTS) donde configuras todo desde cero. Requiere conocimientos de administración de sistemas.

Stack recomendado:

• Ubuntu 24.04 LTS
• Nginx + PHP-FPM 8.3
• MySQL 8.0 o PostgreSQL 16
• Redis (colas y caché)
• Supervisor (gestión de workers)
• Let’s Encrypt / Certbot

Tiempo de configuración inicial: 2-4 horas para alguien con experiencia. Sin experiencia, puede ser un día o más.

Proveedores recomendados para VPS bare metal en Europa:

Para proyectos Laravel en producción con tráfico real, el plan mínimo recomendable es 2 GB RAM. Con 1 GB, PHP-FPM + MySQL + Redis juntos pueden quedarse sin memoria.

Opción 2: VPS con panel de gestión — el punto medio inteligente

La opción más popular para equipos que quieren control sin gestionar servidores a mano. Un panel como Laravel Forge o Ploi automatiza la configuración del servidor, deployments, SSL, colas y cron.

Laravel Forge (forge.laravel.com):

• 12$/mes por servidor (ilimitados sitios por servidor)
• Configura automáticamente Nginx, PHP-FPM, MySQL/PostgreSQL, Redis, Supervisor
• Deploy hooks: push a main → deploy automático vía webhook
• Gestión de colas y scheduler desde la UI
• Compatible con cualquier VPS (Hetzner, DigitalOcean, AWS, Vultr…)
• Certificados SSL automáticos
• El coste real: Forge (12$/mes) + VPS (5-15€/mes) = 17-27€/mes total

Ploi (ploi.io):

• 8€/mes para hasta 3 servidores (más barato que Forge)
• Funcionalidad muy similar a Forge
• Interfaz más moderna y, según muchos usuarios, más rápida
• Soporte para PHP 8.x, Node.js, Python, Ruby

Coolify (self-hosted, gratis):

• Alternativa open source gratuita
• Instalar en un VPS propio (recomendado: 2 GB RAM mínimo para Coolify + apps)
• Soporta Docker, PHP, Node.js, bases de datos
• Requiere más tiempo de configuración inicial, pero sin coste de suscripción

La combinación Hetzner (CAX21: 2 vCPU ARM, 4 GB RAM, 40 GB NVMe = 5,77€/mes) + Ploi (8€/mes) da un stack de producción serio por menos de 14€/mes. Es la opción más popular entre desarrolladores Laravel del mercado español en 2026.

Opción 3: PaaS — deploy sin gestionar infraestructura

Las plataformas como servicio (PaaS) abstraen completamente la infraestructura. Haces push a Git y la plataforma construye, despliega y gestiona el servidor.

Nota sobre Vercel: Vercel funciona con funciones serverless, no con procesos persistentes. Puedes desplegar un Laravel básico, pero sin queue workers, sin scheduler real, sin WebSockets. Para Laravel completo, Vercel no es la opción adecuada.

Railway es la PaaS más equilibrada para Laravel en 2026 si no quieres gestionar infraestructura. Con el plan Hobby (5$/mes) tienes un servicio web (Laravel) + un servicio de colas (worker PHP artisan queue:work) + Redis + MySQL gestionados. El coste escala con el uso — un proyecto pequeño puede quedarse en 10-15$/mes total.

Configuración del servidor web para Laravel

La configuración de Nginx para Laravel requiere algunos ajustes específicos:

server {
    listen 80;
    server_name tudominio.com;
    root /var/www/laravel/public;
    index index.php;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }

    client_max_body_size 100M;
}

Lo crítico: el root apunta a /public (no a la raíz del proyecto), y el bloque location / con try_files habilita las rutas de Laravel.

Queue workers y Supervisor

Las colas son uno de los puntos de ruptura más frecuentes al migrar Laravel a producción. Necesitas Supervisor para mantener el worker activo:

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/laravel/artisan queue:work redis --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=www-data
numprocs=2
redirect_stderr=true
stdout_logfile=/var/www/laravel/storage/logs/worker.log
stopwaitsecs=3600

Con numprocs=2 tienes dos workers paralelos. Aumenta este número según el volumen de jobs. En VPS de 2 GB RAM, 2-4 workers es lo razonable.

Laravel Horizon (para proyectos que usan Redis como driver de colas) añade monitorización en tiempo real de los workers. Se configura en minutos y es altamente recomendable para proyectos en producción.

El scheduler de Laravel en producción

El scheduler requiere una sola entrada en crontab:

* * * * * cd /var/www/laravel && php artisan schedule:run >> /dev/null 2>&1

Este cron se ejecuta cada minuto y Laravel decide internamente qué tareas correr. Con Forge o Ploi, esto se configura desde la UI sin tocar el crontab directamente.

Base de datos: opciones y recomendaciones

Para proyectos pequeños y medianos, MySQL en el mismo VPS es perfectamente válido y más económico. La complejidad operativa aumenta — necesitas gestionar backups — pero el rendimiento es excelente al evitar latencia de red entre aplicación y base de datos.

Deployment workflow en producción

Un flujo de deployment profesional para Laravel con Git + Forge/Ploi:

1. Push a main en GitHub/GitLab
2. Webhook notifica a Forge/Ploi
3. Forge ejecuta el deploy script:

   cd /var/www/laravel
   git pull origin main
   composer install --no-dev --optimize-autoloader
   php artisan migrate --force
   php artisan config:cache
   php artisan route:cache
   php artisan view:cache
   php artisan queue:restart
   

4. Nginx sirve la nueva versión sin downtime (PHP-FPM sigue activo)
5. Los workers se reinician con queue:restart para cargar el nuevo código

Zero-downtime deployments más sofisticados requieren Deployer (deployer.org) o Laravel Envoyer (envoyer.io, 8$/mes). Crean un directorio nuevo para cada release y cambian un symlink atómicamente.

WebSockets con Laravel Reverb

Laravel Reverb (lanzado con Laravel 11) es el servidor de WebSockets oficial de Laravel. Se ejecuta como un proceso adicional en el mismo servidor:

php artisan reverb:start --host=0.0.0.0 --port=8080

Gestionado con Supervisor, igual que los queue workers. Requiere configuración de Nginx para hacer proxy del puerto 8080 bajo /app con soporte WebSocket:

location /app {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
}

Alternativas gestionadas: Pusher (gratuito hasta 200 conexiones simultáneas), Soketi (self-hosted, compatible con Pusher API).

¿Para quién es cada opción?

VPS no gestionado (Hetzner, Clouding.io, DigitalOcean):

• Desarrolladores con experiencia en Linux/sysadmin
• Proyectos donde el coste es crítico (desde 4€/mes)
• Equipos que ya tienen DevOps internos
• Aplicaciones con requisitos de configuración muy específicos

VPS + Forge/Ploi:

• Desarrolladores Laravel que no quieren administrar servidores
• Equipos pequeños (1-5 personas) con varios proyectos
• El punto medio ideal en 2026: control + conveniencia
• Presupuesto de 14-30€/mes por proyecto

PaaS (Railway, Fly.io, Render):

• Proyectos en fase inicial o con tráfico impredecible
• Desarrolladores que no quieren gestionar nada de infraestructura
• Aplicaciones que necesitan escalar automáticamente
• Equipos que prefieren pagar más a cambio de no operar servidores

No recomendado para Laravel:

• Hosting compartido estándar (sin SSH, sin Composer, sin control de procesos)
• Hostings de WordPress (configurados específicamente para WP, no para PHP genérico)
• Vercel (sin workers persistentes, arquitectura serverless incompatible con Laravel completo)

Alternativas a este setup

Si tu equipo ya usa Kubernetes o Docker en producción, considera Laravel Octane con Swoole o RoadRunner. Octane mantiene la aplicación cargada en memoria entre requests, reduciendo el TTFB hasta un 80% respecto a PHP-FPM tradicional. Requiere un servidor dedicado (no compartido) y gestión de estado más cuidadosa (evitar estado global en memoria).

Para proyectos más pequeños que no justifican un VPS, Laragon en local + Render en producción es un stack ágil que muchos freelancers usan en España para proyectos de clientes medianos.

Preguntas frecuentes

¿Puede Laravel funcionar en hosting compartido?

En contadas excepciones sí: si el hosting ofrece SSH, Composer, permite cambiar el document root a /public, y soporta cron jobs. Webempresa y Raiola Networks lo permiten. Pero sin control de procesos, las colas y el scheduler tienen limitaciones importantes. Para proyectos serios, un VPS es la respuesta correcta.

¿Cuánta RAM necesita un servidor Laravel en producción?

Mínimo 1 GB para proyectos muy pequeños (PHP-FPM + MySQL + Redis juntos usan ~600-800 MB en reposo). Para producción real con tráfico, 2 GB es el punto de partida razonable. Con Horizon y workers adicionales, 4 GB es más cómodo.

¿Laravel funciona con Apache?

Sí, con la configuración correcta de .htaccess. Laravel incluye un .htaccess por defecto en /public que habilita el routing. Sin embargo, Nginx con PHP-FPM tiene mejor rendimiento y es la combinación recomendada en producción.

¿Cuánto cuesta desplegar Laravel en producción en España?

El stack más económico viable: Hetzner VPS CX22 (3,79€/mes) + Ploi (8€/mes) = ~12€/mes. Con datacenter en España: Clouding.io 2 GB (6€/mes) + Ploi (8€/mes) = ~14€/mes. Los PaaS como Railway o Fly.io cuestan 15-30$/mes para proyectos con tráfico real.

¿Necesito Redis para Laravel?

No es estrictamente necesario, pero es altamente recomendable en producción. Redis mejora el rendimiento de las colas (mucho más eficiente que database o file como driver), la caché de sesiones, y la caché de aplicación. El coste adicional es mínimo: Redis consume ~50-100 MB de RAM.

¿Forge vale la pena frente a gestionar el servidor manualmente?

Para la mayoría de desarrolladores Laravel, sí. Forge ahorra horas en la configuración inicial (SSL automático, Nginx, PHP-FPM, Supervisor, cron) y en cada deployment. El coste de 12$/mes se amortiza rápidamente. La alternativa más económica: Ploi a 8€/mes con funcionalidad equivalente.