Hosting Laravel pensado para tu forma de desplegar

Sí. Cada plan incluye un shell SSH completo, así que desplegar es el mismo flujo basado en Git que ya usas en local. Clona tu repositorio directamente desde GitHub, GitLab o Bitbucket dentro de tu cuenta, ejecuta composer install para traer tus paquetes vendor y luego copia tus valores de producción al .env. A partir de ahí Artisan toma el control: php artisan key:generate define la clave de tu app y php artisan migrate construye el esquema de tu base de datos. Publicar una versión posterior es igual de rápido: git pull para traer los nuevos commits, composer install para actualizar dependencias, php artisan migrate para cualquier migración nueva y un refresco de caché para limpiar la configuración anterior. Como tienes un shell de verdad y no un panel cerrado, puedes revisar logs en vivo, corregir permisos de storage y volver a ejecutar cualquier comando si algo necesita una segunda mirada. Apunta el document root a la carpeta public y el sitio queda en línea por HTTPS.

Sí: Composer está instalado en todas las cuentas y ya en tu PATH, así que no hay nada que descargar, descomprimir ni configurar antes de tu primer despliegue. Abre una sesión SSH en cuanto se aprovisione tu cuenta y composer install, composer update, composer require y composer dump-autoload funcionan de inmediato con el binario de PHP correcto. Eso importa en Laravel, porque el framework y casi todos los paquetes que agregas, desde los starter kits hasta Sanctum, Horizon y el resto, se traen mediante Composer en lugar de subirse al repositorio. Conservas tu propio composer.json y composer.lock, así que las versiones que pruebas en local son las versiones que aterrizan en el servidor. Si alguna vez necesitas ejecutar Composer con una versión concreta de PHP, puedes hacerlo, ya que la versión de PHP se elige por sitio. En resumen, tu flujo de dependencias se comporta exactamente igual que en tu propia máquina.

Tienes PHP 8.x moderno y tú eliges qué versión usa cada sitio desde el panel de control. Esa flexibilidad importa porque cada versión de Laravel declara un requisito mínimo de PHP: las versiones recientes esperan PHP 8.1 o superior, mientras que una app antigua con soporte a largo plazo puede estar fijada a una build 8.x anterior. En lugar de imponer un solo runtime a todo, defines la versión por dominio, así un proyecto heredado de un cliente y una app recién estrenada pueden convivir en la misma cuenta sin conflictos. Junto al selector puedes ajustar los parámetros que a Laravel le importan: memory_limit para comandos Artisan e importaciones más pesados, max_execution_time para tareas largas y OPcache para que tu código compilado se mantenga caliente en memoria. Cambiar de versión es instantáneo y reversible, lo que hace que probar una actualización de PHP sea de bajo riesgo: sube primero un dominio de staging, confirma que tu suite de pruebas pasa y luego mueve producción con un solo clic.

Ambos son ciudadanos de primera clase aquí. Para el trabajo en cola, arranca un worker permanente con php artisan queue:work para que trabajos, notificaciones, mailables y exportaciones pesadas corran fuera de la petición web en lugar de bloquear la carga de página de un visitante. Respalda la cola con Redis y los trabajos se toman y se procesan rápido incluso con tráfico real. Para el trabajo programado no agregas una larga lista de líneas de cron separadas. En su lugar registras todo dentro del planificador de Laravel en el código de tu app y luego agregas una sola entrada de cron que ejecute php artisan schedule:run cada minuto. Desde esa única tarea, Laravel decide qué comandos toca ejecutar y los dispara: resúmenes cada hora, limpiezas nocturnas, informes semanales y demás. Después de cada despliegue, ejecuta php artisan queue:restart para que tus workers carguen el código nuevo. Es la configuración estándar de Laravel funcionando exactamente como describe la documentación, sin trucos específicos de la plataforma que aprender.

Sí. Redis está disponible para caché, almacenamiento de sesiones y colas, que es la combinación a la que recurren la mayoría de las apps Laravel en producción. Apunta tu driver de caché a Redis y los resultados de consultas costosas, los fragmentos renderizados y los valores calculados se sirven desde memoria en lugar de reconstruirse en cada visita. Mueve las sesiones a Redis y el estado de los usuarios autenticados se mantiene rápido y consistente a medida que crece el tráfico. Configura tu conexión de colas en Redis y los trabajos en segundo plano se encolan y procesan con muy poca sobrecarga, así los workers siguen respondiendo durante los picos. Todo esto se conecta desde tu .env con los ajustes estándar de driver de caché, sesión y cola: no hace falta ninguna configuración a medida de nuestro lado. Como Redis mantiene ese conjunto de datos en RAM y no en disco, las páginas que antes se sentían pesadas se vuelven notablemente más ágiles, y el procesamiento en segundo plano sigue el ritmo en lugar de acumularse cuando llega una ráfaga de tráfico.

Sí, y es la forma correcta de servir una app Laravel. Laravel mantiene un único punto de entrada en su directorio public y guarda el código de tu aplicación, el .env y storage por encima de la raíz web, así que nada sensible es accesible desde internet. Desde el panel de control defines el document root de tu dominio en la carpeta public de tu proyecto, y las peticiones fluyen por index.php exactamente como el framework pretende. Combinado con SSL gratis de renovación automática, tu app responde por HTTPS con URLs limpias y sin index.php en la barra de direcciones. Los permisos de directorio en storage y bootstrap/cache son sencillos de ajustar por SSH, así que la caché, las sesiones y las subidas de archivos funcionan a la primera. Si alojas varias apps en una cuenta, cada dominio tiene su propio document root apuntando a su propia carpeta public, manteniendo los proyectos bien separados mientras comparten el mismo servidor NVMe rápido por debajo.

Yes. Our team transfers your codebase, exports and imports your MySQL database, and carries over your storage folder so uploaded files and cached data aren't left behind. We bring everything up on a temporary address first so you can confirm queues, the scheduler and Redis-backed sessions all still work, and only then do we walk through the DNS cutover.

Yes, daily backups cover your database and storage directory, giving you a restore point that sits alongside your own Git-based code rollbacks. If a migration or seed command goes wrong, you can restore the previous day's snapshot rather than trying to reverse the damage by hand.

Yes. Addon domains let you point a staging subdomain and your live domain at the same account, each with its own document root and database. Push and test on staging first, run your Artisan migrations there, and only promote to the production domain once you're confident.

Higher tiers support up to 100 MySQL databases, which in practice means room for several Laravel projects — a mix of client sites, side projects and staging copies — on a single account, each with its own domain, database and .env.

Every plan is covered by a 30-day money-back guarantee, so you can deploy your actual project, run it under real traffic, and check queue throughput and Redis caching behave the way you expect before committing beyond the trial period.

Plans are priced in USD starting at $2.42/mo, and geo-currency detection displays that price converted into your local currency at checkout, so what you see is what gets billed rather than a rate you have to calculate yourself. Billing itself runs through Bohzo Ltd (UK).