What bills in each state
Three meters run on an elastic machine, and only one of them depends on whether the guest is powered on. The Cloud VPS page prints the running rate per hour, but compute is counted by the second.
| State | Compute | Disk and IPv4 | Egress |
|---|---|---|---|
| Running | Billed per second | Billed every hour | Per GB sent |
| Stopped | Not billed | Billed every hour | Nothing is sent |
| Released | Final invoice: last usage | Final invoice: last usage (billed while the machine exists) | Final invoice: last usage |
Ingress is free in every state. Egress has no monthly allowance and is never shaped, which is the opposite of the monthly plans, where a fixed allowance is included and traffic past it is slowed to 10 Mbit/s.
Stopping a machine does not end its bill. The disk and the address accrue an hourly charge while the machine exists, stopped included.
Jobs that fit per-second compute
- A test environment for an afternoon. Build it, run the tests, release it before the evening.
- CI and build bursts. A runner that exists for a release week; the self-hosted GitHub Actions runner page covers registering one.
- A load-test client. The generator belongs outside the system under test, and only for the length of the run; see sizing a k6 load generator.
- A one-off batch job. A conversion, an import or a data crunch that finishes and is never run again.
- Trying a stack before committing. Install it yourself on a clean image and throw the machine away afterwards. On the Cloud VPS, Docker, GitLab, Coolify, PostgreSQL, Redis and the other one-click apps can be picked at order and install at first boot on Ubuntu 24.04; larger apps need a larger flavor.
What these share is a clear end. If you cannot say when the machine will be released, it is probably not a short job.
The flavors and their limits
Elastic machines use the same five flavors as the monthly plans, from 1 vCPU with 1 GB of memory and 25 GB of SSD up to 8 vCPUs with 16 GB and 320 GB. Each is a KVM guest on an OpenStack host in New York, the one region it is sold in.
- vCPUs are not pinned: processor time is shared with other guests on the host, not reserved.
- The hypervisor caps disk operations and disk throughput per guest, reads and writes counted together. A larger flavor raises both caps.
- The virtual port is capped at the flavor's speed in each direction.
- Images are Ubuntu, Debian, AlmaLinux and Rocky Linux from their official cloud images, with the QEMU guest agent added. There are no Windows images.
- Addressing: a single IPv4 plus an IPv6 /96. Outbound TCP 25 is closed by default; 465 and 587 are open.
For a short job the caps matter more than the core count. A batch import bound by disk operations will finish no sooner on more vCPUs if the IOPS cap is what it hits.
Running a batch job that survives the SSH session
Paste your SSH keys on the order page and they are installed for root when the machine is built. Then hand the job to systemd rather than to the terminal: systemd-run starts the command as a transient service unit, so a dropped connection does not kill it, and its output lands in the journal.
# on the VPS: run the job as a transient service
systemd-run --unit=batchjob --working-directory=/root/job /root/job/run.sh
# follow its output, or check whether it has finished
journalctl -u batchjob -f
systemctl status batchjob
# from your workstation: copy the results off before releasing
rsync -az --partial root@vm.example.net:/root/job/results/ ./results/--unit= names the unit. Give the script's full path: --working-directory= sets where it runs (systemd 240 and later), not where systemd-run looks for the command. journalctl -u reads that unit's log. In rsync, -a is archive mode, -z compresses in transit and --partial keeps a half-copied file if the link drops. Copy everything you need before releasing; our advice is to assume nothing on the disk survives the release.
Stop or release
Power control sits in the Virtual Machines tab: start, stop, reboot, and a hard reset for a guest that has stopped answering. The choice between stopping and releasing is a billing decision.
- Stop when you will come back to the same disk: a test environment paused overnight, a runner idle between release days. Compute stops; disk and address keep billing.
- Release when the job is done. Since disk and address accrue an hourly charge while the machine exists, releasing it should be what stops them; a final invoice carries the last usage.
- Reinstall only to start clean on the same machine. It erases the disk, and the dashboard asks you to type the host name first.
How the account is charged
Nothing is paid up front. Checkout stores a card and places a hold worth one week of running; the page says the hold lifts after the first payment. Usage is billed at month end, or earlier once it crosses a small threshold; a released machine's remaining usage lands on a final invoice. It sits on the same account and dashboard as any servers, domains and invoices you already have.
Elastic, monthly, or a whole machine
| Elastic Cloud VPS | Monthly Cloud VPS | Dedicated server | |
|---|---|---|---|
| Billed | Compute per second while running; disk and IPv4 hourly | Monthly or yearly, in advance | Month to month; 3, 6 or 12 months prepaid for a discount |
| Traffic | Egress per GB, no allowance | Egress allowance, then shaped to 10 Mbit/s | Unmetered port, no allowance |
| Processor | Shared vCPU time | Shared vCPU time | Every core, nobody else on it |
| Systems | Linux images only | Linux images only | Linux, Windows, your own hypervisor |
| Best for | Jobs with a known end | Small, steady jobs | Busy all day, every day |
Our advice: compare before you commit. The elastic flavor table has a running-all-month column, which the page describes as 730 hours of compute on top of the disk and address, before egress and tax. Set it beside the monthly price of the same flavor, and remember the monthly plan includes an egress allowance while elastic charges every GB sent. A job that keeps every core busy, hits the largest flavor's IOPS cap, needs a GPU or Windows, or sends traffic month after month belongs on a dedicated server. A racked machine is handed over in about 30 minutes after the order is approved; a built-to-order line takes 4 to 24 hours.
Questions
Is a stopped VPS free?
No. Stopping ends the compute charge, but disk and IPv4 accrue an hourly charge while the machine exists, guest up or down. Releasing it from the dashboard should therefore be what stops them; a final invoice carries the last usage.
Is it billed by the hour or by the second?
Compute is metered in seconds of uptime, although the page quotes the running rate per hour. Disk and address accrue an hourly charge while the machine exists. Egress is charged per GB.
Is any traffic included?
Not on the elastic flavors. Every GB sent is charged, with no allowance and no throttle, and incoming traffic is free. The monthly plans work the other way round: an included egress allowance, then shaping to 10 Mbit/s.
Do I pay anything when ordering?
No payment up front. A card goes on file with a hold worth one week of compute, and usage is billed at month end, or earlier once it crosses a small threshold.
Where does it run, and can it run Windows?
In New York, on OpenStack hosts that Server Room operates; it is not sold in other regions. The images are Ubuntu, Debian, AlmaLinux and Rocky Linux. Windows is available on dedicated servers, not on the Cloud VPS.
When is a dedicated server the better buy?
When the job has no end date and keeps the processor busy, outgrows the IOPS cap of the largest flavor, needs a GPU or Windows, or pushes heavy egress every month. A dedicated server gives you every core and an unmetered port, billed month to month.