Published: 24 September 2026
A preview environment is a full copy of your application, deployed from a branch, reachable at its own URL, that exists for exactly as long as the pull request does. Reviewers click a link instead of checking out your branch. Designers see the change without a local toolchain. QA tests the thing that is actually about to merge.
The reason teams do not have them is almost never that they are hard to build. It is that a permanent fleet of idle staging servers is expensive, and nobody wants to own the cleanup. Hourly billing removes both objections: the environment costs money only while the pull request is open.
The cost, before anything else
An open pull request in a healthy team lives a day or two. Say the average is 30 hours and you merge 40 a month — 1,200 machine-hours if every one gets its own environment.
| Environment size | Bucharest | Frankfurt | 1,200 h in Bucharest |
|---|---|---|---|
| 4 GB / 2 vCPU / 40 GB | €0.0083/h | €0.0125/h | €9.96 |
| 8 GB / 2 vCPU / 60 GB | €0.0139/h | €0.0222/h | €16.68 |
| 16 GB / 4 vCPU / 80 GB | €0.0222/h | €0.0361/h | €26.64 |
Forty preview environments a month, each an 8 GB machine with full root, for under seventeen euro before VAT. That is the entire business case. The prices are the same six hourly VPS plans we sell for everything else; the full per-country grid is in our location pricing post.
Sizing one
A preview environment does not need production capacity. It needs enough memory to hold your app plus its database plus whatever the test data weighs.
- 4 GB — a single service with a small Postgres or MySQL alongside it, a few hundred megabytes of seed data.
- 8 GB — the common case. Several containers, a real database, a cache, a background worker.
- 16 GB — a full compose stack, a JVM, or an application that loads a large dataset at boot.
Disk matters more than people expect once you are pulling container images. The 8 GB plan carries 60 GB and the 16 GB plan carries 80 GB, which is comfortable for an environment that lives two days.
Building it
1. One machine per pull request, created by your pipeline
The create step belongs in the same workflow that builds the branch. Name the machine after the pull request number so the teardown step and a human debugging at 23:00 both know which is which.
2. Wildcard DNS, so URLs need no DNS round trip
Point
*.preview.example.com at a small always-on router — a 2 GB machine at €4.00 a month in Bucharest is plenty — running a reverse proxy that maps pr-1234.preview.example.com to the right backend. This is far less brittle than creating and deleting a DNS record per pull request and waiting for propagation.3. Seed data, not production data
A preview environment is by definition less hardened than production and its URL will end up in a chat log. Seed it from a fixture set or an anonymised dump. If you are subject to EU data-residency obligations, note that the country is a field on our order form — see our post on choosing which country your VPS sits in.
4. Put it behind authentication
Basic auth at the proxy is enough. The goal is to keep an unfinished feature out of a search index, not to resist an adversary.
5. Delete it on merge or close — and mean delete
This is the step that decides whether the whole scheme saves money. Powering a VPS off does not stop the charges. A stopped virtual machine still holds its RAM allocation, its disk and its IP address on a node, and it bills exactly as a running one does. Destroying it is what stops the meter.
Add a sweeper as a backstop: once a day, list the machines, list the open pull requests, and destroy anything in the first list that is not in the second. Pipelines fail, and a teardown step that only runs on success will leak environments forever.
How the meter works, exactly
- The hourly rate is the plan's monthly price divided by 720 hours. Thirty days of uptime costs the monthly figure; thirty hours costs thirty hours.
- One deduction per clock hour, at the top of the hour, UTC, from prepaid account credit.
- No setup fee. Prices are euro before VAT.
- If credit runs out there is one hour of grace before suspension and 48 hours before termination, with low-credit warnings first and optional automatic top-up. Worth enabling if your merge rate is spiky.
- A monthly summary invoice closes the period, so finance gets one document rather than a ledger of hours.
Where this sits in the rest of the pipeline
Preview environments are deploy targets; CI runners are build machines. They have opposite appetites — runners want CPU and a warm disk cache, previews want memory and a stable URL — so give them separate machines. We covered the runner side in self-hosted CI runners on an hourly VPS, and if what you want to test is behaviour under load rather than behaviour at all, load testing on an hourly VPS is the companion piece.
Try it on one repository
Take your noisiest repository, wire an 8 GB machine per pull request, and run it for a month. If reviewers stop asking "can you screenshot it?", script it for the rest. The bill will be smaller than the meeting you had about whether to do it.