Pricing and SLA

Newly enrolled hosts start paused. 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 under Price what it earns: Traffic per TiB, Host for the whole host and Instance per instance, both per month (/ m); retired hosts show on Show retired. Open the host there and set what it earns on its Pricing tab (/provider/hosts/HOST_ID/pricing), which lists each size by its vCPUs, with its RAM and Disk, and what it earns now (Current / month) and with what you type (New / month). The host’s Overview shows its prices on one line under its capacity. For a cloud host, add its addresses under Provider › IP pools and let them pass their check. Then resume new rentals on the host’s Settings tab when you are ready. You set and change a host’s prices only there or with the API (ghost provider set-pricing), never in the host’s configuration or a deployment file, and a change needs neither a new enrollment nor a deployment.

The prices you set are what you earn. Renters pay each of them 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 ($85.00 earned costs a renter $100.00; $3.672 a month per instance costs $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.

You set what you earn per instance and month, and what you earn for compute: the price a month of one vCPU that has a core of its own, with the host’s full RAM and disk per vCPU. You may give it as a total for the whole host instead, which is divided by the host’s saleable vCPUs when you publish (its vCPU limit per NUMA node times its NUMA nodes) and kept 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 rental with a core for each vCPU earns exactly $100.00 of compute a month, and every smaller size its share of it. The whole-host amount the website shows is worked out from what you set and the host’s vCPUs now. 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 final price of each size is rounded down, to a whole micro-dollar. Each rental earns its size’s share of the compute earnings. Your host offers one ladder of sizes, each reserving twice the cores, RAM, and disk of the one before: a quarter of a core and half a core with 1 vCPU, one core and two cores with 2 vCPUs, then as many cores as vCPUs, 4, 8, 16 and so on up to your host’s limit. Between two sizes with a core for each vCPU, N and 2N vCPUs, a mid-step has 2N vCPUs on the N cores, RAM, and disk of the smaller one, for a guest that needs more CPU but not more memory: 2 vCPUs, 4 vCPUs on 2 cores, 4 vCPUs, 8 vCPUs on 4 cores, 8 vCPUs, and so on, where the larger size exists. No size has less than the platform’s least RAM for a VM, 768 MiB: a host with less than 3 GiB of RAM per logical CPU offers no quarter of a core, and one with less than 1.5 GiB no half core. 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; the hypervisor guide says what RAM a host needs for them. A size’s compute earnings follow the cores it reserves: a quarter of a core earns a quarter of a core’s. A mid-step earns 1.5 times the size whose cores it shares, halfway between that size and the next. Only the compute part scales with CPU utilization. At full CPU use a VM earns 1.5× the compute earnings of as many whole cores as it has vCPUs, so the sizes that reserve less than a core for a vCPU earn less only below full CPU use. What you earn per instance stays the same, for both cloud and home VMs. 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.

Traffic is metered by the platform, never by your hypervisor: by the router VM on a cloud host and by the hosted gateway of a home VM. 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. 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 public IPv4 address: 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 a higher amount is refused. 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. It applies to rentals with an address of their own only: a rental that shares your host’s own address (shared IP) takes none of your addresses and pays nothing for the shared IP: your fixed price per rental covers it, and there is no price for it to set. It pays your base, CPU and traffic prices as any rental does.

Backups are no part of your prices. A backup stored on your host costs renters the same on every host, $0.001 per GB to create and to restore and $0.01 per GB per month for storage, and you earn what your customers pay for the backups on your host less the same platform share of 15%. The backup’s traffic is not charged.

Choose an SLA of 98%, 99.5%, or 99.9%, with downtime credits of 1×, 5×, or 20× the rental’s base price for the downtime. SLA changes affect new rentals only. They do not change an existing customer’s guarantee.

Setting prices on the website

The Pricing tab shows what the host earns now: per instance, per vCPU (with the vCPUs a whole-host total was given for), for the whole host at its vCPUs now, per TiB of traffic and per address on a cloud host, and the SLA. Its form asks for amounts in dollars. The compute earnings have two linked fields, You earn per vCPU and or for the whole host: typing in one fills in the other, and the one you changed is what is published (the one you typed in last, if you changed both). If you change neither, or type the amount shown back, the compute earnings stay exactly as they are while you change the other prices. The table of sizes shows what each one earns now and with the amounts in the form. Every amount on the page is what you earn; renters pay each one plus the platform’s share. The form asks for a reason, kept with the change (up to 500 bytes).

Publishing with ghost

Save your desired profile as pricing.json:

{
  "fixed_instance_earnings_microusd_per_month": 3672000,
  "compute_earnings": {"microusd_per_month": 13770000, "vcpus": 1},
  "network_earnings_microusd_per_tib": 8704000,
  "sla_target_basis_points": 9800
}

These are example values. CLI/API amounts use micro-USD: 1,000,000 micro-USD is $1. What you earn per instance and for compute is per 30-day month, so this example earns $3.672 a month per instance and $13.77 a month per vCPU, $220.32 for a host of 16 vCPUs. Instead of compute_earnings the file may give a total for the whole host, "base_host_earnings_microusd_per_month": 220320000, which is kept for the host’s saleable vCPUs at publication; give one of the two, not both. Traffic earnings are per TiB of guest ingress plus egress, here $8.704 per TiB; for a home host they have to be 0. You can earn at most $43,200 a month per instance and for the whole host (what a vCPU earns times the host’s vCPUs); the refusal of a higher traffic amount names the most the renters’ traffic ceiling lets you earn. A cloud host’s file may add "address_earnings_microusd_per_month", what each rental’s address earns a month (0 on a home host), or give it 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, and the refusal of a higher amount names the most the address ceiling lets you earn. A profile that still names local backup prices is refused: remove the three local_backup_… lines.

ghost provider set-pricing HOST_ID --file pricing.json --expected-revision 0 --reason "Initial pricing"
ghost provider pricing HOST_ID

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 now, and 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 vCPUs now. The values of ghost --json provider pricing HOST_ID are a valid pricing.json, with the whole-host total. For an update, supply the current revision instead of zero. This prevents an outdated editor from overwriting another change.

Existing customers

New rentals earn your new prices immediately. 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; every revision has its own 90-day delay.

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. Raising a price further needs 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.

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.

Payout availability and reviews

Unresolved billable outages pause payout eligibility until SLA credits are finalized. A queued payout that has not reached signed submission can be cancelled to settle those credits. Each credit is debited from your earnings as what the rental would have earned you for the downtime, times its multiplier, even below zero; a negative balance blocks payouts until later earnings cover it. The customer receives the credit at you only: it pays your later charges to that customer before their balance does and is never withdrawn. A payout takes from your earnings exactly what it pays you. Payouts go only to the payout address you set with ghost provider set-payout-address; see provider payouts.

Customers can review a provider after paid usage. Ratings are weighted by net spending on that provider’s service during the last year, excluding gateway charges and subtracting SLA credits. Providers cannot review themselves.