Hospedagem Laravel feita para o seu jeito de publicar

Sim. Todos os planos vêm com um shell SSH completo, então publicar é o mesmo fluxo baseado em Git que você já usa localmente. Clone o seu repositório direto do GitHub, GitLab ou Bitbucket para dentro da sua conta, rode composer install para baixar os pacotes vendor e copie os seus valores de produção para o .env. A partir daí o Artisan assume: php artisan key:generate define a chave da aplicação e php artisan migrate constrói o esquema do banco de dados. Publicar uma versão posterior é igualmente rápido — git pull para pegar os novos commits, composer install para atualizar as dependências, php artisan migrate para quaisquer novas migrações e uma limpeza de cache para descartar a configuração antiga. Como você tem um shell de verdade, e não um painel travado, dá para acompanhar logs, corrigir permissões de storage e repetir qualquer comando se algo precisar de uma segunda olhada. Aponte o document root para a pasta public e o site fica no ar por HTTPS.

Sim — o Composer vem instalado em todas as contas e já está no seu PATH, então não há nada para baixar, descompactar ou configurar antes do primeiro deploy. Abra uma sessão SSH assim que a conta for provisionada e composer install, composer update, composer require e composer dump-autoload funcionam imediatamente com o binário PHP correto. Isso importa no Laravel, porque o framework e praticamente todo pacote que você adiciona — dos starter kits ao Sanctum, ao Horizon e ao resto — chegam pelo Composer, e não versionados no seu repositório. Você mantém o seu próprio composer.json e composer.lock, então as versões que você testa localmente são as versões que chegam ao servidor. Se algum dia precisar rodar o Composer com uma versão específica do PHP, pode — a versão do PHP é selecionável por site. Em resumo, o seu fluxo de dependências se comporta exatamente como na sua própria máquina.

Você tem PHP 8.x moderno e escolhe qual versão cada site usa direto no painel de controle. Essa flexibilidade importa porque cada versão do Laravel indica um requisito mínimo de PHP — as versões recentes esperam PHP 8.1 ou superior, enquanto uma aplicação antiga em suporte de longo prazo pode estar presa a uma build 8.x anterior. Em vez de impor um único runtime a tudo, você define a versão por domínio, então um projeto legado de cliente e uma aplicação novinha convivem na mesma conta sem conflito. Ao lado do seletor, você ajusta as configurações que o Laravel valoriza: memory_limit para comandos Artisan e importações mais pesados, max_execution_time para tarefas longas e OPcache para manter o código compilado quente na memória. Trocar de versão é instantâneo e reversível, o que torna testar uma atualização do PHP algo de baixo risco — suba primeiro um domínio de staging, confirme que a sua suíte de testes passa e depois mova a produção com um único clique.

Os dois são cidadãos de primeira classe aqui. Para trabalho enfileirado, inicie um worker persistente com php artisan queue:work para que jobs, notificações, mailables e exportações pesadas rodem fora da requisição web em vez de travar o carregamento da página do visitante. Apoie a fila no Redis e os jobs são capturados e escoados rapidamente mesmo com tráfego real. Para trabalho agendado, você não adiciona uma longa lista de linhas de cron separadas. Em vez disso, registra tudo dentro do agendador do Laravel no código da aplicação e adiciona uma única entrada de cron que roda php artisan schedule:run a cada minuto. A partir dessa única tarefa, o Laravel decide quais comandos estão na hora e os dispara — resumos por hora, limpezas noturnas, relatórios semanais e por aí vai. Depois de cada deploy, rode php artisan queue:restart para que os seus workers carreguem o novo código. É a configuração padrão do Laravel funcionando exatamente como a documentação descreve, sem gambiarras específicas da plataforma para aprender.

Sim. O Redis está disponível para cache, armazenamento de sessões e filas, que é a combinação buscada pela maioria das aplicações Laravel em produção. Aponte o seu driver de cache para o Redis e resultados caros de consultas, fragmentos renderizados e valores calculados passam a ser servidos da memória em vez de reconstruídos a cada acesso. Mova as sessões para o Redis e o estado de quem está logado continua rápido e consistente conforme o tráfego cresce. Defina a conexão de fila como Redis e os jobs em segundo plano são enfileirados e processados com pouquíssima sobrecarga, mantendo os workers responsivos durante picos. Você conecta tudo isso no seu .env com as configurações padrão de driver de cache, sessão e fila — nenhuma configuração sob medida é necessária do nosso lado. Como o Redis mantém esse conjunto de dados na RAM e não em disco, páginas que antes pareciam pesadas ficam visivelmente mais ágeis, e o processamento em segundo plano acompanha o ritmo em vez de virar um acúmulo quando chega uma rajada de tráfego.

Sim, e essa é a forma correta de servir uma aplicação Laravel. O Laravel mantém um único ponto de entrada no diretório public e guarda o código da aplicação, o .env e o storage acima da raiz web, de modo que nada sensível fica acessível pela internet. No painel de controle você define o document root do seu domínio para a pasta public do projeto, e as requisições passam pelo index.php exatamente como o framework pretende. Combinado com SSL grátis de renovação automática, a sua aplicação responde por HTTPS com URLs limpas e bonitas, sem index.php na barra de endereços. As permissões de diretório em storage e bootstrap/cache são simples de definir por SSH, então cache, sessões e uploads de arquivos funcionam de primeira. Se você hospeda várias aplicações em uma conta, cada domínio ganha o seu próprio document root apontado para a sua própria pasta public, mantendo os projetos bem separados enquanto compartilham o mesmo servidor NVMe rápido por baixo.

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).