Keep development and staging away from production

A separate VPS gives experiments and release checks their own environment. A failed package update, migration, or deployment can be investigated without changing the server users depend on.

What staging is useful for

Use staging to test a release through the real web server, run database migrations, check integrations, reproduce production issues, or let a customer review work before launch. Development servers can also host shared branches, preview builds, and internal tools.

The environment should match production where differences could hide a failure. The runtime, database major version, proxy behavior, and deployment method often matter more than identical CPU and memory.

Keep it separate

Use separate domains, credentials, databases, API keys, and deployment access. Disable real email, payment, and webhook side effects or point them to sandbox services. Do not copy personal production data without an approved anonymization process.

XS can suit short-lived tests and small internal services. Small or Medium gives a persistent multi-service environment more room for builds, test data, and logs. Compare the VPS plans with the needs of your test environment.

What you manage

Your team decides how closely staging matches production, who can access it, how data is reset, and when the server is removed. The Docker guide provides a complete base if the environment uses Compose.