Staging sites and safe deployment habits
Test changes somewhere that is not production, then deploy them with confidence.
"It worked on my machine" usually means "I tested it somewhere that was not production". A staging site fixes that.
What staging is for
A staging copy is a full clone of your site — files and database — on a separate URL, where you can:
Try a plugin or dependency update before it reaches customers.
Test a redesign without anyone seeing the half-finished state.
Reproduce a bug safely.
Rehearse a migration.
Set one up
From /panel/web, choose Staging on a site. We create a copy:
On its own hostname (often protected by a password so search engines and strangers stay out).
With its own database copy.
Independent of production, so changes do not leak either way.
The safe deployment habit
Change and test on staging.
Take a production backup / snapshot.
Deploy to production.
Verify the live site.
If it is broken, roll back from the backup — not by "fixing forward" under pressure.
Things staging does not protect you from
Database divergence. If production has moved on (new orders, new posts), overwriting it with a staging DB destroys that data. Deploy code freely; be deliberate with databases.
Third-party side effects. Staging pointing at a live payment gateway or email sender can send real messages. Point staging at sandbox/test credentials.
Missing environment differences. A staging server with different limits will not reveal a production resource problem.
A practical rule
If a change touches the database schema, code, or anything users depend on, it goes through staging. If it is a text change in a CMS, it does not need to. Match the process to the risk.
Related reading