Hourly billing cloud servers: what they are and how pay-as-you-go really works

What is an hourly billing cloud server? The simplest answer: the unit you rent a server by changes from the month to the hour, and you pay only for the hours the machine actually existed. If you've ever paid a full month's rent for a server that works a few hours a day, a large part of that bill could have been avoided. Here we look at how the charge is calculated, the lifecycle of a machine, and where this model is the wrong choice.

What is an hourly billing cloud server, and how is it different from monthly rental?

With traditional VPS rental, you pay a fixed amount at the start of each period; it makes no difference whether you use the server all month or for 7 hours. That amount is a prepayment for a time window, not a price for what you used. The hourly, pay-as-you-go model turns this around: the meter starts when the machine is created and stops when the machine is deleted.

The main consequence isn't financial, it's behavioral: on a monthly plan every wrong decision costs at least a month; on hourly billing it costs an hour. This is a tool for managing uncertainty.

Note that "hourly" is a property of the billing, not of the hardware: it's the same KVM machine with an NVMe disk and full root access.

How exactly is hourly billing calculated?

Three factors make up a server's base rate, and you set all three yourself; add-ons are charged separately:

• Server resources — the RAM, CPU cores and NVMe disk you chose when creating the server; they stay fixed until you change them yourself;
• Hours the machine exists — not hours of "useful work", but the hours it occupies space on the host;
• Traffic used — according to the gigabytes you transfer; the only component not tied to time;
• Add-ons — extra IP addresses and automatic backups each carry their own hourly charge, and unlike the server rate, powering the machine off takes nothing off them.

Stop vs delete: "powered off" is not the same as "deleted"

This is where the most common misunderstanding about hourly billing lives. A powered-off server still exists: its RAM, cores, disk and IP address stay reserved on the host, and nobody else can use them. That's why powering off doesn't bring the rate to zero; on Iran servers it cuts it to a percentage of the full rate — the exact percentage is written in the description of each wallet transaction. The only thing that stops the meter is deleting the machine.

So the right logic is: power off for short breaks, delete for long ones, and only after you've pulled your data out. The numerical formula is in our hourly vs monthly VPS billing break-even guide.

What makes a server a "cloud" server?

The word "cloud" has been repeated in advertising so often that it has almost lost its meaning, but it has a clear technical definition: NIST SP 800-145 lists five essential characteristics of cloud computing, three of which make hourly billing possible:

• On-demand self-service — you create the server yourself, without a ticket; if creating one needed human approval, hourly billing would be pointless.
• Rapid elasticity — resources have to change on a scale of minutes, not days.
• Measured service — if you can't see itemized usage, there's no way to verify the bill.

The other two — broad network access and resource pooling — describe the infrastructure: your machine runs on a host whose resources are shared among several tenants, and the layer that does the sharing is the hypervisor. On Iran cloud servers that is KVM; why that matters is covered in our plain-language explanation of KVM and NVMe. You can see the virtualization type from inside the machine:

systemd-detect-virt
kvm

lscpu | grep -i 'model name\|^CPU(s):'
CPU(s):                               2
  Model name:                         AMD EPYC Processor

The cloud server lifecycle: from creation to deletion

1) Creation: three choices, two of which are hard to change later

When you create a server, you choose three things: resources, operating system and hostname. Resources can be increased later; but the operating system can only be changed by wiping the whole disk, and the hostname stays fixed — you'll have to type it by hand when you delete the server. For a production server, an LTS release is the best choice: according to Ubuntu's release cycle, a new LTS comes out every two years and receives five years of standard security updates.

There's also a practical condition: before you create a server, your wallet balance must be at least the larger of two amounts — the minimum top-up, or 24 hours of that server's rate — otherwise you're sent back to the wallet page. On sizing, the rule is the opposite of monthly rental: start small, because the "one size up, just in case" precaution costs money every hour.

2) Delivery and first login: verify what you've been given

The IP address and root password are shown in the panel, and the meter is running from that moment. The first job is to check the specs against your order — the CPU model varies from node to node; what has to match is the number of cores and the amount of RAM and disk:

ssh root@203.0.113.24
The authenticity of host '203.0.113.24 (203.0.113.24)' can't be established.
ED25519 key fingerprint is SHA256:8Xq2p1s0hVwK7mYtRz9c4LbNfQeJdA6uG3xT5oPiWkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '203.0.113.24' (ED25519) to the list of known hosts.
root@203.0.113.24's password:

root@web-01:~# nproc
2
root@web-01:~# free -m
               total        used        free      shared  buff/cache   available
Mem:            3936         210        3402           1         323        3512
Swap:              0           0           0
root@web-01:~# lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
NAME     SIZE TYPE MOUNTPOINT
vda       40G disk
└─vda1  39.9G part /

The first time, you're asked to accept the host key fingerprint; before typing yes, compare it with the fingerprint shown in the panel's graphical console — this is the only moment you can verify the server's identity. If the fingerprint banner has scrolled out of view, log in at the console and run ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub to print it again.

The 3936 in free -m is your four gigabytes (4096 MB); the kernel set those 160 MB aside before it counted memory: the non-freeable parts of the kernel image, a few megabytes of firmware-reserved regions, and memory-management structures (64 bytes for every 4 KB page, which is 1.6% of total RAM). None of these are counted in MemTotal, so the shortfall is normal. The initial RAM disk isn't part of this list; it is freed after boot and returned to MemTotal.

If the disk looks smaller than you expected, don't rush to conclusions either: df and lsblk both count in base 1024 (if the disk is sold in decimal gigabytes, 40 GB shows up as about 37.3G in both), part of the space goes to filesystem metadata, and ext4 reserves 5% for the root user by default. Only worry when the Size column of df doesn't match the partition size in lsblk — the fix is in the next section. Step-by-step login from Windows, Linux and mobile is covered in our guide on how to connect to a VPS with SSH.

3) Scaling up a cloud server midway

When you need more capacity, you don't have to build the server again: increase RAM, cores and disk from the panel's "Upgrade" tab, and the new hourly rate applies from the moment the change takes effect (on older servers, the same tab tells you that resources can't be changed from the panel and that the change goes through support). But there's an important limitation:

Once the server is back up, check the effect:

df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        39G  6.2G   31G  17% /

# after the resize + one restart from the panel
df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        59G  6.2G   50G  11% /

If df still shows the old size, you'll have to do it by hand — pay attention to the package name, because on the RHEL family both the package name and the command that grows the filesystem are different:

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
NAME     SIZE TYPE MOUNTPOINT
vda       60G disk            # the disk is already 60G
└─vda1  39.9G part /          # but the partition is still 40G

growpart /dev/vda 1  # pkg: cloud-guest-utils (Debian/Ubuntu),
                     #      cloud-utils-growpart (AlmaLinux/Rocky/CentOS)
resize2fs /dev/vda1         # ext4 / ext3
# on XFS (the RHEL-family default) use this instead:
xfs_growfs /

4) The end: export first, then delete

Deletion can't be undone, and the disk goes with the machine. So the order is always the same: take an export, move it off the server, check that the files are intact, and only then delete:

# 1) on the server - pack the things that are not reproducible
set -o pipefail                 # bash only - not POSIX sh
D=$(date +%F)
tar -czf /root/www-$D.tar.gz /var/www /etc/nginx
tar: Removing leading `/' from member names          # normal, not an error
mysqldump --single-transaction --routines --events --databases db1 db2 \
  | gzip > /root/db-$D.sql.gz || echo "DUMP FAILED - do not delete anything"
ls -lh /root/*.gz
-rw-r--r-- 1 root root  38M Sep  7 03:11 /root/db-2026-09-07.sql.gz
-rw-r--r-- 1 root root 214M Sep  7 03:11 /root/www-2026-09-07.tar.gz

# 2) from YOUR machine - pull them off the box
scp root@203.0.113.24:/root/*.gz ./

# 3) verify before you destroy anything - BOTH files
ls *.gz
db-2026-09-07.sql.gz  www-2026-09-07.tar.gz
tar -tzf www-2026-09-07.tar.gz > /dev/null && echo "archive OK"
archive OK
zcat db-2026-09-07.sql.gz | tail -1
-- Dump completed on 2026-09-07  3:11:44

Step three matters most: a backup you haven't tested isn't a backup — and "tested" means both files. The compression test checks that the archive is intact, not what's inside it: if the dump never ran, the pipeline still produces a twenty-byte, apparently healthy file that passes that test. So look at the dump's last line; in a complete dump it is always -- Dump completed on …. The date in the file name is the server's date, not your machine's (servers usually run on UTC), so use the name you actually downloaded.

Another silent trap sits in the dump itself: --single-transaction gives a consistent point-in-time snapshot only for InnoDB tables, and MyISAM tables are read outside the transaction. Check the engines with SELECT table_name, engine FROM information_schema.tables WHERE table_schema='db1'; — if any are MyISAM, convert them to InnoDB or take the dump with the service stopped.

Two small details can also break this block. The set -o pipefail option didn't exist in dash — the /bin/sh of Debian and Ubuntu — before version 0.5.12-7: on Ubuntu 24.04 and older it fails with Illegal option -o pipefail, and because set is a special built-in, the script stops right there and the dump never runs (dash gained it in Debian 13 and Ubuntu 26.04). So make the first line #!/bin/bash and run the script with bash script.sh, not sh script.sh, which ignores that first line. And because tar strips the leading slash from paths (a warning, not an error), restore with tar -xzf … -C /.

The complete script and the restore procedure are in our Linux server backup guide. The final deletion is deliberately made harder: you have to type the server's hostname by hand.

The states of an hourly server and what each one means

Being unclear about where one state ends and the next begins costs both money and data:

Don't mix up the last three rows: suspension erases nothing, a rebuild erases the disk, and deletion takes away both the disk and the machine.

Which projects is hourly billing worth it for?

1) Test and development environments

You create the test environment in the morning and delete it at the end of the day; the next day it comes back up from a Compose file in a minute. The condition is that building the environment is automated — setting up Docker on a cloud server is a good starting point.

2) Short-term projects

A campaign, a webinar or a heavy render — anything with an "end date" pays only for that window. The saving is proportional to the part of the month in which the server doesn't exist: significant for a week, negligible for a project that runs to the end of the month.

3) Variable workloads

A shop that only gets busy during seasonal sales doesn't need to pay for a big server all year. Since shrinking a machine means creating a new one, keep the main server at a normal size and create a second machine for the peak.

4) Learning and experimenting

For the cost of a few hours, you get a real server to practice on; a machine destroyed by a wrong command is only a few minutes' rebuild away.

When is hourly billing the wrong choice?

Hourly billing isn't always better:

• An always-on site or API with a steady load. The saving comes from "switching off", and here there's nothing to switch off.
• A team where nobody owns the cleanup. The biggest financial leak in this model is forgotten machines: a server created for a test that stayed for six months.
• A budget approved in advance. A variable bill is a headache for some finance departments, even when it's smaller.
• A service whose downtime has a hidden cost. A database with a warm cache, or a service that is unavailable for several minutes every time it starts.

Quick comparison: hourly vs monthly VPS

Five habits that seriously cut the cost

1. Delete idle servers; don't just power them off. Reserved disk space and IP addresses are resources too; if you won't need a server for a few days, take an export and delete it.
2. Choose the right size. Look at real usage with htop and free -m — the column that counts is available, not used; Linux spends unused RAM on disk cache, and a high buff/cache is not a memory shortage. If available stays above half the RAM even at peak, create a server one size smaller (how to measure is explained in our Linux server monitoring guide).
3. Use traffic wisely. gzip compression — built into nginx, you only have to switch it on — and image optimization both make the site faster and shrink the gigabytes on your bill (brotli compresses better but needs the ngx_brotli module). If your domain's DNS is hosted at Mehran Host, turn on the content delivery network with one switch next to that same A record.
4. Monitor. Look at the usage graph and the transaction ledger once a week; financial surprises arrive when you never look.
5. Consolidate scheduled jobs. Put your nightly scripts together on one small server; several half-idle machines cost more, because each one bills its own share of unused RAM and disk.

Securing a server that's created and deleted every day

Short-lived machines carry a risk of their own: because they're "temporary", nobody takes hardening them seriously. But internet scanners don't care whether a machine is temporary, and every fresh public IP address soon becomes a target for automated login attempts. Three things are required on every machine, even one that lives for a day: SSH key login, password login disabled, and unneeded ports closed.

There's also a point specific to hourly billing: everything you've left outside the machine — a DNS record pointing to the old IP, an active API key, database access on another server — survives the deletion, and cleaning it up must be on your checklist. The full list is in our Linux server security guide.

How do hourly cloud servers work at Mehran Host?

Iran servers are KVM machines with NVMe disks in a datacenter inside the country, and provisioning is fully automatic — no ticket, and no waiting for a business day. You get full root access, and you manage everything from the panel: power on and off, restart, upgrading resources, reinstalling the OS and deleting.

A few details that come in handy in practice: the graphical console opens inside the same panel and works even when the server's network is down — if you lock yourself out with a firewall rule, you don't need to rebuild the machine. IP reachability is monitored automatically, and if the IP assigned at delivery is blocked by Iran's internet filtering, it is replaced right there; for blocks that happen later, you file a "Report an IP reachability problem" request from the server's page and get a replacement if it is confirmed. Automatic backups are optional and not available everywhere; their monthly price is deducted hourly, and restores go through a ticket, because a restore overwrites the entire disk.

You pay from a prepaid wallet in Iranian currency, priced in Toman (the everyday unit of Iran's currency, equal to 10 rials). Unused credit can be refunded on a written request with a stated reason in a ticket, after the account has been reviewed; gift credits (tiered top-up bonuses and promo-code rewards) are excluded, and the refundable amount is calculated after deducting them in full. The rate for every configuration is visible before you create the server, in the calculator on the homepage, and the same engine writes the bill. International cloud servers are ordered from the same wallet, but the rule is different: the machine is billed at the full hourly rate for as long as it exists, and powering it off doesn't reduce the rate; since the rate is updated with the exchange rate, the cost won't necessarily be the same every month, so take the hourly rate at the moment you order as your reference.

Conclusion

Hourly billing lowers the risk of a decision: you create a server, try it, and if it isn't a fit, you set it aside with no penalty; in return, the cleanup is up to you. Three habits are enough: know the difference between powering off and deleting, take an export and test it before you delete, and review your servers once a month. To get started, create an account and top up your wallet.

Frequently asked questions

What is an hourly billing cloud server, and how is it different from a regular VPS?

An hourly cloud server is a virtual machine billed by the hour rather than by the month: from the moment it is created until the moment it is deleted, the price of each hour is deducted from your wallet. In hardware and access it is no different from a regular VPS, the same KVM machine with full root access, but because you create, change or delete it yourself at any time, a wrong decision costs you one hour instead of one month.

If I power off the server, does it stop costing money?

No. As long as the server exists, its RAM, CPU cores, disk space and IP address stay reserved for you on the host hardware, and nobody else can use them. That is why, on Iran servers, powering off cuts the hourly rate to a percentage of the full rate rather than to zero, and on international servers it does not reduce the rate at all. Only deleting the server stops billing completely, and deletion takes the disk and its data with it.

Can I get my data back after deleting a server?

No. Deleting a server is irreversible, and the disk is destroyed along with the machine. Before you delete it, take an export, pull it off the server and test that it is intact. If you enabled the automatic backup add-on, existing copies may still be available, but restoring them goes through support, so do not count on that route as a substitute for taking your own export.

Can I scale down the resources of an hourly server?

No. You can increase RAM, CPU and disk from the panel, and the new hourly rate applies from the moment the change takes effect, but you cannot reduce resources, especially not disk space. To downsize, create a new server with a smaller configuration and move your data across. That is why the practical advice with hourly billing is to start with a small configuration and grow it only when real usage shows you need more.

Is hourly billing worth it for a WordPress site that is always on?

Not in terms of cost: hourly billing saves money when you power off or delete the machine, so for a site that runs all month it makes no significant financial difference. The advantage that remains is having no commitment. You can test for a few days and walk away without paying for a full period if it does not work out, and during a sales peak you can add a helper machine and delete it afterwards.