Test a script on a staging copy before going live

A staging site is a copy of your site that only you can see. You try an update, a new script or a configuration change there first, and only repeat it on the live site when it works. It costs a little time, and it turns "I hope this works" into "I have seen this work".

What staging is, and is not

Staging is a separate address, a separate database and a copy of your files. It should look and behave like the live site, but nobody should find it by accident, and it should never send real emails or take real payments.

It is not a backup. A backup restores the past; staging tests the future. You need both.

Set one up

1. Create a separate address. A subdomain such as staging.example.com works well.
2. Copy the files from the live site to the new location.
3. Copy the database into a new, separate database with its own user. Never point staging at the live database.
4. Update the configuration so the site URL is the staging address and the database credentials are the staging ones.
5. Keep it private. Protect it with a password at the web server level and ask search engines not to index it.
6. Turn off anything with real-world effects. Use a test mode for payments, a mail catcher or a disabled mailer for email, and disable scheduled jobs that contact customers or ping real services.

Commands for a typical server

Dump the live database and load it into the staging one:

mysqldump --single-transaction -u live_user -p live_db > live.sql
mysql -u staging_user -p staging_db < live.sql

Copy the files, leaving out logs and caches:

rsync -a --exclude 'storage/logs' --exclude 'cache' /var/www/example.com/ /var/www/staging.example.com/

For a Laravel-based script the relevant settings live in the environment file:

APP_ENV=staging
APP_DEBUG=false
APP_URL=https://staging.example.com
MAIL_MAILER=log

MAIL_MAILER=log writes emails to the log instead of sending them, which is exactly what you want while testing. Other scripts have an equivalent "disable email" or "test mode" setting; check its documentation.

Keep staging out of search results and out of reach

Add HTTP basic authentication so only people with the password get in. On Nginx:

auth_basic "Staging";
auth_basic_user_file /etc/nginx/.htpasswd-staging;

Also set the script's "discourage search engines" option if it has one. A password is stronger than a request.

What to test

• The change itself. Run the update or install the new script, following its documentation step by step.
• The paths that make money or break trust. Registration, login, checkout, password reset, file upload.
• Your customisations. Anything you edited is the first thing an update can break.
• Emails. Check what would have been sent, and read the content.
• Scheduled jobs. Run them once by hand and read the output.
• The log. New warnings after a change are often the first sign of a problem.

Move it to the live site

Repeat the same steps on the live site, in the same order, after taking a fresh backup. Do not copy the staging database over the live one: your live site has new orders, accounts and content that staging does not.

If the update includes a database migration, note how long it takes on staging. That tells you how long the live site may be unavailable, and whether to put it into maintenance mode first.

When staging is not worth it

For a tiny site with no customisations and a script that documents a simple update, a good backup and a quiet hour may be enough. Once the site takes payments, has users or has been customised, staging pays for itself the first time it catches a problem.

Before you start, read the changelog for the version you are moving to. The security checklist explains backups, and installing a PHP script covers the first install.

Frequently asked questions

Does staging need its own domain?

A subdomain is enough. What matters is a separate address, database and configuration.

Can I use my laptop as staging?

Yes, for many scripts. A local stack is fine for testing logic, but it will not catch problems that depend on your real PHP version, web server or cron setup.

How long should I keep a staging site?

As long as you need it for the change. Delete copies of customer data when you are finished.

Can staging send test emails safely?

Yes, if you route mail to a log or a mail catcher instead of the live mail service. Do not use real customer addresses.