Pricing and SLA
The prices you set are what you earn. You set them per host, once it is enrolled:
- what you earn for compute, per vCPU or as a total for the whole host;
- on a cloud host, what you earn per TiB of a rental’s traffic and per rental’s public address;
- the host’s SLA.
You set and change a host’s prices on its Pricing tab on the website or
with the API (ghost provider set-pricing). The agent’s configuration and
deployment files do not hold prices, and a change needs neither a new
enrollment nor a deployment. Before the host accepts rentals, its capacity,
storage-pool, location, and pricing setup need to be complete in your
provider account.
What renters pay
Section titled “What renters pay”Renters pay each of your prices plus the platform’s share: the platform keeps 15% of what renters pay for your prices, so a renter pays what you earn divided by 0.85, rounded up to a whole micro-dollar.
| You earn | A renter pays |
|---|---|
| $85.00 | $100.00 |
| $3.672 a month | $4.32 |
If the platform’s share ever changes, what you earn does not: renters’ prices change instead, lower ones at once and higher ones after 90 days’ notice.
The fixed price per instance
Section titled “The fixed price per instance”There is no price per instance for you to set. Since 2026-10-21 the fixed price per rental is Gigahost’s own: it is the same on every host, added to every rental’s base price whatever its size, and none of it is yours, nor is any platform share taken from what you earn for it. It is $0 today. A host whose prices still named an amount per instance had its prices published again without it, at once for new rentals and after the 90-day notice for existing ones; your next change of prices can follow 24 hours later, as after any publication. Should Gigahost change its fixed price, new rentals take it at once and existing ones after 90 days’ notice, as with your own prices, and your SLA credits leave it out.
Your host offers one ladder of sizes. Each size has twice the RAM and the disk of the one before:
- two sizes with 1 vCPU;
- two sizes with 2 vCPUs;
- then 4, 8, 16 vCPUs and so on, each with the host’s full RAM and disk per
vCPU (
memory_bytes_per_cpu_core,root_storage_bytes_per_cpu_core).
The last size has cpu_core_limit_per_numa_node vCPUs, a power of two or
not. No VM has more, and every VM remains within one NUMA node.
A mid-step is a size for a guest that needs more CPU but not more memory. Between two sizes of N and 2N vCPUs, from the larger 2-vCPU size up, a mid-step has 2N vCPUs with the RAM and disk of the N-vCPU size, where the 2N-vCPU size exists.
The ladder of an example host
Section titled “The ladder of an example host”With 4 GiB of RAM and 64 GiB of disk per logical CPU and a limit of 16, the sizes are these. Compute earnings are a multiple of what the 2-vCPU size with the least RAM earns, which is what you set per vCPU.
| vCPUs | RAM | Disk | Compute earnings |
|---|---|---|---|
| 1 | 1 GiB | 16 GiB | 0.25 |
| 1 | 2 GiB | 32 GiB | 0.5 |
| 2 | 4 GiB | 64 GiB | 1 |
| 2 | 8 GiB | 128 GiB | 2 |
| 4, mid-step | 8 GiB | 128 GiB | 3 |
| 4 | 16 GiB | 256 GiB | 4 |
| 8, mid-step | 16 GiB | 256 GiB | 6 |
| 8 | 32 GiB | 512 GiB | 8 |
| 16, mid-step | 32 GiB | 512 GiB | 12 |
| 16 | 64 GiB | 1 TiB | 16 |
A VM weighs on the host’s scheduler in proportion to its RAM. A mid-step weighs as much as the size with the same RAM, the 4-vCPU mid-step as much as the larger 2-vCPU size. A node holds as many VMs as their CPU shares allow, each with its size’s RAM, 64 MiB of which is the VM’s own overhead; How much RAM the host needs says what RAM a host needs for them.
The platform’s minimums
Section titled “The platform’s minimums”The platform offers no new VM with less than 1 GiB of memory, counted on the size’s RAM, 64 MiB of VM overhead included, or with less than 8 GiB of root disk, which most images need. A size of your host with less of either is not offered, so the ladder starts higher.
- A host with less than 4 GiB of RAM per logical CPU does not offer the smallest 1-vCPU size, and one with less than 2 GiB not the second one either.
- With
memory_bytes_per_cpu_core = "1.5G"the two 1-vCPU sizes would have 384 MiB and 768 MiB, and the smallest VM the host offers is the first 2-vCPU size, with 1.5 GiB. - With
root_storage_bytes_per_cpu_core = "25G"the smallest 1-vCPU size would have 6.25 GiB of disk, and the smallest VM is the second 1-vCPU size, with 12.5 GiB.
The larger sizes are not affected, and VMs that run keep their size when a minimum changes.
- The host’s Overview tab lists every size with its RAM and disk and whether it is offered, noting a size with too little RAM, too little disk or both.
ghost provider host get HOST_UUIDlists the sizes that are not offered insizes_below_minimum_memoryandsizes_below_minimum_disk.- The host’s Pricing tab says the same under what each size earns.
Enrollment boots the smallest and the largest size the host will offer.
Gigahost does not accept a host none of whose sizes has both minimums, and
its message names the …_per_cpu_core setting to raise.
Compute earnings
Section titled “Compute earnings”What you set for compute is the price for a month of one vCPU with the host’s full RAM and disk per vCPU, as the sizes that are not mid-steps from the larger 2-vCPU size up have it.
- A size’s compute earnings follow its RAM, as the table above shows.
- A mid-step earns 1.5 times the size with the same RAM, halfway between that size and the next.
- Each rental earns its size’s share of the compute earnings.
- Only the final price of each size is rounded down, to a whole micro-dollar.
Per vCPU or for the whole host
Section titled “Per vCPU or for the whole host”You can give the compute earnings as a total for the whole host instead. Gigahost divides it by the host’s saleable vCPUs when you publish (its vCPU limit per NUMA node times its NUMA nodes), and keeps it exactly as the total and those vCPUs, never as a rounded rate.
- $100.00 for a host of 7 vCPUs is kept as $100.00 for 7 vCPUs, so the base price of a 7-vCPU size that is not a mid-step earns exactly $100.00 of compute a month, and every smaller size its share of it.
- The website has one compute field, You earn for the whole host ($ per month), and no per-vCPU field; the backend divides it by the host’s saleable vCPUs. A price shows per vCPU, such as “$2.50 / month”, without the whole-host amount beside it.
- If a host’s capacity is raised later, the price of every size stays as it was, for new and existing rentals; the whole-host amount grows with the vCPUs, and nothing is published again.
CPU utilization
Section titled “CPU utilization”Only the compute part scales with CPU utilization. At full CPU use a VM earns 1.5× the compute earnings of as many vCPUs at your price per vCPU as it has. The sizes with less than the host’s full RAM per vCPU (both 1-vCPU sizes, the 2-vCPU size with the least RAM, and the mid-steps) therefore earn less only below full CPU use.
A home VM’s gateway is paid for separately by its renter and is not affected by CPU utilization.
When a rental pays
Section titled “When a rental pays”A rental pays the base price from when its creation succeeds until its deletion completes, whatever the VM’s power state, except while your host is down: the downtime that SLA credits count bills no base price and no CPU time. A stopped VM is billed like a running one except that it uses no CPU time.
Traffic
Section titled “Traffic”The platform meters traffic, never your hypervisor: the router VM on a cloud host and the hosted gateway of a home VM do. It is billed as counted, including while your host is down.
- On a cloud host you set what you earn per TiB of a rental’s traffic.
- A home host earns nothing for traffic: its customers pay the traffic rate of their gateway, and your prices name traffic earnings of 0. The one exception is the LAN mesh: what a customer’s instance on your home host sends to an instance on another home host of the same local network is billed at the LAN mesh price, $1.00/TiB, all of it yours, with no platform fee (see Home mode). The bytes billed are the lower of your host’s count and the receiving host’s, so what you earn over a link to another provider’s host rests on that host’s count too: traffic it does not count earns you nothing. Earnings shows the LAN mesh as its own line and each host’s mesh traffic over the last 30 days, and a host’s Usage tab its days.
- A platform ceiling protects renters against an unexpectedly large traffic price.
- GB and TB labels mean GiB and TiB; monthly prices use a 30-day month.
Addresses
Section titled “Addresses”A cloud host can also earn for each rental’s Dedicated IP: an amount per rental and month, whatever its size, which renters pay beside the base price for as long as the rental is billed and keeps its address.
- It starts at $0.
- A platform ceiling, at most $10 a month, protects renters against an unexpectedly large address price, as the traffic ceiling does for traffic. While it is $0, which it is until Gigahost raises it, an address earns nothing, and Gigahost does not accept a higher amount.
- A home host earns nothing for addresses: its customers pay their gateway for theirs, and your prices name address earnings of 0.
- Like your other prices, a new address price applies to new rentals at once and to existing ones after the 90-day notice.
The address price applies to rentals with a Dedicated IP only. A rental with a Shared IP of your host’s own address takes none of your addresses and pays nothing for the Shared IP: there is no price for it to set. It pays your base and CPU prices as any rental does, and twice your traffic price, rounded up: you earn twice your traffic earnings per TiB of its traffic, and the platform its share of the whole. Your published traffic price, and its ceiling, stay as you set them.
Backups
Section titled “Backups”Backups are no part of your prices. A backup stored on your host costs renters the same on every host, at the platform’s local backup prices, and you earn what your customers pay for the backups on your host less the same platform share of 15%.
Setting prices on the website
Section titled “Setting prices on the website”- Open the host under Provider › Hosts and its Pricing tab
(
/provider/hosts/HOST_ID/pricing). - Type the amounts you want to earn, in dollars, and publish.
The Pricing tab shows what the host earns today:
- per vCPU (with the vCPUs a whole-host total was given for);
- for the whole host at its current vCPUs;
- per TiB of traffic and per address on a cloud host;
- the SLA.
The compute earnings are one field, You earn for the whole host ($ per month). If you type the amount shown back, the compute earnings stay exactly as they are while you change the other prices.
The table of sizes lists each size by its vCPUs, with its RAM and Disk, and what it earns today (Current / month) and with the amounts in the form (New / month). Every amount on the page is what you earn; renters pay each one plus the platform’s share.
Publishing with ghost
Section titled “Publishing with ghost”Before you open a newly enrolled host to rentals, publish what it earns.
-
You save your desired profile as
pricing.json:{"compute_earnings": {"microusd_per_month": 13770000, "vcpus": 1},"network_earnings_microusd_per_tib": 8704000,"sla_target_basis_points": 9800} -
To publish it, with revision 0 the first time, and read it back, run:
ghost provider set-pricing HOST_ID --file pricing.json --expected-revision 0 --reason "Initial pricing"ghost provider pricing HOST_ID -
For an update, give the current revision, which the command returns, instead of zero. This keeps an outdated editor from overwriting another change.
The fields
Section titled “The fields”These are example values. CLI/API amounts use micro-USD: 1,000,000 micro-USD is $1.
| Field | What it is |
|---|---|
compute_earnings |
What a vCPU earns per 30-day month, {"microusd_per_month": ..., "vcpus": 1}; here $13.77 a month per vCPU, $220.32 for a host of 16 vCPUs |
base_host_earnings_microusd_per_month |
Instead of compute_earnings, a total for the whole host, such as 220320000, kept for the host’s saleable vCPUs at publication; you give one of the two, not both |
network_earnings_microusd_per_tib |
Traffic earnings per TiB of guest ingress plus egress, here $8.704 per TiB; for a home host they have to be 0 |
address_earnings_microusd_per_month |
A cloud host’s, what each rental’s address earns a month (0 on a home host); optional |
sla_target_basis_points |
The SLA: 9900 for 99%, 9990 for 99.9%, 9999 for 99.99% |
- You can earn at most $43,200 a month for the whole host (what a vCPU earns times the host’s vCPUs). Gigahost does not accept earnings above the configured platform ceilings.
- A file from before that names
fixed_instance_earnings_microusd_per_monthstill works while the amount is 0. Gigahost does not accept any other amount, since there is no price per instance to set, and its message says so: nothing is published that you did not set. - When Gigahost does not accept a higher traffic amount, its message names the most the renters’ traffic ceiling lets you earn.
- You can also give the address earnings with
--address-earningsonghost provider set-pricing. Left out, the host’s address earnings stay as they are, so a file from before it changes none. When Gigahost does not accept a higher amount, its message names the most the address ceiling lets you earn.
What ghost provider pricing shows
Section titled “What ghost provider pricing shows”ghost provider pricing shows what the host earns as published:
- its
values, whosebase_host_earnings_microusd_per_monthis what the compute earnings make for the whole host today; - beside them
compute_earningsas you gave it (for 1 vCPU, or the whole-host total for the host’s vCPUs then); - and
saleable_vcpus, the host’s current vCPUs.
The values of ghost --json provider pricing HOST_ID are a valid
pricing.json, with the whole-host total.
Existing customers
Section titled “Existing customers”New rentals earn your new prices at once. Existing instances receive a notice with their new prices and the exact effective time, then switch automatically after 90 full days. This applies to increases and reductions.
- You can change a host’s prices once every 24 hours, and every revision has its own 90-day delay.
- The policy includes instance prices, traffic, address prices and gateway base charges.
- A backup keeps the storage and restore prices recorded when it was made, even if its source instance has been deleted.
The increase limit
Section titled “The increase limit”An increase for an existing instance is limited per price component to a multiple of the price in effect when you publish; the platform sets the multiple, ten times by default.
- A higher published price still applies to new rentals at once, while existing instances switch to the capped price and their notice shows both.
- To raise a price further, you publish another revision after the first one has taken effect.
- A component whose price in effect is zero is not limited this way; only the platform’s price ceilings bound it.
- The same limit applies when Gigahost changes its gateway prices.
You choose an SLA of 99%, 99.9%, or 99.99% together with the prices
(sla_target_basis_points, or the Pricing tab’s form). Its downtime
credits and payout holds are in the table under
SLA tiers.
An SLA change affects new rentals only. It does not change an existing customer’s guarantee.
The tiers were named 98%, 99.5%, and 99.9% until 2026-10-20, with the same credits and holds; every host and rental kept its tier under the new name. Files and scripts of before still work: 9500 and 9800 are taken as 99%, and 9950 as 99.9%. 9900 and 9990 are tiers today and are taken as they are, so a file that still says 9990 for the old 99.9% now gets 99.9%, with its 5× credit.
What the uptime is measured to
Section titled “What the uptime is measured to”Your host’s agent sends a heartbeat every 30 seconds. An outage opens only once none has arrived for 60 seconds; it then starts 30 seconds after the last heartbeat and ends with the first one after it. So a host that is back within 60 seconds of its last heartbeat records no outage: one gone for less than 30 seconds never does, and one gone for up to about a minute may not, depending on when it went. Once an outage opens, it is measured to about one heartbeat, 30 seconds, at each end. Time when the fault was the platform’s own does not count.
At 99.99%, 30 days allow about 4.3 minutes of downtime, under nine heartbeats: one restart that takes longer than that misses the target for the month. At 99.9% they allow about 43 minutes, and at 99% about 7.2 hours. The credits count every outage, within the target or beyond it.
Where to find it on the website
Section titled “Where to find it on the website”The website’s Provider pages have the tabs Hosts (/provider),
Incidents, Earnings, Payouts and IP pools.
- Hosts lists each host with its state (Accepting while it takes new rentals), Type (cloud or home), location, VMs (its rentals), CPU model, the RAM and disk installed, its SLA, and, as plain columns, Traffic per TiB and the price of the whole host per month. A host that takes no new rentals shows it in its state badge.
- Retired hosts show on Show retired.
- Opening a host there leads to its Pricing tab.
- For a cloud host, you add its addresses under Provider › IP pools and each address needs to pass its check (Registering public addresses).