Laravel Cloud CLI salió de beta con un camino corto: instalar la CLI, autenticarse y ejecutar cloud ship. El terminal administra el deploy y recursos de base de datos, cache, storage y dominios sin exigir el dashboard en el flujo normal.
Esto cierra una brecha de experiencia alrededor de PHP. Los equipos Laravel solían montar configuración de servidores, pipelines, Forge y servicios cloud antes de llegar a usuarios. Un comando integrado acerca un servicio nuevo a los flujos asociados con Vercel o plataformas modernas de Rails.
La comodidad tiene una curva de precio. Starter no tenía mensualidad fija y podía hibernar, con una instancia pequeña cerca de cinco dólares mensuales. Growth empezaba en veinte y Business en doscientos; compute mayor alcanzaba importes bastante más altos por instancia. El precio de entrada no describe la factura con tráfico sostenido.
El primer ship y el deploy de rutina son trabajos distintos
cloud ship es un flujo guiado: detecta el repositorio, pide región y nombre, y puede sincronizar .env, crear base o cache y activar scheduler, Octane o WebSockets. Sirve para poner la aplicación en el aire sin abrir el dashboard. La documentación de la CLI lo separa de cloud deploy, que resuelve aplicación y entorno a partir de la configuración del repositorio y sigue el progreso.
Tratar ambos como el mismo atajo oculta el trabajo permanente. La rutina pide cloud repo:config (grava application_id y organization_id en .cloud/config.json), deploy desde CI, monitoreo y rollback. La CLI expone --json y autenticación por token para GitHub Actions y entornos sin TTY. La comodidad en el portátil de desarrollo no es el contrato de producción.
Antes de estandarizar Cloud para el equipo, describan el camino de un merge hasta el entorno estable: quién dispara el deploy, qué cuenta como salud, quién revierte, dónde vive el log. Si la respuesta es "alguien vuelve a ejecutar ship", todavía tienen un atajo de bootstrap, no una operación.
La API REST cubre lo que cubre el dashboard. Entornos de feature branch, teardown después del PR, horarios de scale to zero y alertas en el stack de observabilidad existente pasan a ser script. Esa es la ganancia real para un equipo que ya tiene pipeline. El comando único en el terminal es la puerta de entrada.
El plan barato describe la entrada, no la factura acordada
La página de precios lista Starter a 5 dólares al mes más uso (primer mes gratis y crédito de uso), Growth a 20 y Business a 200, todos más consumo. Flex en Starter hiberna y despierta en menos de 500 ms. Growth añade compute Pro, autoscaling hasta 10 réplicas, preview environments y roles de equipo. Business amplía autoscaling, WAF y retención de log. Se puede poner techo de gasto: alerta al 50%, 80% y 100%, y el compute pausa en el límite.
La hoja operativa necesita tres filas, no una. Base del plan. Compute, base, cache, cola y storage mientras están despiertos. Costo de permanecer despierto todo el mes si la hibernación no aplica. Un SaaS con workers 24 h no comparte perfil con un sitio que duerme. Comparar solo los 5 dólares de entrada con un VPS suelto mezcla productos.
Yo usaría el estimador de la propia página con las horas despiertas del producto, no con el escenario de hobby. Después compararía con Forge (ustedes operan el servidor) y Vapor (Lambda y consola AWS). Cloud vende infraestructura gestionada en EC2. El precio incluye esa operación. Esconderlo en la conversación de "deploy en 30 segundos" empuja la sorpresa al mes en que el tráfico deja de ser esporádico.
El techo de gasto evita una factura sin control. No evita la conversación de capacidad: si el compute pausa en el techo, el producto se cae. Quien usa el techo como defensa necesita alerta y un dueño despierto para subir el límite o recortar réplicas.
La comodidad en el terminal no porta el estado gestionado
Salir de la plataforma nunca es el inverso de cloud ship. Base gestionada, cache, bucket, dominio, cola, variable de entorno, proceso en background y clúster de WebSocket se quedan en el proveedor. La CLI ayuda a listar, volcar y destruir. No empaqueta un artefacto único que arranca en otro sitio con el mismo comando.
Antes de concentrar producción en Cloud, escriban la prueba de salida en una página. Cómo se exporta la base. Dónde se copia el objeto en storage. Qué DNS apuntan al edge de la plataforma. Qué jobs no pueden perder mensajes en el cambio. Si el equipo no puede responder eso en una tarde, el costo de salida sigue opaco. La opacidad es el lock-in, más que la ausencia de un botón "exportar cuenta".
.cloud/config.json en el repositorio ata el proyecto a IDs de la organización. Es útil en el día a día y es un acoplamiento explícito. Trátenlo como el vercel.json de otro ecosistema: comodidad con dirección fija. La aplicación Laravel sigue siendo código PHP; la operación alrededor (región, tamaño de instancia, hibernación, WAF) no viaja con ella.
Forge sigue existiendo para quien quiere el servidor. Vapor sigue existiendo para quien ya está en Lambda. La CLI de Cloud no unifica esas salidas. Hace que la opción gestionada sea tan fácil de empezar que quedarse tiene que ser una decisión consciente.
Un agente con API de infra necesita permiso estrecho
El anuncio de la API deja explícito que los agentes pueden provisionar bases, consultar réplicas y preguntar el estado de scale to zero. La CLI instala skills para Claude, Cursor, Copilot y formatos genéricos. Eso reduce trabajo repetido. También amplía la superficie: un token con el alcance de la cuenta puede crear un recurso que genera factura.
Acoten el token a lo que el flujo necesita. Desplegar un entorno ya existente es un poder. Crear un clúster de base es otro. Ejecutar cloud tinker --code contra producción es un tercero. En CI, usen token de organización específica, --json, y rechacen el prompt interactivo. Fuera del CI, no dejen la skill del agente con credencial de producción en el mismo perfil que el portátil de feature.
La ganancia de DX de cloud ship es real y cambia la conversación de contratación de PHP. La decisión de plataforma sigue siendo precio en carga sostenida, permiso de quién puede crear recurso, y una prueba de salida escrita antes de concentrar el tráfico. Sin esos tres, el equipo compra velocidad de bootstrap y descubre el resto en la factura o en el incidente.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
