Every team that ships more than once a week eventually wants the same thing: a real environment per branch, so reviewers click a link instead of pulling the code. The usual objection is cost — nobody wants to pay for eight always-on staging servers so that two of them can be used on a Tuesday. Hourly billing removes that objection, because an environment that exists for eleven hours costs you eleven hours.
This is how we would build per-branch preview environments on hourly VPS instances, what the arithmetic actually looks like, and the billing details that decide whether it is cheap or not.
Why a VPS instead of a container platform
Containers are excellent for stateless application code and awkward for everything else a realistic preview environment needs: a database with a seeded copy of production-shaped data, a cron that runs, a queue worker, a mail catcher, a TLS certificate on a real hostname. A full KVM virtual machine gives you a box that looks exactly like production, because it is the same kind of box production runs on.
The trade-off is that you manage it. That is fine for preview environments, because the machine is disposable by design — if it drifts, you destroy it and build another one.
The arithmetic
Take a VPS II KVM: 4 GB of RAM, 2 vCPU, 40 GB of disk. In Bucharest that is €0.0083 an hour. Assume an environment is up during the working day while a pull request is open, roughly 10 hours a day across 20 working days:
| Scenario | Hours | Cost in Bucharest | Cost in Frankfurt |
|---|---|---|---|
| One preview env, 10 h/day × 20 days | 200 h | €1.66 | €2.50 |
| Five concurrent preview envs, same pattern | 1,000 h | €8.30 | €12.50 |
| One env left running all month | 730 h | €6.06 | €9.13 |
| One env on the monthly price instead | — | €6.00 | €9.00 |
The last two rows are the honest part. Hourly billing is not a discount — it is a shape. At around 720 hours the hourly path costs the same as the monthly price, and past that it costs slightly more. Anything you leave running permanently belongs on the monthly price; anything that lives and dies with a branch belongs on hourly. Our billing comparison post works through the same maths for other shapes.
A workable design
1. Build a golden image once
Set up one machine the way a preview environment should look: runtime, web server, database, your deploy user, your monitoring agent, nothing application-specific. Then capture it as your own image from the client panel. Accounts can keep up to three images, billed at €0.06 per GB per month for the space they occupy — a 6 GB image is about €0.36 a month, which is a rounding error against the time it saves.
Every new environment then starts from that image instead of from a stock distribution, so the provisioning step is "pull the branch, run migrations, restart" rather than twenty minutes of package installation.
2. Give each environment a hostname before it exists
Wildcard DNS (*.preview.example.com) pointed at nothing, then an A record written per environment when it is created. Certificates via the ACME DNS challenge, so you are not waiting for HTTP to be reachable. Reviewers get pr-482.preview.example.com and never see an IP address.
3. Seed data that is not production data
Preview environments leak — links get pasted into chat, screenshots go into tickets. Use an anonymised dump or a generated dataset, and if you are in the EU treat this as a GDPR decision rather than a convenience one. Our note on EU data residency covers the hosting side; the anonymisation side is yours.
4. Destroy on merge, not on a calendar
The single behaviour that makes this cheap: the environment's lifetime is the pull request's lifetime. When the branch merges or closes, the machine goes. If your pipeline cannot do that yet, a nightly sweep that destroys anything older than 48 hours is a decent approximation and still cheaper than always-on staging.
Ordering and destroying machines can be driven from your own tooling rather than by hand — see our deploy-by-API write-up and the API documentation.
Billing details that matter for disposable machines
- You need credit before you can create an hourly service. The account has to hold at least €5. Hourly charges come out of that balance each hour, and the month's usage is summarised on an invoice at the end of the month.
- Stopping a machine does not stop the meter. A shut-down VPS still holds its RAM, vCPU reservation and disk, and still bills. To stop paying, destroy it.
- Running out of credit has a schedule, not a cliff. We warn you when your balance is down to about 24 hours of runtime. If the balance empties, the service is suspended after a one-hour grace period and terminated 48 hours after that. Keep a buffer if your preview fleet spikes on release week.
- There is no traffic quota. Preview environments that serve a few hundred megabytes of assets to reviewers cost nothing extra.
Which shape, and where
For most web applications the preview environment can be smaller than production, because it serves five reviewers rather than five thousand users. Start at the shape that holds your stack in memory:
| Shape | RAM / vCPU / disk | Bucharest | Frankfurt · Vienna | Good for |
|---|---|---|---|---|
| VPS I KVM | 2 GB / 1 / 20 GB | €0.0056/hr | €0.0077/hr | A single service plus SQLite or an external database |
| VPS II KVM | 4 GB / 2 / 40 GB | €0.0083/hr | €0.0125/hr | App + PostgreSQL + a worker — the usual choice |
| VPS III KVM | 8 GB / 2 / 60 GB | €0.0139/hr | €0.0222/hr | Several services, a search index, a browser test runner |
| VPS IV KVM | 16 GB / 4 / 80 GB | €0.0222/hr | €0.0361/hr | A full compose stack that mirrors production closely |
Put the environments in the location your team sits in, not the one production sits in — the people waiting on the page load are your reviewers. All five locations (Bucharest, Warsaw, Amsterdam, Frankfurt, Vienna) carry every shape, and the per-location price list shows what geography adds.
What this replaces
Teams arriving at this pattern are usually escaping one of three things: a single shared staging server that everyone queues for, a managed preview product priced per seat, or developers testing on their laptop and hoping. The first is a coordination tax, the second gets expensive at exactly the moment it becomes useful, and the third is why "works on my machine" exists.
A fleet of five preview environments on hourly VPS instances, used during working hours, is under €10 a month in Bucharest. That is cheaper than the shared staging box it replaces, and nobody has to ask whose turn it is.
How Noded Can Help
Start with one VPS II on hourly billing from the hourly VPS page, build it the way your preview environments should look, capture it as an image, then wire your pipeline to create and destroy from that image. If you would rather talk the design through first — how many concurrent environments, which shape, how to seed data — open a ticket and we will go through it with you.
FAQ
Is hourly billing cheaper than monthly?
Only if the machine does not run all month. At roughly 720 hours the two are level; beyond that hourly costs marginally more. Use hourly for machines with a short life and monthly for anything permanent.
What happens if I forget to destroy a preview environment?
It keeps billing at its hourly rate, and it will not stop when the machine is powered off. Set a sweep that destroys anything older than a fixed age, and watch your credit balance — we email a warning when it is down to about 24 hours of runtime.
Do I need to pay upfront for hourly machines?
Yes, as credit: an account needs at least €5 of balance to create an hourly service, and hours are deducted from that balance as they are used.
Can I automate creating and destroying environments?
Yes — machines can be ordered and removed from your own tooling rather than the panel. Our API documentation covers the calls.
Can a preview environment use my own base image?
Yes. Capture an image from a configured machine in the client panel (up to three per account, €0.06 per GB per month of storage) and deploy new machines from it.