Skip to content
Gigahost Docs

Finding and renting an instance

Finding an offering

Section titled “Finding an offering”

Capacity (/) lists one row per offering. You can filter the rows by location, by cloud or home hosts, by instance type, by the kind of IP, and by the least vCPUs, RAM, disk and the number of instances you can rent. Choosing a row opens the offering’s own page (/offerings/OFFERING_ID).

Under each size the row says how many instances of it can be rented now, such as 12 available, and the offering’s page adds the number of hosts they are on. The count adds up the room of every host that lists the size, one instance after the other. It counts that size alone: the sizes share a host’s room, so renting one size lowers what the others can still take. A cloud host can give an instance of its own an IPv4 address only while it has free ones, and keeps its last one for its largest size, so a size that fits many times counts no more than the host’s free addresses, one fewer for the sizes below the largest; a host that also offers a shared IP counts its room. For a backup kept on one host, the count is that host’s room alone. The count is as fresh as the catalog, and a host’s room is checked again when you create the instance.

The Instance column says what each offering can be rented as: VM, Container, or both, the kind it is offered as by default first, such as Container, VM for a small size. The Host type filter (Any type, or cloud or home hosts) and the Instance type filter (Any type, Virtual machine or Container) keep the virtual machines or the container instances alone. The minimums read “≥ 4 vCPU”, “≥ 8 GiB” and “≥ 12” (Available starts at “≥ 1”); RAM starts at 1 GiB, and Disk runs from 2 GiB to 16 TiB.

The IP filter

Section titled “The IP filter”

The Address filter on Capacity, and --ip dedicated|shared on ghost catalog offerings, choose which address the list prices, orders by and offers. The website starts with the Shared IP, which for a small instance or a container is much of the price (a trial-only account gets it chosen by default); ghost starts with the Dedicated IP, so a script keeps the list it had:

  • Shared IP (shared) is a range of a shared address’s ports. It is where Capacity starts, and each row’s Rent link opens its offering with it.
  • Dedicated IP (dedicated) is an address of the instance’s own: a cloud host’s address, or the gateway a home host gets by default. Choose it in the filter and the list, its prices and its links follow.
  • An offering without the address you chose is not listed, so a cloud offering whose hosts have no address left appears only under Shared IP, and one that lists no Shared IP only under Dedicated IP.
  • With ghost, the price column and the cursor are that address’s.

The kinds of address are explained on Connecting and networking.

What a listing shows

Section titled “What a listing shows”

Each row of Capacity has:

  • its size by its vCPUs, CPU model, RAM and disk; under the CPU model, “Score” with the single-thread score and the size’s total (“Score 1250 / 5000”), or the single-thread score alone for 1 vCPU;
  • its price per month for the chosen address: the base price, with the base price of the gateway a home host gets by default, or nothing more for a cloud host’s Shared IP;
  • its traffic price, a home host’s through that gateway;
  • its location with its provider under it, written “City (CC)”, such as “Bangkok (TH)”, its host type as an icon, and its provider’s record, with each offering’s uptime.

Hovering over the CPU model, the memory type or the disk size shows the CPU’s full name, the memory modules and their speed, and the disks.

Filters

Section titled “Filters”
ghost catalog offerings \
  --mode cloud_routed \
  --country SG \
  --continent AS \
  --provider gh-abcdefgh \
  --min-vcpu 4 \
  --min-ram 8GiB \
  --min-disk 100GiB
Filter Takes
--mode home_gateway or cloud_routed, spelled as the catalog shows them; home-gateway and cloud-routed still work
--location A location slug from ghost catalog locations
--country, --continent An ISO two-letter country_code, a geographic continent_code
--provider A provider’s alias, such as gh-abcdefgh, or its UUID
--min-vcpu The least vCPUs
--min-ram, --min-disk A size in binary units, such as 512MiB, 8GiB or 1TiB
--available The least instances of the offering that can be rented now, at least 1
--ip dedicated or shared
--kind vm, container or any, the default
--for-backup, --host See Create an instance from a backup
  • For --min-ram and --min-disk, M, G and T stand for MiB, GiB and TiB, so 8G is 8GiB, and a bare number is GiB. Decimal units such as 8GB are not accepted.
  • Gigahost applies every filter before it cuts the list. Gigahost does not accept an unknown --location, or a --country or --continent that no location is in, and the message says why, instead of returning an empty list.

Locations

Section titled “Locations”
ghost catalog locations --country US
ghost catalog offerings --continent EU

A location slug from ghost catalog locations goes in provider configuration and catalog filters. display_name is its human-readable label. Locations also include ISO two-letter country_code and geographic continent_code values. US is a country in continent NA; EU denotes geographic Europe. The same geography filters narrow the location list.

Paging through offerings

Section titled “Paging through offerings”
ghost catalog offerings --min-vcpu 4 --limit 50
ghost catalog offerings --min-vcpu 4 --limit 50 --after 3100000.of2_F95QS_EuMsVz4IG5EulOew
  • Offerings are listed cheapest first by their listed price (the base price plus a home offering’s default gateway base price, or with --ip shared the Shared IP’s). A list holds at most 500 at a time, and --limit makes it shorter.
  • When a list comes back full, the CLI says on standard error how to get the next one, with the same filters.
  • --after takes the last offering’s listed price in micro-USD and its ID, joined by a dot.

Private hosts

Section titled “Private hosts”

A provider can keep a host private: only its own account and the accounts it allows rent it, and nobody else sees it in the catalog. When a provider has allowed your account, its private hosts’ offerings appear among the others while you are logged in on the website, with a Private tag on Capacity and on the offering’s page, and in ghost catalog with an account key. They are in the same order, pages and filters as the rest, and you rent them the same way. Once the provider removes your account, they no longer appear and new instances on them are refused; what you already have there keeps running.

Sizes

Section titled “Sizes”

Every host offers one ladder of sizes, each with twice the RAM and disk of the one before:

vCPUs RAM and disk, as a multiple of the 2-vCPU size with the least RAM
1 ¼ (the smallest size)
1 ½
2 1
2 2
4 4
8 8
16 16, and so on up to the largest VM the host takes
  • A mid-step gives more CPU without more memory. Between two sizes of N and 2N vCPUs, from the 2-vCPU size with 2× upward, a mid-step has 2N vCPUs with the N-vCPU size’s RAM and disk, where the 2N-vCPU size exists: 4 vCPUs with the RAM of the 2-vCPU size that has 2×, 8 vCPUs with the 4-vCPU size’s, and so on.
  • A host whose largest VM has 1 vCPU offers three 1-vCPU sizes, with 1, 2 and 4 times the smallest one’s RAM.
  • A size with less than the platform’s least RAM for a VM, currently 1 GiB, is offered as a container instance only, from 256 MiB of RAM: a host with less than 4 GiB of RAM per logical CPU offers its smallest 1-vCPU size that way, and one with less than 2 GiB the second one too.
  • An instance boots with its size’s RAM less 64 MiB, which the VM itself uses on its host (QEMU and its devices): an offering of 4 GiB gives its instance 4 GiB less 64 MiB.

Which sizes are listed

Section titled “Which sizes are listed”
  • The catalog lists only the sizes a host has room for now.
  • A cloud host with one free public address left lists only the largest size that fits and the mid-step with the same RAM.
  • An offering is described by its vCPUs, RAM, disk, and prices. ghost prints a size by its vCPUs alone, such as 4 vCPU, a mid-step’s too.

How a size is priced

Section titled “How a size is priced”
  • Its base price follows its RAM; a mid-step’s is 1.5 times that of the size with the same RAM.
  • The price at full CPU use follows the number of vCPUs alone, so a mid-step’s is that of the next size.
  • With --json an offering also carries cpu_tier, how the platform accounts for what a vCPU reserves.

Offering IDs

Section titled “Offering IDs”

Creating an instance takes the offering ID, of2_ and 22 more letters, digits, -, or _, and the image’s slug, such as debian-13, or its UUID from the response.

  • An offering ID names a configuration group and its exact terms: hardware, prices, and SLA. It is not one physical host: Gigahost chooses an available matching host during creation.
  • Once the provider changes those terms, or no host with them takes new instances, the ID no longer works. Gigahost answers a creation with offering_unavailable, and the catalog lists the current offerings with their new IDs.
  • ghost catalog offering (GET /v1/catalog/offerings/{offering_id}) reads one offering while it is listed.

Comparing providers

Section titled “Comparing providers”

An offering’s own page (/offerings/OFFERING_ID) shows:

  • its hardware with RAM and PCIe details, and its drives (each host’s where their models differ);
  • its CPU score, the average of its hosts’ scores and the size’s approximate total, as the score is measured, once they have run the benchmark;
  • which backups its hosts have room for;
  • its network readings and gateway RTT;
  • its prices, where the base price and the price at full CPU include the gateway you choose, as the rent form’s “What it costs” does;
  • its provider with its rating where it has one, its full reliability record and spend-weighted reviews, which the provider’s page (/providers/PROVIDER_ID) shows too.

Scores are comparisons, not a guarantee of application performance. Missing data is shown as unknown.

Reliability

Section titled “Reliability”

Public provider reliability reports cover completed UTC days in the trailing 365-day window.

  • They include renter-observed uptime after platform-wide incident overlap is removed, plus the count and percentage of abandoned instances (Failed on the website).
  • The observation duration and distinct-instance sample size are always included, so a new provider is not presented as equivalent to a long-running one. An empty or small sample is not equivalent to an established reliability record.

Reviews

Section titled “Reviews”
ghost catalog reviews PROVIDER_ID
ghost account review PROVIDER_ID --rating 5 --message "My experience"

You can review a provider after paid usage with it in the last year. Reviews are public under your account alias. Providers cannot review themselves.

  • Ratings are weighted by net spending on that provider’s service during the last year, excluding gateway charges and subtracting SLA credits.
  • To change a review, give its current revision as --expected-revision. A wrong one gets review_revision_conflict.
  • The first change may follow publication at once, and later ones once a day. A change that comes too soon gets 429 limit_reached, whose message names when the next is allowed.

Network readings

Section titled “Network readings”

Network readings come from each host testing itself against every platform test location, using one randomly picked server per location, once after enrollment and then about every three days.

  • A listing shows the best download, upload, and one-way latency (half the measured round trip) across its hosts with the measurement time.
  • Each host’s network tests page (/hosts/HOST_ID/network), linked from the offering’s page, lists each location’s latest result and the server that took it.
  • A reading marked with a plus (at_limit, such as 1 Gbit/s+) reached the test server’s own uplink limit, so the host may be faster.
  • Unknown (null) means that direction could not be measured or the result has expired; it is not zero.

Gateway RTT

Section titled “Gateway RTT”

Gateway RTT is measured from an existing public gateway to its instance through the tunnel. It is not latency from your own computer. Hosts without a current sample, or instances that block ICMP echo, show no measurement.

Renting an instance

Section titled “Renting an instance”
  1. On the offering’s page, open Rent it.
  2. Pick an operating system, or a backup from the list, which names each backup’s restore charge. Choosing a backup hides the operating systems: the instance keeps the backup’s hostname, which the form shows read-only.
  3. Paste your SSH public key, or leave the saved keys the form offers checked. A label (the instance’s name) and tags are optional, a label also when you restore from a backup; tags are separated by commas or spaces. A collapsed Advanced section holds cloud-init user data and the first-boot command.
  4. For a home instance, choose the gateway tier and, for a shared gateway (shared bandwidth or the shared IP), its location from a drop-down. The gateway cards show the prices at the default location.
  5. Review the costs the form shows, then send it.

Beside the form is the ghost instance create command for what the form holds, which changes as you choose. The form shows the one-time creation fee, refunded if the creation fails for a reason other than yours, and the price per month, the traffic price and the balance reserved while the instance exists, for the gateway you chose.

When no host of the offering has room, the page says what is short, such as cores, memory or a free public address, and when a resting address is free again. A new instance opens its own page.

The gateway tiers and locations are explained on Connecting and networking, and what creation costs on Pricing and billing.

SSH keys

Section titled “SSH keys”

A creation needs at least one SSH public key. Keys saved on your account are installed unless you name others.

  • Repeat --ssh-key-file or --ssh-key to install more than one.
  • A key is one OpenSSH public key line of type ssh-ed25519, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, sk-ssh-ed25519@openssh.com, or sk-ecdsa-sha2-nistp256@openssh.com; DSA keys and certificates are not accepted.
  • Only public keys, such as the .pub file, are accepted: ghost turns a private key down before it sends anything, and so do the website’s forms. The one-line public key from the .pub file is what to paste.
  • How to log in once it runs: Connect with SSH.

Image, hostname and first boot

Section titled “Image, hostname and first boot”
Option Meaning
--image An image’s slug from ghost catalog images, such as debian-13, or its UUID
--hostname Optional; a lowercase RFC 1123 hostname
--name Optional; the name the website and ghost show the instance by, by the same rules. Without it the instance is named after its hostname
--tag Optional, repeated; a tag of the new instance, at most 20. With --backup and no --tag, the instance starts with the tags of the backup’s instance, and --no-tags starts it with none
--startup-command A first-boot shell command
--startup-command-file A multiline first-boot shell program, instead of --startup-command
--cloud-init-file Raw cloud-init user data for advanced initialization; cannot be combined with either startup-command option
--gateway-tier, --gateway-location A home instance’s network; see Connecting and networking
--backup A backup instead of --image; see Backups and restore

ghost checks a --cloud-init-file before anything is created:

  • a #cloud-config is a YAML mapping, a #cloud-config-archive a list, and a #cloud-config-jsonp a JSON Patch array;
  • a script starts with #!, and a MIME multipart document needs a MIME-Version header;
  • without an SSH key, ghost warns when a #cloud-config sets no SSH key or password of its own.

Secrets are best kept out of files that you do not control.

What is checked before anything is created

Section titled “What is checked before anything is created”

The website’s rent form checks the SSH keys, the hostname and the first-boot command before sending anything. ghost instance create rejects at once a --hostname that is not a lowercase RFC 1123 hostname. Once it has read the offering, it also rejects:

  • a --gateway-tier other than shared_ip given for a cloud offering, or one missing for a home one, whose tiers and prices the message lists;
  • a backup whose disk is larger than the offering’s root disk;
  • a container instance on an offering that is rented as a VM only, or a VM on one that is too small for a VM.

An offering that is no longer listed, or a tier the offering does not list now, gets only a warning there, and Gigahost then decides whether it can still be rented. --compact prints none of the quote, and leaves the checks after the hostname’s to Gigahost.

Waiting for the first boot

Section titled “Waiting for the first boot”

With --wait, once the new instance’s kernel has started, ghost waits up to five minutes more for cloud-init in the instance to report how the first boot went.

  • It warns when cloud-init reported errors or finished degraded, listing its messages, or says that it has not reported yet.
  • --compact does not wait.
  • Repeating a creation with the same --idempotency-key returns the job of the first request, and ghost says so, with when that job was made: nothing new is charged. backup create and backup restore say the same of a repeat.

Renting a container instance

Section titled “Renting a container instance”

A container instance is a VM of its own that boots a container image instead of an operating system: the same sizes, prices, disk, backups and addresses as a VM, with less memory spent on a distribution, so it can be smaller. ghost catalog offerings --kind container lists the offerings that take one.

Which kind suits you depends on what you run:

  • A stock image behaves like a small VM: the distribution’s own init system (systemd, or OpenRC on Alpine), SSH with your keys, packages, timers and services, in less memory than a VM needs.
  • A custom image runs one application as its image describes it, with the environment, command and restart policy you give it, and without SSH unless the image runs its own.
  • A VM suits a system that needs its own kernel settings, cloud-init or more than the stock images offer.

An offering with less than 2 GiB of memory or 10 GiB of disk is shown as a container instance by default; you can still rent it as a VM where its size takes one, from 1 GiB of memory and 8 GiB of disk.

On an offering that can be rented both ways, Rent it starts with Instance type: Virtual machine or Container, the offering’s default chosen. An offering rented one way only names its type instead. Choosing Container shows, in place of the operating systems:

  • the stock images the size’s memory takes, each running its init system like a VM, with SSH; they take the SSH keys as a VM does, and environment variables;
  • Custom image, with the image’s reference (a tag or a digest, such as nginx:1.27), its environment variables, an entrypoint and a command as ghost takes them, the user and working directory, and its Restart policy (Always restart, Restart on failure or Never restart);
  • your container instances’ backups that fit, under Or restore a backup.

Each variable’s value is masked, and Show reveals it while you check it. The values go with the request alone: the command beside the form names a variable as --env NAME=… without its value, and Gigahost keeps them encrypted and never shows them again.

--container runs an image of your choice, from Docker Hub or another public registry, by its tag or its digest:

ghost instance create \
  --offering <OFFERING_ID> \
  --container nginx:1.27 \
  --env-file app.env \
  --restart on-failure \
  --wait

The image runs as it is: it gets no SSH keys, cloud-init or startup command, and has no SSH unless the image runs its own, so ghost turns those options down before it sends anything. A tag is pinned to its digest when the instance is created, and ghost instance get shows both.

--stock-image runs one of the platform’s stock images from ghost catalog container-images, such as Debian, Ubuntu, Alpine, Rocky Linux or AlmaLinux. A stock image runs the distribution’s own init system and OpenSSH, so it is reached over SSH with your keys, as a VM is, and ghost x and ghost ghostd install work on it:

ghost instance create \
  --offering <OFFERING_ID> \
  --stock-image debian-13 \
  --ssh-key-file "$HOME/.ssh/id_ed25519.pub" \
  --wait
Option Meaning
--container An image reference, such as nginx:1.27, ghcr.io/owner/app:v2 or REPOSITORY@sha256:DIGEST
--stock-image A stock image’s slug from ghost catalog container-images, such as debian-13
--env, --env-file Environment variables, NAME=VALUE, repeated or as lines of a file; kept encrypted and never shown again
--entrypoint, --command The image’s entrypoint and command replaced, as a JSON array such as '["nginx", "-g", "daemon off;"]'; the entrypoint can also be a single word
--user, --workdir The user and the absolute directory the process runs as and in
--stop-timeout How long a stop waits for the process, 0 to 300 seconds; 10 by default
--restart always (the default with --container), on-failure (the default with --stock-image) or never
--volume A path the instance keeps when it is redeployed, such as /var/lib/app; repeated for more, at most 32
  • One of --image, --container, --stock-image and --backup is always given: ghost does not choose one for you, also for an offering that is offered as a container instance by default.
  • A stock image takes --env, --env-file, --restart and --volume; its own init system runs in place of an entrypoint, command, user or directory.
  • A stock image needs an SSH key, given or saved on your account, as a VM does; it runs no cloud-init or startup command.
  • With --wait, the command waits for the creation, not for cloud-init, and ends with where the instance is and how to read its logs.

Reading a container’s logs

Section titled “Reading a container’s logs”

ghost instance logs prints what the container wrote, its standard output and error, at most the last 64 KiB since it was last started:

ghost instance logs <INSTANCE>
ghost instance logs <INSTANCE> --previous

When the container was started again, by the platform or by its restart policy, the end of what it wrote before comes first, under a heading of its own: the output that made it exit. --previous shows that part alone. The output is printed without the escape sequences that color a terminal, and --json has it as the container wrote it. A VM has no such logs; its console is under Console. On the website the same output is on the instance’s Logs tab; see Logs.

While the instance is created

Section titled “While the instance is created”

Creation stays in provisioning until the host sees the new instance’s operating system start and, for a home instance, its gateway reports a fresh WireGuard handshake; the instance’s billing starts then.

  • The job says what the host is doing, such as how much of the image has arrived. The creation step’s progress follows the download up to 80% and is 90% once the disk holds the image.
  • A home host keeps the catalog’s images downloaded ahead of time, so a creation or reinstall there rarely waits for its image.
  • An image that starts no operating system within five minutes fails the creation with guest_boot_timeout, which is not retried.
  • A new instance is not checked for reachability itself: a cloud instance only gets an address that passed its one-time check, and a home instance’s public address is its gateway’s.

A home instance’s gateway

Section titled “A home instance’s gateway”

A home instance uses one gateway. Its creation waits up to 15 minutes for the gateway to be created and up to 15 more for it to boot, since creating one can take the gateways’ cloud provider several minutes, and longer when its service is slow; --wait prints each wait once.

  • If the gateway is not created or does not become ready in that time, or does not report the handshake, the creation fails, and Gigahost orders no second one.
  • The job’s error then says in plain words what went wrong, that the creation charge is refunded, and that you can try again.
  • gateway_quota_exhausted means that no gateway capacity is available at the moment, and trying again later is the remedy.
  • While a gateway step waits for room among the gateways, the job says so and keeps trying.

A failed creation

Section titled “A failed creation”
  • A failed creation keeps its balance reserve, capacity, and address until its host has removed what the creation left there, which takes moments while the host is online. One that never reached its host holds nothing after the failure.
  • A home instance’s gateway is given up at the failure.
  • These steps continue through restarts of Gigahost or of the provider.
  • What is refunded is under Refunds of a failed creation.