Laravel Staging Environment and Laravel Staging Server for Client Review

How do I set up a staging environment for Laravel?

Create a second Laravel site from a staging branch, give it a separate database and .env, and protect it with HTTP basic auth. Set APP_ENV=staging, use test service credentials, and isolate mail, queues, and cache before the first deploy. Release the approved commit through your production deployment process.

In DeployManage, select the branch explicitly because new sites default to main. Create the staging database in the panel and configure the site's encrypted .env. Set APP_DEBUG=false for client review. Rebuild configuration caches after changing environment variables.

Use a consistent Laravel deployment workflow for both sites. Check migrations, assets, and workers before requesting approval. Our Git deployment guide covers the branch workflow; DeployManage requires a separate production deploy after review.

Should staging run on the same server as production?

Staging can share a server with production when the machine has spare capacity and you accept shared resource risk. A separate server gives testing its own CPU, memory, and failure boundary. Either setup still needs separate databases, credentials, queues, and cache namespaces so staging cannot interfere with production work.

A shared server avoids another server bill, but migrations, asset builds, and test jobs compete with live traffic. Basic auth controls visitors; it does not isolate resource use. Keep heavy load testing away from the production machine.

A separate server is useful when clients review changes during business hours or database rehearsals consume resources. Match relevant runtime settings to production. Our Laravel hosting guide for agencies covers managing client apps across servers.

How do I set up staging on Laravel Forge?

A Laravel Forge staging environment is usually a second site on a staging branch, either beside production or on a separate server. Configure its database and environment variables independently, then deploy that branch. Forge also offers hosted on-forge.com domains for sharing apps before you configure your own DNS.

Hobby costs $12 per month and covers 1 external server with unlimited Laravel VPS. Growth is $19 and Business is $39 with unlimited servers. Include the external VPS fee when comparing totals.

Forge's pricing page lists no preview environment feature. Treat staging as a maintained site rather than assuming a pull request creates it automatically. Compare team requirements and release controls in our Laravel Forge alternative comparison.

Does Laravel Cloud have staging and preview environments?

Laravel Cloud staging uses branch based environments, with unlimited environments available on every plan. Each environment bills for its own compute and database. Laravel Cloud preview environments create an environment per pull request, available for 1 app on Starter and unlimited apps on Growth and above.

Keep a persistent staging environment when a client needs a stable review target. Pull request previews suit changes reviewed independently. Their convenience does not remove the need for separate data, safe mail settings, and review access controls.

Plans cost $5, $20, or $200 plus usage, with a $5 usage credit. Flex compute can scale to zero. Our Laravel Cloud pricing breakdown explains why environment count alone does not predict the bill.

How much does a Laravel staging server cost?

A Laravel staging server adds no server fee when staging shares an existing production machine with spare capacity. A separate DigitalOcean Basic 2 GB droplet adds $12 per month. Include your panel subscription when comparing complete setups, and budget for database, storage, or other services outside the server.

DigitalOcean Basic costs $6 for 1 GB, $12 for 2 GB, or $24 for 4 GB. These are price examples, not capacity guarantees. The Cloud example uses two 512 MB Flex compute instances at their $6 monthly caps and two MySQL Flex 512 MB databases at $5.50 each, plus the $5 plan minus the $5 credit.

DeployManage Starter includes 3 servers and 10 sites per server; Growth includes 10 servers and 50 sites per server. Business is unlimited. Yearly billing halves the monthly subscription price. Growth and Business include zero downtime releases. A code rollback does not undo database changes; plan compatible migrations separately.

How do I keep a staging site out of Google?

Protect staging with HTTP basic auth so crawlers and the public cannot access application pages. Also send an X-Robots-Tag noindex header, using APP_ENV=staging to select staging behavior if needed. Do not rely on robots.txt alone, because a blocked URL can still be indexed when another page links to it.

APP_ENV=staging does not add a noindex header by itself. Configure that response explicitly and verify it on the deployed site. Keep basic auth in place for review URLs, including any aliases that expose the app.

Never let staging send real emails. Use a mail catcher or the log mailer, and never point staging at production queues or the production database. Review these settings before starting workers or importing sanitized test data.