Precios de Laravel Cloud y Forge frente a tu propio servidor: lo que cuesta una app

Laravel Cloud factura el cómputo por segundos y deja de facturarlo mientras tu app está en reposo. Solo entra en reposo tras un periodo de inactividad igual a su tiempo de espera de reposo. Cada tarea programada la despierta durante ese mismo tiempo, así que una tarea cada 5 minutos con un tiempo de espera de 5 minutos nunca deja que el entorno entre en reposo. Si programas algo cada minuto, se te factura como si estuviera siempre encendida, hasta el límite de Cloud de 28 días por instancia al mes.

Si tu app puede estar en reposo la mayor parte del día, sin nada programado con más frecuencia que su tiempo de espera y con los trabajos en una cola administrada, el plan Starter de Laravel Cloud solo factura el cómputo del tiempo que está activa, más la cuota del plan, las operaciones de la cola y el almacenamiento y las copias de seguridad de la base de datos. Todas las facturas de abajo suponen que tu app nunca entra en reposo. Si tu app es un conjunto de contenedores Docker en lugar de una sola app de Laravel, lo que cuesta un contenedor siempre encendido en Fly.io, Cloud Run o Fargate calcula el precio de este mismo problema en plataformas de contenedores de pago por uso.

Lo que usó una app de Laravel en nuestro servidor de prueba (no es un servidor de DreamHost)

Desplegamos una app nueva de Laravel 13 en un servidor de prueba, dentro de un contenedor creado con los paquetes propios de Debian 13. Ejecutaba los mismos tres programas que incluye el LAMP Stack VPS, pero eran Apache, MariaDB y PHP 8.4 de Debian 13, no la imagen LAMP de DreamHost. Supervisor mantenía un worker de colas en marcha y una línea de cron ejecutaba el programador de tareas. El servidor tenía 2 vCPU, igual que Stack 4 y Stack 8.

A 200 peticiones por segundo, el p95 de esa página subió a 160 ms, aún sin errores. Para entonces, el generador de carga compartía los mismos dos núcleos, así que esperaríamos un resultado algo mejor en un servidor donde no ocurra. Una ruta básica de Laravel sin llamadas a la base de datos se mantuvo por debajo de 17 ms en el percentil 95 hasta 400 peticiones por segundo. Como referencia, el caso S3 (más abajo) supone 3 millones de peticiones al mes, una media de unas 1,2 por segundo.

Incluso en ese pico de 572 MiB, los 4 GB de Stack 4 dejarían unos 3 GB libres, según nuestros cálculos. Pero tu app en producción tendrá más código y datos que nuestra instalación nueva, y si añades workers para una cola con más actividad, cada uno ocupa unos 55 MiB. Para producción, te recomendaríamos Stack 8, con el doble de memoria que Stack 4.

Lo que cuesta la app en tres tamaños

Las facturas siguientes usan los precios de Laravel para su región US East (Virginia). Cada una supone que tu app responde a cualquier hora y programa una tarea cada minuto, así que el cómputo y la base de datos permanecen activos todo el mes. Restamos el crédito de uso de 5 $ que incluye cada plan de pago. Para las copias de seguridad tomamos el caso bajo, con un almacenamiento de instantáneas igual al volumen de datos. S1 ejecuta el worker en la propia instancia de 1 GiB de la app. A juzgar por nuestro servidor de prueba, donde la app completa, base de datos incluida, alcanzó un pico de 572 MiB, esa instancia tiene espacio suficiente. S2 y S3 envían los trabajos a una cola administrada que, según la documentación de Laravel, sustituye a un worker dedicado.

Incluso la pequeña factura de S1 supera el precio mensual normal de Stack 8, y la diferencia crece rápido: S2 lo triplica con creces. S3, unas 11 veces más cara, paga dos réplicas y una caché para atender un tráfico de una media de unas 1,2 peticiones por segundo, muy por debajo de las 100 por segundo que soportó nuestro servidor de prueba. En el servidor no añadirías una caché Valkey, porque Laravel 13 guarda por defecto la caché, las sesiones y la cola en la base de datos. Si usas Forge, suma los 12 $ al mes del plan Hobby al precio del servidor en cualquiera de los tres casos.

El ejemplo de la propia documentación de Laravel para una Medium SaaS application sale más barato, unos 53,90 $ al mes, porque usa las tarifas de US East (Ohio), no incluye la cuota del plan y deja el cómputo en reposo por las noches y los fines de semana.

En S1 y S2, la base de datos cuesta más que la instancia de la app a la que da servicio. Además, Laravel MySQL sigue facturando el almacenamiento y las copias de seguridad mientras está en reposo. Las copias de seguridad podrían llegar a 3,50 $ al mes si cada instantánea diaria ocupara el tamaño completo. Aquí los datos de salida salen gratis porque la instancia Flex 1 GiB de S1 incluye 100 GB al mes. En S3, los datos de salida ya son el mayor concepto de uso: las dos réplicas Pro solo tienen una asignación de 200 GB, y los otros 800 GB cuestan 80,00 $. En el LAMP Stack VPS no pagas el ancho de banda por GB. Es sin límite y sin cargos por exceso, según las condiciones de uso razonable de DreamHost.

La tarifa de Forge se suma a la del servidor

Forge puede funcionar en un servidor que ya alquilas mediante su opción Custom VPS. Ese servidor debe ser una instalación nueva de Ubuntu 24.04 o 26.04 x64 con acceso SSH como root. Después, el propio Forge instala Nginx, PHP, la base de datos y Redis. En DreamHost, eso significa un VPS con Ubuntu, que se vende a los mismos precios de Stack que el LAMP Stack VPS. La imagen LAMP no sirve, porque llega con Apache y MariaDB ya en marcha. Si estás dudando entre los dos servidores web, consulta Apache o Nginx para PHP.

Así que, en un servidor de DreamHost, Forge cuesta su cuota más el mismo precio de Stack que pagarías por gestionar la app tú mismo. A cambio de esa cuota, Forge configura el servidor, despliega con cada push y escribe las entradas de Supervisor y cron, lo que cubre la mayoría de los pasos siguientes.

Lo que gestionas tú en el servidor LAMP

Nuestro servidor de prueba necesitó estos cuatro pasos además de Apache, MariaDB y PHP, sin ningún panel de control. Si aun así quieres un panel en el servidor, nuestra guía alternativas gratuitas a cPanel en tu propio VPS mide cuánta memoria y disco consumen HestiaCP, CloudPanel y Virtualmin. Las rutas dan por hecho que tu app está en /var/www/app y se ejecuta como www-data.

1. Instala Composer y Supervisor

   Ambos están en el repositorio de paquetes propio de Debian 13. Omite cualquiera de los dos si tu servidor ya lo tiene.

   bashCopiar

   sudo apt install composer supervisor

2. Añade el worker de cola a Supervisor

   Guárdalo como /etc/supervisor/conf.d/laravel-worker.conf. Es el propio ejemplo de Laravel con la ruta, el usuario y el número de workers adaptados a una sola app. Movimos el log a /var/log, porque el Supervisor de nuestro servidor de prueba se negaba a arrancar mientras no existiera la carpeta de logs dentro de la app.

   iniCopiar

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

   Después, cárgalo con sudo supervisorctl reread, sudo supervisorctl update y sudo supervisorctl start "laravel-worker:*".

3. Añade la línea de cron del programador de tareas

   Guarda esta línea como /etc/cron.d/laravel. Es la única entrada de cron de Laravel, con la ruta y el usuario ya rellenados.

   bashCopiar

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

4. Despliega con un script

   Ejecuta esto desde la carpeta de la app en cada versión. En nuestras tres pruebas, todo lo posterior al cambio de código tardó alrededor de 1,5 segundos, la mayor parte en composer install. Durante ese tiempo, el sitio estuvo en modo de mantenimiento. El primer despliegue de una app nueva tardó 19 y 29 segundos en nuestras dos pruebas, casi todo mientras Composer descargaba paquetes.

   bashCopiar

   php artisan down --retry=5
   git pull
   composer install --no-dev \
     --optimize-autoloader --no-interaction
   php artisan migrate --force
   php artisan optimize
   php artisan queue:restart
   php artisan up

Cuándo tiene sentido cada opción

Con el tamaño de S1, la factura de Laravel Cloud queda un poco por encima de la tarifa mensual normal de Stack 8. Una app tan pequeña también cabe en Stack 4, que conserva unos 3 GB libres en nuestra lectura más alta. Las diferencias grandes empiezan en S2, donde Stack 8 deja margen para que la app crezca.

El soporte de DreamHost está disponible 24/7, y el equipo de DreamHost se encarga del hardware, la red y la conectividad. Tú gestionas el sistema operativo, el software y la configuración, que en este caso es la app. En nuestra prueba, Composer, Supervisor y cron se configuraron una sola vez, y a partir de ahí cada versión fue un único script. Después, las tareas mensuales se limitan a aplicar las actualizaciones del sistema operativo y comprobar que las copias de seguridad se han ejecutado.

Cómo probamos la app y consultamos los precios

DreamHost consultó las páginas de precios de Laravel Cloud, Forge y DreamHost el 20 de octubre de 2026, y su documentación entre el 19 y el 21 de octubre, y realizó la prueba el 20 de octubre. Volvimos a comprobar cada plan, precio y característica de DreamHost de esta página con las páginas de DreamHost el 22 de octubre de 2026.

El servidor de prueba era una VM arm64 con 2 vCPU y 8 GB con Ubuntu 24.04, con la app en un contenedor creado con paquetes de Debian 13. No era un servidor de DreamHost ni la imagen LAMP de DreamHost, y los planes VPS de DreamHost funcionan con procesadores AMD EPYC.

El contenedor ejecutaba los paquetes de Apache 2.4, PHP 8.4 y MariaDB 11.8 de Debian 13, con Laravel 13.38. En reposo, MariaDB ocupaba 123 MiB, Apache y PHP 123 MiB y el worker 55 MiB; esos procesos comparten memoria, así que sus cifras suman más que el total de 208 MiB.

Cada paso de carga duró un minuto. En los redespliegues cronometrados, un cambio de código local sustituyó a git pull. No se ejecutó nada en Laravel Cloud ni en Forge, así que sus columnas proceden de las tarifas publicadas. La prueba no refleja directamente tráfico real, HTTPS, PHP-FPM ni un servidor de 4 GB.

Preguntas frecuentes sobre el coste del hosting de Laravel