Preços do Laravel Cloud e do Forge vs seu próprio servidor: quanto custa um app

O Laravel Cloud cobra a computação por segundo e para de cobrá-la enquanto o app dorme. Ele só adormece depois de um período ocioso tão longo quanto o tempo limite de suspensão. Cada tarefa agendada o mantém acordado por esse mesmo tempo, então uma tarefa a cada 5 minutos com tempo limite de 5 minutos nunca deixa o ambiente dormir. Se você agenda algo a cada minuto, a cobrança é de um app sempre ligado, até o limite do Cloud de 28 dias por instância por mês.

Se o seu app pode dormir a maior parte do dia, sem nada agendado com mais frequência que o tempo limite e com os jobs em uma fila gerenciada, o plano Starter do Laravel Cloud cobra a computação apenas pelo tempo em que ele fica acordado, além da taxa do plano, das operações da fila e do armazenamento e dos backups do banco de dados. Todas as contas abaixo consideram que o seu app nunca dorme. Se o seu app é um conjunto de contêineres Docker em vez de um único app Laravel, quanto custa um contêiner sempre ligado no Fly.io, no Cloud Run ou no Fargate calcula o preço do mesmo problema em plataformas de contêineres com pagamento por uso.

O que um app Laravel usou no nosso servidor de teste (não é um servidor da DreamHost)

Fizemos o deploy de um app Laravel 13 novo em um servidor de teste, em um único contêiner criado com os pacotes do próprio Debian 13. Ele rodava os mesmos três programas que vêm na VPS LAMP Stack, mas eram o Apache, o MariaDB e o PHP 8.4 do próprio Debian 13, não a imagem LAMP da DreamHost. O Supervisor manteve um worker de fila rodando, e uma linha de cron executava o agendador. O servidor tinha 2 vCPUs, assim como o Stack 4 e o Stack 8.

A 200 requisições por segundo, o p95 dessa página subiu para 160 ms, ainda sem erros. A essa altura, o gerador de carga dividia os mesmos dois núcleos, então esperamos um resultado um pouco melhor em um servidor onde isso não acontece. Uma rota Laravel simples, sem chamada ao banco de dados, ficou abaixo de 17 ms no percentil 95 até 400 requisições por segundo. Para comparação, o S3 abaixo considera 3 milhões de requisições por mês, o que dá uma média de cerca de 1,2 por segundo.

Mesmo no pico de 572 MiB, os 4 GB do Stack 4 deixariam cerca de 3 GB livres, pelas nossas contas. Mas o seu app em produção terá mais código e dados que a nossa instalação nova, e, se você adicionar workers para uma fila mais movimentada, cada um ocupa cerca de 55 MiB. Para produção, recomendamos o Stack 8, com o dobro da memória do Stack 4.

Quanto o app custa em três tamanhos

As contas abaixo usam os preços do Laravel para a região US East (Virgínia). Cada uma considera que o seu app responde a qualquer hora e agenda uma tarefa a cada minuto, então a computação e o banco de dados ficam acordados o mês inteiro. Descontamos o crédito de uso de US$ 5 que vem com todos os planos pagos. Para os backups, usamos o cenário baixo, com armazenamento de snapshots igual ao volume de dados. O S1 roda o worker na própria instância de 1 GiB do app. A julgar pelo nosso servidor de teste, onde o app inteiro, incluindo o banco de dados, chegou ao pico de 572 MiB, essa instância tem espaço para ele. O S2 e o S3 colocam os jobs em uma fila gerenciada, que, segundo a documentação do Laravel, substitui um worker dedicado.

Mesmo a pequena conta do S1 fica acima do preço mensal regular do Stack 8, e a diferença cresce rápido: o S2 custa mais que o triplo. O S3, cerca de 11 vezes mais, paga por duas réplicas e um cache para atender um tráfego médio de cerca de 1,2 requisição por segundo, bem abaixo das 100 por segundo que o nosso servidor de teste suportou. No servidor, você não adicionaria um cache Valkey, porque o Laravel 13 guarda cache, sessões e a fila no banco de dados por padrão. Se você usar o Forge, some os US$ 12 mensais do Hobby ao preço do servidor em qualquer um dos três.

O exemplo da própria documentação do Laravel para uma Medium SaaS application sai mais barato, cerca de US$ 53,90 por mês, porque usa as tarifas de US East (Ohio), deixa de fora a taxa do plano e deixa a computação dormir à noite e nos fins de semana.

Nos cenários S1 e S2, o banco de dados custa mais do que a instância do app que ele atende. O Laravel MySQL também continua cobrando armazenamento e backups enquanto está em repouso. Os backups poderiam chegar a US$ 3,50 por mês se cada snapshot diário tivesse o tamanho completo. O tráfego de saída é gratuito aqui porque a instância Flex 1 GiB do S1 inclui 100 GB por mês. No S3, o tráfego de saída já é o maior item de uso, porque duas réplicas Pro têm uma franquia de apenas 200 GB, e os outros 800 GB custam US$ 80,00. No LAMP Stack VPS, você não paga pela largura de banda por GB. Ela é ilimitada, sem taxas de excedente, nos termos de uso justo da DreamHost.

A taxa do Forge é cobrada além do servidor

O Forge pode funcionar em um servidor que você já aluga, pela opção Custom VPS. Esse servidor precisa ser uma instalação nova do Ubuntu 24.04 ou 26.04 x64 com acesso SSH root. Depois, o próprio Forge instala o Nginx, o PHP, o banco de dados e o Redis. Na DreamHost, isso significa um VPS Ubuntu, vendido pelos mesmos preços de Stack do LAMP Stack VPS. A imagem LAMP não serve, porque já chega com o Apache e o MariaDB rodando. Se você está comparando os dois servidores web, veja Apache ou Nginx para PHP.

Então, em um servidor da DreamHost, o Forge custa a taxa dele mais o mesmo preço de Stack que você pagaria para rodar o app por conta própria. Por essa taxa, o Forge configura o servidor, faz o deploy a cada push e escreve as entradas do Supervisor e do cron, o que cobre a maior parte dos passos abaixo.

O que você mesmo executa no servidor LAMP

Nosso servidor de teste precisou destes quatro passos além do Apache, do MariaDB e do PHP, sem painel de controle. Se mesmo assim você quiser um painel no servidor, o guia alternativas gratuitas ao cPanel no seu próprio VPS mede quanto o HestiaCP, o CloudPanel e o Virtualmin consomem de memória e disco. Os caminhos pressupõem que o seu app fica em /var/www/app e roda como www-data.

1. Instale o Composer e o Supervisor

   Os dois estão no repositório de pacotes do próprio Debian 13. Pule qualquer um deles se o seu servidor já o tiver.

   bashCopiar

   sudo apt install composer supervisor

2. Adicione o queue worker ao Supervisor

   Salve isto como /etc/supervisor/conf.d/laravel-worker.conf. É o exemplo do próprio Laravel com o caminho, o usuário e o número de workers ajustados para um único app. Movemos o log para /var/log, porque o Supervisor do nosso servidor de teste se recusava a iniciar enquanto a pasta de log dentro do app ainda não existia.

   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

   Depois, carregue-o com sudo supervisorctl reread, sudo supervisorctl update e sudo supervisorctl start "laravel-worker:*".

3. Adicione a linha de cron do scheduler

   Salve esta linha como /etc/cron.d/laravel. É a única entrada de cron do Laravel, com o caminho e o usuário preenchidos.

   bashCopiar

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

4. Faça o deploy com um script

   Execute isto na pasta do app a cada release. Nas nossas três execuções, tudo o que veio depois da alteração no código levou cerca de 1,5 segundo, a maior parte em composer install. O site ficou em modo de manutenção durante esse tempo. O primeiro deploy de um app novo levou 19 e 29 segundos nas nossas duas execuções, a maior parte com o Composer baixando pacotes.

   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

Quando cada opção faz sentido

No tamanho do S1, a conta do Laravel Cloud fica um pouco acima do preço mensal regular do Stack 8. Um app desse tamanho também cabe no Stack 4, que mantém cerca de 3 GB livres na nossa leitura mais alta. As diferenças maiores começam no S2, onde o Stack 8 tem espaço para o app crescer.

O suporte da DreamHost está disponível 24/7, e o hardware, a rede e a conectividade têm todo o suporte da equipe da DreamHost. Você cuida do sistema operacional, do software e da configuração, o que aqui significa o app. No nosso teste, o Composer, o Supervisor e o cron foram configurados uma única vez, e cada release depois disso foi um único script. A partir daí, as tarefas mensais são aplicar as atualizações do sistema operacional e verificar se os backups rodaram.

Como testamos o app e analisamos os preços

A DreamHost consultou as páginas de preços do Laravel Cloud, do Forge e da DreamHost em 20 de outubro de 2026, a documentação deles entre 19 e 21 de outubro, e executou o teste em 20 de outubro. Conferimos novamente cada plano, preço e recurso da DreamHost citado nesta página com as páginas da DreamHost em 22 de outubro de 2026.

O servidor de teste era uma VM arm64 com 2 vCPUs e 8 GB rodando Ubuntu 24.04, com o app em um único contêiner criado com pacotes do Debian 13. Não era um servidor da DreamHost nem a imagem LAMP da DreamHost, e os planos VPS da DreamHost rodam em processadores AMD EPYC.

O contêiner rodava os pacotes Apache 2.4, PHP 8.4 e MariaDB 11.8 do Debian 13, com o Laravel 13.38. Em repouso, o MariaDB ocupava 123 MiB, o Apache e o PHP 123 MiB e o worker 55 MiB; esses números por processo compartilham memória, por isso somam mais que o total de 208 MiB.

Cada etapa de carga durou um minuto. Nos redeploys cronometrados, uma alteração local no código substituiu git pull. Nada rodou no Laravel Cloud nem no Forge, então as colunas deles vêm das tarifas publicadas. O teste não mostra diretamente tráfego real, HTTPS, PHP-FPM nem um servidor de 4 GB.

Perguntas frequentes sobre o custo de hospedagem Laravel