Staging and test servers

What it is for

A place to find out that the migration locks a table, the new package conflicts, the certificate renewal breaks, or the config change loses a setting — before any of that reaches customers.

It is also where you rehearse the things that are only theory otherwise: a restore, a migration, a failover.

Make it resemble production

Same operating system version, same package versions, same web server and database configuration. It does not need the same size — a smaller machine is fine, and a virtual machine on an existing server is often enough, see Proxmox.

Build it with the same configuration management as production, from the same roles with different variables. If staging is configured by hand, it proves nothing.

Data: realistic, not real

A copy of the production database makes staging genuinely useful and turns it into a second copy of your customers' personal data, on a machine with weaker access control, that nobody is watching. Under the GDPR that is processing, and it is the kind of thing that ends badly — see who is responsible under the GDPR.

Anonymise during the copy: scramble names and emails, drop payment details, truncate logs. Keep the shape and the volume, lose the people. An anonymisation script that runs as part of the refresh is twenty lines and removes the whole problem.

Keep it out of the way

• Behind authentication or a firewall, or ideally over WireGuard. Staging environments get found.
• X-Robots-Tag: noindex and a blocking robots.txt, or you will find staging outranking production.
• No production credentials. Separate database users, separate API keys, payment providers in test mode. See managing secrets.
• No outbound mail to real addresses. Catch it locally or send it to a trap. A test run that emails ten thousand customers is a famous and entirely avoidable mistake.
• Make it visibly different — a coloured banner, a different shell prompt. Most “I thought I was on staging” incidents are prevented by one CSS rule.

Refresh it regularly

A staging server that has drifted six months from production tells you nothing. Refresh the data and reapply the configuration on a schedule, and treat a failed refresh as a bug — it usually means production has something nobody wrote down.

Spend accordingly

Staging can be modest hardware; it does not need production's disks or port speed. Ask us for a quote that reflects that — describe it as a staging machine and we will specify it as one rather than selling you a second production server. See writing a good quote request.

---

Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base