Hospedar uma aplicação Laravel: VPS, requisitos e implantação

Laravel é um framework de aplicações PHP completo, não um conjunto de páginas que se carrega por FTP. Espera um ambiente de execução real: um PHP recente, várias extensões, um diretório de armazenamento com permissão de escrita, tarefas agendadas e — para qualquer coisa não trivial — workers de fila em segundo plano. É por isso que uma hospedagem compartilhada básica muitas vezes lhe cria obstáculos, e por que um VPS costuma ser a casa certa para uma aplicação Laravel. Este guia cobre o que o servidor realmente precisa e percorre uma implantação real.

Por que um VPS combina com Laravel

A hospedagem compartilhada foi feita para «largar ficheiros numa raiz web». O Laravel quer mais do que isso: acesso SSH para executar composer e artisan, a capacidade de apontar o servidor web para o diretório public/, um processo de longa duração para esvaziar a fila e uma entrada cron para o agendador. Um VPS dá-lhe acesso root, RAM e CPU garantidos e controlo total da stack — exatamente o que essas necessidades exigem. Uma plataforma gerida também pode funcionar, mas um VPS é o meio-termo mais flexível assim que uma aplicação tem filas, uma base de dados e uma cache.

Requisitos do servidor

PHP e extensões

Execute uma versão do PHP atualmente suportada que corresponda à sua versão do Laravel — consulte a documentação do framework para o mínimo exato. O Laravel precisa de um conjunto padrão de extensões PHP ativadas; num VPS Debian/Ubuntu costumam instalar-se em conjunto:

# Ubuntu/Debian: PHP-FPM + the extensions Laravel expects
sudo apt install -y php-fpm php-cli php-mbstring php-xml \
  php-bcmath php-curl php-mysql php-zip php-gd php-intl

# Composer (dependency manager)
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer

Os nomes exatos dos pacotes variam consoante a distribuição, mas as extensões a confirmar são mbstring, xml, bcmath, curl, o controlador da base de dados (pdo_mysql ou pdo_pgsql), zip e openssl. Se faltar uma, costuma surgir como um erro claro durante o composer install ou no arranque.

Base de dados, cache e backend de fila

A maioria das aplicações Laravel combina-se com MySQL/MariaDB ou PostgreSQL. Para qualquer coisa que use filas, sessões ou cache em escala, adicione Redis — serve ao mesmo tempo de cache rápida, armazém de sessões e driver de fila. Garanta que o VPS tem RAM suficiente para a base de dados e o Redis a par dos workers PHP-FPM; a memória é o recurso que mais provavelmente irá esgotar.

Permissões de armazenamento

O Laravel escreve em dois diretórios, storage/ e bootstrap/cache/. O utilizador do servidor web (muitas vezes www-data) tem de poder escrever neles, ou terá erros de permissão que parecem bugs da aplicação:

sudo chown -R www-data:www-data storage bootstrap/cache
sudo chmod -R ug+rwX storage bootstrap/cache

Percurso de implantação

1. Obter o código e instalar dependências

Clone o repositório no servidor e depois instale as dependências de produção. As flags abaixo ignoram os pacotes de desenvolvimento e constroem um autoloader otimizado:

git clone https://github.com/you/your-app.git /var/www/app
cd /var/www/app
composer install --no-dev --optimize-autoloader

2. Configurar o ambiente

O Laravel lê a configuração de um ficheiro .env que nunca é versionado no git. Copie o exemplo, gere a chave da aplicação e preencha os valores reais:

cp .env.example .env
php artisan key:generate

Um .env de produção mínimo tem este aspeto — defina APP_DEBUG como false para que os erros não sejam expostos aos visitantes:

APP_NAME="Your App"
APP_ENV=production
APP_KEY=base64:...generated...
APP_DEBUG=false
APP_URL=https://yourapp.com

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=yourapp
DB_USERNAME=yourapp
DB_PASSWORD=change-me

CACHE_STORE=redis
QUEUE_CONNECTION=redis
SESSION_DRIVER=redis
REDIS_HOST=127.0.0.1

3. Migrar e colocar em cache para produção

Execute as migrações da base de dados e depois construa a configuração, as rotas e as views em cache do Laravel. Colocar isto em cache é o que torna o framework rápido em produção — mas lembre-se de reconstruí-las a cada implantação, pois congelam o estado atual:

php artisan migrate --force

php artisan config:cache
php artisan route:cache
php artisan view:cache

4. Apontar o Nginx para public/

A raiz de documentos do servidor web tem de ser o diretório public/ — nunca a raiz do projeto, ou exporia o .env e os ficheiros de origem. Um bloco de servidor Nginx + PHP-FPM padrão:

server {
    listen 80;
    server_name yourapp.com;
    root /var/www/app/public;

    index index.php;
    charset utf-8;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

Adicione HTTPS com um certificado automatizado gratuito (a maioria das hospedagens e ferramentas como o Certbot tornam-no numa só linha) — uma aplicação de produção deve ser sempre servida sobre TLS.

5. Executar o worker de fila com o Supervisor

Os trabalhos em segundo plano (e-mails, notificações, exportações) correm através de um worker de fila, um processo de longa duração que tem de sobreviver a falhas e reinícios. Não execute php artisan queue:work à mão numa sessão SSH — use um gestor de processos como o Supervisor para o manter vivo:

# /etc/supervisor/conf.d/app-worker.conf
[program:app-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/app/artisan queue:work redis --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
user=www-data
numprocs=2
redirect_stderr=true
stdout_logfile=/var/www/app/storage/logs/worker.log
stopwaitsecs=3600

sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl start app-worker:*

6. Agendar o agendador

O agendador de tarefas do Laravel é movido por uma única entrada cron que corre a cada minuto; é o próprio Laravel que decide quais tarefas estão pendentes. Adicione-a ao crontab do utilizador de implantação:

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

Dimensionar o VPS

Perfil da aplicação	Do que precisa
Aplicação pequena, tráfego leve	VPS de entrada: alguns GB de RAM, armazenamento NVMe, 1–2 vCPU — PHP-FPM mais uma pequena base de dados.
Filas + Redis + base de dados	Mais margem de RAM para que o Redis, a base de dados e vários processos PHP-FPM e workers coexistam confortavelmente.
Tráfego mais elevado / trabalhos pesados	vCPU dedicadas para carga constante, mais processos workers, espaço para escalar; considere separar a base de dados mais tarde.

Para quem é

• Prefere não gerir um servidor: uma plataforma gerida ou um VPS gerido trata do patching e da supervisão de processos por si, a um preço mais alto.
• À vontade na linha de comandos: um VPS não gerido é mais barato e totalmente flexível — é seu dono da configuração de PHP, Nginx, Supervisor e cron mostrada acima.
• Aplicação em crescimento com filas e cache: um VPS com RAM/CPU garantidos e Redis é a escolha natural; dimensione primeiro a memória, depois a CPU e depois o armazenamento.

Como decidir

Parta do que o Laravel precisa para funcionar bem: acesso SSH, um PHP suportado com as extensões certas, uma base de dados e (para filas/cache) Redis, armazenamento com permissão de escrita, um worker de fila sob o Supervisor e um cron de uma linha para o agendador. Um VPS dá-lhe tudo isso com recursos garantidos e um caminho claro para escalar — faça corresponder o plano ao seu tráfego e à carga de trabalhos em segundo plano, e escolha o mais pequeno que o cubra com margem.