A staging environment is a separate working copy of your public website. It lets you test an update or change before deployment. It reduces some risks, but publishing still changes a live service and can affect visitors and website data.
Create a test copy
- Confirm that Softaculous recognizes the installation and that staging is available for that application and your service.
- Have a recent backup of the live site's files and database, with a confirmed way to restore it.
- In the Softaculous installation list, select the source site and the staging action. Check the destination address, directory and database: they must be separate from production.
- Restrict access to the copy. A request to search engines not to index it is not an access restriction.
- Before testing, disable real email sending, payments, webhooks and automatic jobs that could act on external services. Use test modes and avoid copying unnecessary personal data.
Then check pages, sign-in, forms, extensions and the site's important functions. Successful tests prepare the deployment; they do not replace verification after publication.
Define exactly what will be published
Copying a staging database to production can replace the data already in production. Orders, registrations, comments or edits received since the copy was created can be lost. Do not treat Push to Live as an automatic merge of those records.
Before confirming, identify which files, tables, structures or data the selected option will overwrite. Available choices depend on the application and Softaculous version. For a site receiving transactions, agree on the deployment method and handling of new writes with your developer or our team. A maintenance window may be needed.
Create a fresh production backup immediately before the work and confirm that it is available. Record the rollback method and which recent data a return to that backup could replace. If an option's scope is unclear, have it confirmed before execution.
Check the public website
After publication, verify essential user journeys and expected data at the actual production address. Check integrations and automatic jobs as well. If there is a problem, avoid repeated blind restores: confirm the backup, destination and items to restore first.
To plan an intervention, open a request through your Client Area identifying the website, intended changes and data that continues to arrive there.
Turn successful tests into a planned release
Staging is especially useful when several people work on a website. Define who approves content, who tests the functions and who authorizes publication. A short shared checklist helps confirm the intended result: receiving an enquiry, completing an order or finding important information.
Our team can help prepare the hosting side and, within a development engagement, organize application changes. Tell us about your next website improvement with the site, affected functions and business constraints so the scope and project steps can be established.
