O Laravel Cloud CLI saiu do beta essa semana. Agora você digita "cloud ship" no terminal e faz deploy de uma aplicação Laravel em 30 segundos. Sem dashboard, sem painel, sem clicar em nada.
Parece pouco. Mas pensa no que isso significa na prática.
Durante anos, o argumento contra PHP em projetos novos passava por isso: "o ecossistema de deploy é arcaico", "precisa configurar servidor", "não tem a experiência do Vercel". E era verdade. Enquanto um dev Next.js digitava vercel deploy e ia tomar café, quem trabalhava com Laravel estava montando pipeline, configurando Forge, ajustando Nginx.
Agora o fluxo é: composer global require laravel/cloud-cli, cloud login, cloud ship. Deploy feito. Ambiente gerenciado. Banco, cache, storage, domínios, tudo controlável pelo terminal.
O que me chama atenção é que o Laravel está construindo uma stack completa de infraestrutura: Cloud, Forge com Postgres gerenciado, API pública, CLI. A ambição virou ser a plataforma inteira, não só o framework.
Para quem lidera times PHP, isso muda a conversa. Não precisa mais justificar a escolha da linguagem explicando que "dá pra resolver" o deploy. Agora a experiência de deploy compete diretamente com o que Next.js e Rails oferecem.
Agora, o custo. O plano Starter não tem mensalidade fixa e hiberna sozinho quando não tem tráfego. Uma instância básica sai por ~$5/mês. O Growth começa em $20/mês, o Business em $200/mês. Parece acessível no início, mas conforme a aplicação cresce, compute vai de $5 pra $103/mês por instância, e aí a conta muda.
E aí entra a pergunta real: quanto dessa conveniência depende de ficar preso ao ecossistema Laravel Cloud? Porque o "cloud ship" é bonito, mas a migração pra fora nunca é um comando só. Vale colocar na planilha antes de mover tudo.
O primeiro ship e o deploy de rotina são trabalhos diferentes
cloud ship é um fluxo guiado: detecta o repositório, pede região e nome, oferece sincronizar .env, criar banco ou cache, ligar scheduler, Octane ou WebSockets. Serve para colocar a aplicação no ar sem abrir o dashboard. A documentação da CLI separa isso de cloud deploy, que resolve aplicação e ambiente a partir da configuração do repositório e acompanha o progresso.
Tratar os dois como o mesmo atalho esconde o trabalho permanente. Rotina pede cloud repo:config (grava application_id e organization_id em .cloud/config.json), deploy a partir do CI, monitoramento e rollback. A CLI expõe --json e autenticação por token justamente para GitHub Actions e ambientes sem TTY. Conveniência no notebook do desenvolvedor não é o contrato de produção.
Antes de padronizar Cloud para o time, descreva o caminho de um merge até o ambiente estável: quem dispara o deploy, o que conta como saúde, quem reverte, onde o log fica. Se a resposta for "a pessoa roda ship de novo", vocês ainda não têm operação. Têm um atalho de bootstrap.
A API REST cobre o que o dashboard cobre. Ambientes de feature branch, teardown depois do PR, agendamento de scale to zero e alerta no stack de observabilidade existente passam a ser script. Isso é o ganho real para um time que já tem pipeline. O comando único no terminal é a porta de entrada.
Plano barato descreve entrada, não a fatura acordada
A página de preços lista Starter a US$ 5 por mês mais uso (primeiro mês grátis e crédito de uso), Growth a US$ 20 e Business a US$ 200, todos mais consumo. Flex no Starter hiberna e acorda em menos de 500 ms. Growth adiciona compute Pro, autoscaling até 10 réplicas, preview environments e papéis de time. Business amplia autoscaling, WAF e retenção de log. Dá para colocar teto de gasto: alerta em 50%, 80% e 100%, e o compute pausa no limite.
A planilha operacional precisa de três linhas, não de uma. Base do plano. Compute, banco, cache, fila e storage enquanto acordados. Custo de ficar acordado o mês inteiro se a hibernação não se aplicar. Um SaaS com workers 24 h não vive no mesmo perfil de um site que dorme. Comparar só o US$ 5 de entrada com um VPS avulso mistura produtos.
Eu pediria o estimador da própria página com as horas acordadas do produto, não com o cenário de hobby. Depois compararia com Forge (você opera o servidor) e Vapor (Lambda e console AWS). Cloud vende infraestrutura gerenciada em EC2. O preço inclui essa operação. Esconder isso na conversa de "deploy em 30 segundos" empurra a surpresa para o mês em que o tráfego parar de ser esporádico.
Limite de gasto evita fatura fora de controle. Não evita a conversa de capacidade: se o compute pausa no teto, o produto sai do ar. Quem usa o teto como defesa precisa de alerta e de um dono acordado para subir o limite ou reduzir réplicas.
Conveniência no terminal não porta o estado gerenciado
Sair da plataforma nunca é o inverso de cloud ship. Banco gerenciado, cache, bucket, domínio, fila, variável de ambiente, processo em background e cluster de WebSocket ficam no provedor. A CLI ajuda a listar, dump e destruir. Não empacota um artefato único que sobe em outro lugar com o mesmo comando.
Antes de concentrar produção no Cloud, escreva o teste de saída em uma página. Como exportar o banco. Onde o objeto no storage é copiado. Quais DNS apontam para o edge da plataforma. Quais jobs não podem perder mensagem na troca. Se a equipe não consegue responder isso em uma tarde, o custo de saída ainda está opaco. A opacidade é o lock-in, mais do que a ausência de um botão "exportar conta".
.cloud/config.json no repositório amarra o projeto a IDs da organização. Isso é útil no dia a dia e é um acoplamento explícito. Trate-o como o vercel.json de outro ecossistema: conveniência com endereço fixo. Aplicação Laravel continua sendo código PHP; a operação em volta (região, tamanho de instância, hibernação, WAF) não.
Forge continua existindo para quem quer o servidor. Vapor continua existindo para quem já está no modelo Lambda. A CLI do Cloud não unifica essas saídas. Ela torna a opção gerenciada tão fácil de começar que a decisão de ficar precisa ser consciente.
Agente com API de infra precisa de permissão estreita
O anúncio da API deixa explícito que agentes podem provisionar banco, consultar réplicas e perguntar status de scale to zero. A CLI instala skills para Claude, Cursor, Copilot e formatos genéricos. Isso reduz trabalho repetido. Também amplia a superfície: um token com o mesmo alcance da conta consegue criar recurso que gera fatura.
Escopo o token ao que o fluxo precisa. Deploy de um ambiente já existente é um poder. Criar cluster de banco é outro. Rodar cloud tinker --code contra produção é um terceiro. Em CI, use token de organização específica, --json, e recuse prompt interativo. Fora do CI, não deixe a skill do agente com credencial de produção no mesmo perfil que o notebook de feature.
O ganho de DX do cloud ship é real e muda a conversa de contratação de PHP. A decisão de plataforma continua sendo preço em carga sustentada, permissão de quem pode criar recurso, e um teste de saída escrito antes do tráfego concentrar. Sem esses três, a equipe compra velocidade de bootstrap e descobre o restante na fatura ou no incidente.
