# Hourly VPS for staging, demos and load tests: how to use it URL: https://cloudj.net/blog/staging-server-hourly-vps Published: 2026-11-11 ยท Updated: 2026-11-11 > How an hourly VPS is billed (charged while it exists, even stopped), and practical workflows for staging servers, client demos and load tests without surprises. An hourly VPS is the right tool for anything that should exist for hours or days rather than months: a staging copy of production for a risky upgrade, a demo environment for a client meeting, a fleet of load generators for an afternoon. The appeal is obvious. The catch is that hourly billing has rules, and the most common surprise is a server that was "turned off" but kept costing money. This guide explains exactly what you pay for on Cloudj's hourly billing, then walks through three workflows that use it well. ## What you actually pay for on an hourly VPS Cloudj lets you pay for a server by the hour from your account balance, or prepay a term of 1, 3, 6 or 12 months. Hourly billing works like this: | Question | Hourly billing | Prepaid monthly term | |---|---|---| | When does charging start? | When the server is created | When the term is paid | | Is a stopped server charged? | Yes, because its disk and IP stay reserved | Covered by the term | | How do I stop charges? | Delete the server | The term runs to its end; auto-renew is optional | | How is traffic billed? | Per GB used | An allowance is included (for example 1 TB in Singapore, 5 TB in Frankfurt) | | Best for | Short-lived and bursty work | Servers that run all month | The line people miss is the second one. **Stopping a server does not stop hourly charges.** The disk still holds your data and the IP address is still yours, so the server still costs money until it is deleted. If you want to keep the work without keeping the server, save a custom image first, then delete. The console shows the exact hourly price before you deploy, and the [pricing page](https://cloudj.net/pricing) has live rates for every location. For a deeper comparison of the two models, see [hourly vs monthly VPS](https://cloudj.net/blog/hourly-vs-monthly-vps). ## Workflow 1: a staging server for a risky change You are about to upgrade a framework, a database major version or the operating system. Testing it on production is a gamble; a full-time staging server is money spent eleven months a year for nothing. An hourly staging server sits in between. 1. **Pick the same location as production.** Network paths, DNS behaviour and external API latency should match. If production is a [crypto trading bot in Singapore](https://cloudj.net/blog/crypto-trading-bot-vps-singapore) or a [forex VPS in London](https://cloudj.net/blog/forex-vps-london), stage it in the same city. The [VPS locations guide](https://cloudj.net/blog/vps-locations-guide) lists every city. 2. **Match the operating system and size.** Use the same image and the same CPU type. A dedicated-CPU production server tested on shared CPU gives misleading timings. 3. **Copy the data, not the secrets.** Restore a recent database dump, but replace production API keys, payment credentials and email settings with test ones. A staging server that emails real customers is a classic incident. 4. **Block indexing and public access.** Add HTTP basic auth or restrict the firewall to your office IP, and send `X-Robots-Tag: noindex` so search engines never see the copy. 5. **Run the upgrade, write down every step,** then repeat the exact steps on production. 6. **Delete the staging server** when the change is live. If you rebuild staging often, configure it once and save a [custom image](https://cloudj.net/custom-images). The next staging server deploys from that image in the same state. ## Workflow 2: a client demo that disappears afterwards Agencies and freelancers often need a working environment for a presentation or a two-week review. An hourly VPS keeps that cost tied to the project instead of becoming a forgotten line item. A clean pattern: - Deploy the smallest size that runs the demo comfortably (from 1 vCPU, 1 GB RAM and 20 GB disk). - Put it on a subdomain such as `demo-client.example.com` with a Let's Encrypt certificate; the [Nginx reverse proxy with SSL guide](https://cloudj.net/blog/nginx-reverse-proxy-ssl-vps) covers the setup. - Use the browser SSH console in the Cloudj console for quick fixes during the meeting if your laptop's SSH client is not at hand. - Put a calendar reminder for the day the review ends, and delete the server that day. If the client signs off and the demo becomes the real site, move it to a prepaid term rather than leaving it on hourly billing for months. ## Workflow 3: load tests Load testing is where hourly billing shines and where its traffic rule matters most. You might need several machines for two hours, and you do not want them afterwards. Install a load tool such as k6 on each generator and run a scenario: ```bash k6 run --vus 200 --duration 10m script.js ``` Things to plan for: - **Traffic is billed per GB on hourly servers.** A load test can move a lot of data, so estimate it first: average response size multiplied by request count. Run a short test, read the network graph in the console, and extrapolate before the big run. - **Generators need CPU too.** If the generator maxes out its own CPU, you are measuring the generator, not your app. Watch both sides' graphs; choose general purpose or dedicated CPU for generators. - **Test only systems you own or have permission to test,** and warn your upstream providers or CDN if their rules require it. - **Spread generators across locations** if your real users are spread out. A generator in New York, the city traders choose for a [forex VPS in New York](https://cloudj.net/blog/forex-vps-new-york), and one in Tokyo exercise very different network paths. When the report is saved, delete every generator. That last step is the one that keeps the test cheap. ## The cleanup checklist Most hourly billing regret comes from forgotten servers. Before you close your laptop: - List your servers in the console and confirm each one has an owner and a reason. - Delete anything that was only for today; stopping is not enough. - Save a custom image first if you will need the setup again. - Check your balance; hourly servers draw from it continuously. If you need help keeping a server reachable during its short life, the [new VPS security checklist](https://cloudj.net/blog/secure-new-vps-checklist) still applies; a demo server exposed to the internet gets scanned just like production. ## FAQ ### Is a stopped hourly server still charged? Yes. The disk and IP stay reserved while the server exists, so charges continue until you delete it. ### Can I keep a staging setup without paying for it all month? Save a custom image of the configured server, then delete the server. Deploy a new one from the image next time. ### Does hourly billing include traffic? No. On hourly billing traffic is charged per GB used. Monthly plans include an allowance, for example 1 TB in Tokyo or 5 TB in Amsterdam. ### What if the staging server should become permanent? Save a custom image of it and deploy a new server on a prepaid term from that image, then delete the hourly one. You keep the setup and move to included traffic. ## Try it on your next change Create an hourly server in the [Cloudj console](https://app.cloudj.net) for your next upgrade or demo, run your checklist, and delete it when you are done. Live hourly and monthly prices are on the [pricing page](https://cloudj.net/pricing).