Skip to content

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.

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.

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.

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 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_UUID lists the sizes that are not offered in sizes_below_minimum_memory and sizes_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.

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.

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.

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.

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.

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.

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 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%.

  1. Open the host under Provider › Hosts and its Pricing tab (/provider/hosts/HOST_ID/pricing).
  2. 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.

Before you open a newly enrolled host to rentals, publish what it earns.

  1. 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
    }
  2. 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
  3. For an update, give the current revision, which the command returns, instead of zero. This keeps an outdated editor from overwriting another change.

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_month still 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-earnings on ghost 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.

ghost provider pricing shows what the host earns as published:

  • its values, whose base_host_earnings_microusd_per_month is what the compute earnings make for the whole host today;
  • beside them compute_earnings as 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.

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.

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.

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.

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).