Shipping & Running

Laravel Cloud runs the app for you on fully managed, auto-scaling compute with managed databases, caches and object storage; Forge provisions and manages servers you own on a provider; Vapor deploys the app serverless onto AWS Lambda.

php artisan down makes Laravel answer requests with a 503 maintenance response. With --secret=token (or a random --with-secret), visiting /token sets a signed laravel_maintenance bypass cookie so that browser uses the site normally; php artisan up ends maintenance.

php artisan optimize runs config:cache, event:cache, route:cache and view:cache, plus any commands packages register. php artisan optimize:clear runs the matching :clear commands, and it also runs cache:clear and clear-compiled.

Pulse registers a default viewPulse gate that only passes in the local environment, and its Authorize middleware checks that gate on /pulse, so production answers 403. Define viewPulse yourself in AppServiceProvider::boot, for example allowing only admins.

/up, registered by withRouting(health: '/up'), returns 200 when the app boots and every DiagnosingHealth listener succeeds, and 500 if a listener throws. It is excluded from maintenance mode, so it stays 200 while the site is down.

The config, route and event caches from the earlier optimize are still in bootstrap/cache, and Laravel uses them instead of reading config files, route files or listener directories. Hot-fixed changes stay invisible until php artisan optimize runs again.

Each deploy builds a new releases/<timestamp> directory with its own vendor, assets and bootstrap/cache, symlinks in a shared storage directory and .env, migrates and runs optimize there, then atomically repoints current and runs php artisan reload.

php artisan reload terminates long-running processes so a process monitor restarts them on the new release: it runs queue:restart and schedule:interrupt, plus commands packages register with reloads(), such as horizon:terminate, octane:reload, reverb:restart and pulse:restart.

An Artisan command run as root created storage/logs/laravel.log (or a cache file) owned by root, so the PHP-FPM user can no longer write to it. Run deploy commands as the web user and give storage and bootstrap/cache group-writable ownership.

On Vapor the app runs on AWS Lambda, where only /tmp is writable; vapor-core moves the storage path to /tmp/storage, which belongs to one short-lived container. Keep files on S3 and cache and sessions in DynamoDB, Redis or a database.

--render stores a prerendered view that public/index.php can serve before the framework loads; --retry sets Retry-After; --refresh sets a Refresh header; --redirect sends browsers to one path. --render keeps the page working while vendor files are being replaced.

Yes. Laravel 13's route:cache wraps each closure action in SerializableClosure::unsigned() and stores it in the cached route file, so closure routes work cached. Caching still fails when a closure captures a value PHP cannot serialize.

Pulse's SlowRequests recorder logs requests at or above a threshold (1,000 ms by default), grouped by method, route URI and controller action; SlowQueries groups slow SQL with the file and line that ran it. Compare the cards before and after the release.

On Vapor, each SQS message triggers a Lambda invocation that runs the hidden vapor:work command to process that one job, and a per-minute invocation runs vapor:schedule, which calls schedule:run. There are no worker daemons to supervise or restart.

The default file driver writes storage/framework/down on the one server that ran the command, so the other three stay live. APP_MAINTENANCE_DRIVER=cache stores the flag in a shared cache store, so one php artisan down covers every server.

config:cache freezes resolved values, so production runs on the CI job's credentials, key and paths and ignores its own environment. Route, event and view caches mostly depend on code; cache config where production values exist.

With PULSE_INGEST_DRIVER=redis, requests push Pulse entries onto a Redis stream instead of writing to the database; a long-running php artisan pulse:work moves them into Pulse's tables, trims old data, and must be restarted with pulse:restart on deploy.

Each Pulse recorder's sample_rate is the chance, per event, that it is considered at all; the dashboard scales sampled counts up and marks them with ~. Sample high-volume recorders such as user requests and cache interactions, not rare events like exceptions.

Tier the portfolio: pack small, steady sites onto a few Forge-managed servers for cost and control, put spiky or high-stakes apps on Laravel Cloud to offload operations and scaling, and use Vapor only where serverless scaling on AWS outweighs its constraints.

Envoy.blade.php declares @servers, shell @task blocks for named servers, and @story blocks that run tasks in order. Each task runs under set -e, so a failing command fails the task and stops the story unless --continue is passed.

Laravel 13's Cloud facade offers hosted(), usesManagedQueues(), queue() and isManagedQueue(); separately, on Cloud the framework reads platform-injected variables to set up object-storage disks, a read replica, Postgres pooling, a managed cloud queue connection, logging and exception reporting.

Calling $this->optimizes(optimize: 'package:optimize', clear: 'package:clear-optimizations') in a provider's boot() adds those Artisan commands to the task lists that php artisan optimize and optimize:clear run after Laravel's own caches.

The Servers card is fed by the Servers recorder, which only reacts to beats emitted by php artisan pulse:check; until that long-running command runs on each server, nothing records CPU, memory or disk. Each server needs a unique PULSE_SERVER_NAME.