VPS for developers: staging environments
A staging environment exists so that you find the bug before your customers do. It should match the production server in software and configuration, but it can have half the resources and live for just a few days. Here is how to keep staging cheap, how to run several versions on one server and how to make sure a copy of the site does not end up in search results or send emails to real customers.
Development usually involves three environments. On a local machine the developer writes code. In staging, the built version is tested in conditions close to production: the client reviews a new feature, a tester runs through the scenarios, database migrations are checked. The production server serves real users. Some teams add temporary environments for each branch: they are used to demonstrate a single task and deleted after the merge.
What staging must share with production
- Software versions. The same operating system and the same versions of PHP, Node.js, Python, the database and the web server. Bugs that appear only on a different version are the most common surprise at release time.
- Configuration. Web server configuration, caching, upload limits, time zone and environment variables, except passwords and keys.
- Deployment method. Staging is updated by the same script or pipeline as production. That way you test the deployment itself, not just the code. How to set up such a pipeline is described in the article CI/CD on your own VPS.
What can differ. Resources: staging with one or two users needs 1–2 cores and 2–4 GB of memory, even if production needs 8 cores. Data volume: an anonymised sample instead of the full database. Load testing on a scaled-down environment is pointless: for that you need a server with the same configuration as production. How to run such a test is covered in Load testing a website before launch.
Short-lived environments: hourly billing and snapshots
An environment for demonstrating a task or testing an update is needed for a few days. There is no need to pay for a whole month: with hourly billing you are charged while the server exists, and charges stop once it is deleted. According to the accsly.io catalog as of November 2026, 173 of 2,248 hosts with VPS plans offer hourly billing. At these hosts a plan with 1 core and 2 GB of memory costs a median of about $11 a month, roughly $0.015 an hour, so a week of staging costs about $2.6. An environment with 2 cores and 4 GB costs $24 a month, about $0.033 an hour, and three days cost about $2.3. The catalog keeps prices in roubles; dollar figures are converted at the catalog rate of 7 November 2026. The break-even calculation and the pitfalls are covered in the article Hourly billing: when it pays off, and plans are collected in VPS with hourly billing.
A disk snapshot speeds up creating an environment. Configure a server once, take a snapshot and create new environments from it in minutes. Before deleting an environment you will need again, take a snapshot and then delete the server: storing a snapshot is usually cheaper than a running server, but it is not free. A snapshot at the same host does not replace a backup; the difference is explained in the article VPS backups: strategies and tools.
If the host is new to you, a staging environment is a convenient way to test it before moving the production site. According to the accsly.io catalog as of November 2026, 247 hosts offer a free trial; the terms and limitations of such trials are covered in the article Free trials and money-back guarantees.
Several environments on one server with Docker Compose
If you need staging all the time, it is cheaper to keep one larger server and run several versions on it in containers. Docker Compose reads compose.yaml and compose.override.yaml by default, and with the -f flag merges several files in order (Docker documentation). The shared part is described once, while compose.staging.yaml holds what differs in staging: other ports, lower memory limits, test variables.
Each environment runs under its own project name: docker compose -p feature-123 -f compose.yaml -f compose.staging.yaml up -d. Projects with different names have their own containers, networks and volumes, so the environments do not interfere with each other. From the outside, a single web server or reverse proxy routes traffic to them by subdomain: feature-123.stage.example.com. How to prepare a server for Docker and keep images from filling the disk is explained in the article Docker on a VPS: getting started.
How many resources to take: allow 1–2 GB of memory and 5–10 GB of disk for each environment with a database. A server with 2 cores and 4 GB holds two or three small environments. According to the accsly.io catalog as of November 2026, such a plan costs a median of about $21 a month, with a quarter of plans cheaper than $12.5. A plan with 1 core and 2 GB for a single environment costs $11, with a quarter below $7. Collections: VPS for a staging environment and VPS for Docker.
Keeping staging out of search engines
A copy of the site in search results means duplicate pages competing with the production site and a leak of whatever has not been published yet. The options, from least to most reliable:
- robots.txt does not protect you. Google states plainly that a robots.txt disallow is not a mechanism for keeping a page out of search: a URL that others link to can appear in results even if the crawler never visited it.
- noindex. The
<meta name="robots" content="noindex">tag or theX-Robots-Tag: noindexheader prohibits indexing; the header is easier to add for the whole environment in the web server configuration. Both Google and Bing support it. The crawler has to see this directive, so you must not block the environment in robots.txt at the same time (Google documentation). - A password is the most reliable option. Basic authentication in nginx takes two directives,
auth_basicandauth_basic_user_file, and the password file is created with thehtpasswdutility (nginx documentation). Thesatisfy anydirective lets office addresses in without a password and asks everyone else for one. A crawler will not see a single page.
The environment's name is not a secret. Let's Encrypt submits every certificate it issues to public Certificate Transparency logs, which reveal every subdomain a certificate was issued for. A certificate for *.stage.example.com hides the names of individual environments but does not replace password protection. How to issue such certificates and set up subdomains is explained in the articles SSL certificates: free and paid and Domains and DNS for a server owner.
Data and side effects
- Do not copy the production database as is. It holds customers' personal data, and staging is less well protected than production. Anonymise names, phone numbers, email addresses and payment details, or build a test data set. Under the GDPR, a copy of customer data on a staging server is still personal data processing with the same obligations; see the article GDPR and choosing a host.
- Turn off email and SMS sending. Staging with a copy of the database can send notifications to real customers. Route outgoing mail to a catch-all test mailbox or disable it.
- Payments in test mode only. Payment providers have test keys and test cards; staging has no need for live keys.
- Check scheduled jobs. Exports to marketplaces, CRM synchronisation and calls to external APIs from cron on staging should go to test environments or be switched off.
- Separate keys and passwords. Contractors and testers get access to staging; no key from staging should open the production server.
Forgotten environments
A forgotten staging server costs money every month and over time becomes the most vulnerable point: nobody installs updates on it, its passwords are old and a copy of the database stays open to contractors who left long ago. A few rules help prevent this:
- every environment has an owner and a deletion date, recorded in its name or in a label in the host's control panel;
- temporary branch environments are deleted after the merge by the same pipeline that created them;
- a permanent staging server is updated together with production and locked down the same way: key-only login, a firewall, security updates (First 10 steps after buying a VPS: security);
- once a month, compare the list of servers in the host's control panel with the list of environments you actually need and delete the rest.