Laravel Cloud vs Forge vs a Self-Hosted VPS

Getting a Laravel application into production involves three main options: Laravel Cloud, Forge, or a self-hosted VPS. Each approach sits on different points of the control-versus-convenience spectrum and carries its own advantages and drawbacks. This article explores the trade-offs of each choice.

Laravel Cloud, launched on February 24, 2025 alongside Laravel 12, is a fully managed, serverful platform running on Amazon EC2. It automatically provisions isolated environments for production, staging, and preview branches. It runs composer install, configures route/view caches, and performs migrations on every deployment. The service also scales replicas up or down based on traffic, rotates SSL certificates, and manages encrypted environment variables.

However, users cannot SSH into the underlying instance, install custom PHP extensions, configure Nginx, or run long-lived daemons outside the provided worker abstraction.

Pricing for Laravel Cloud follows a usage-based model. The Starter plan has no monthly subscription fee, charging only for consumed compute and bandwidth. Growth plans start at $20/month with higher resource ceilings. This model is predictable for steady traffic but may experience spikes with traffic bursts.

Laravel Forge, on the other hand, is a server management panel. Users must bring their own cloud server (like DigitalOcean, AWS, Hetzner, Vultr, or any provider that allows Forge to connect via API). Forge provisions Ubuntu, configures Nginx, PHP-FPM, MySQL or PostgreSQL, Redis, and Supervisor, and sets up your deployment pipeline.

An October 2025 update introduced Laravel VPS, a DigitalOcean-backed product within Forge that provisions an Ubuntu server in seconds with consolidated billing. Users get full SSH and root access, but Forge handles the initial stack configuration. Zero-downtime deployments, enabled by default for new Forge sites, use an atomic symlink strategy.

Forge's deployment script includes running git pull origin main, composer install, and various artisan commands to cache configuration, routes, views, events, and migrate the database. It's crucial to note that php artisan migrate --force bypasses the production confirmation prompt, so testing migrations on a staging server is essential to avoid irreversible data loss due to schema changes.

Shared paths like .env and storage/ must persist across releases, so users should configure these in Forge's zero-downtime settings to avoid issues with uploaded files and sessions.

Forge provides full server control, allowing custom Nginx configurations, specific PHP extensions, multiple queue worker groups, and the ability to SSH in when issues arise. It's ideal for those who want predictable traffic and a flat-rate pricing model. However, Forge's atomic deployments are limited to a single server, which means it cannot coordinate simultaneous atomic deploys across multiple application servers behind a load balancer.

For such scenarios, users might need to consider Laravel Envoyer, which deploys a single project across multiple servers with health checks before switching traffic.

Lastly, there's the option of a self-hosted VPS without using Forge. This approach means fully owning every layer, from OS updates to Nginx configuration, PHP-FPM pools, SSL renewal, firewall rules, and deployment scripting. While this provides complete control and the lowest possible cost per compute unit, it's operationally expensive due to the need to manage all aspects of the server.

A baseline production stack on an Ubuntu 24.04 LTS server includes configuring Nginx, setting up Supervisor for queue workers, and ensuring PHP is properly integrated.

Each option has its trade-offs. Laravel Cloud offers zero ops overhead and auto-scaling but lacks SSH access and custom PHP extensions. Forge provides full server control and zero-downtime deployments but is limited to a single server and uses a flat-rate pricing model. A self-hosted VPS offers complete control and the lowest cost but requires significant operational effort. Choosing the right approach depends on the team's DevOps capabilities, traffic patterns, and desired level of control over the hosting environment.