Staging, a test environment for developing websites and applications

Reviewed on September 8, 2026 4 min read staging applications

A staging environment is a copy of the website for trying out updates or changes before applying them to production. It can stop a design or compatibility error from affecting visitors, as long as the copy does not keep sending real emails, payments or jobs.

Pushing staging to production does not automatically merge the data of both websites. Replacing the database can delete orders, users and content created since you made the copy.

Create the test environment (staging)

Go to Softaculous and find the installation.
If it is not registered, import it.
Open Create Staging if that application and installation support the feature. It is not necessarily available for the whole catalogue.
Select an empty domain or subdirectory, review the new database and confirm the creation.
Check the clone's URLs and credentials, and protect access before using real data.

The Softaculous creation guide describes the form. Check HTTPS, space and access permissions on the destination.

Protect staging with authentication. noindex does not stop someone from seeing its data. Set up separate test recipients, test payments, webhooks and cron jobs. Also review Redis, remote storage and other shared connections.

Merge changes from staging into production

Before using Push to Live, identify what changes: files, SQL structure or content. Test the deployment on a recent copy and prepare a restorable backup of production taken immediately before the work.

In a live shop, you usually want to bring over code and specific settings without replacing orders. If you need to replace data, plan how to keep the writes made after the clone. A visual maintenance mode may not stop APIs, cron or external integrations.

Default options, copying every change made

The full options can replace production's files and database with staging's. Do not use them as a content merge. Read the summary for the installed version and do not rely solely on an automatic backup you have not tested restoring.

If the whole database is replaced, any information staging does not know about is replaced too. Stop the necessary writes, keep the backup and define the rollback point before confirming.

Customize, applying changes selectively

Review each group the form offers:

Option	What to check
Overwrite Files/Folders	Which files will be replaced and whether production contains recent uploads
Push Full Database	Whether the whole database is replaced, including new production data
Database Structure Changes	Compatibility of columns, indexes and tables with the final code
Data Changes in Tables	What content is replaced and whether those tables receive writes

Selecting tables does not guarantee a row-by-row merge. Relationships can span several tables; do not exclude orders or users without checking how they relate to the rest. Nor can every SQL change be undone with a transaction.

Check and roll back

After the change, test the front end, admin area, user login, forms or a test purchase, cron jobs and logs. Check HTTPS, the canonical URL and caches. Confirm that production keeps its real credentials and integrations and that staging stays isolated.

If a check fails, keep the affected writes stopped and restore the planned consistent set of files and data. Reopening before deciding on the rollback can create new data that a later restore would lose.

Remove the test environment

You can remove the staging installation from Softaculous. Check the URL, document root and database before confirming, so you do not select production.

If you keep staging, keep it protected and up to date. Before another round of work, decide whether you need to recreate it from a recent copy: an old clone can overwrite changes it never received.