Skip to content

Manage instances

Signed out, the website shows the capacity on offer (Capacity), About and how to log in. Signed in:

  • its header links Capacity, Instances, Backups, Billing, Provider and Support;
  • an account menu at the right has Account, Notices, Activity, the theme and Log out;
  • the footer links Status, which shows how the platform is doing.

Every account can rent instances and host them too; for an account without hosts the Provider page lists the steps that add one. Times show in your browser’s time zone. How amounts are rounded, and what works on a phone, is in the FAQ.

Open Instances and choose an instance by its hostname. Its page (/instances/INSTANCE_ID) has the tabs Overview, Usage, Backups, Activity, Console and Settings.

  • Details: its operating system, size, location and provider, network (a cloud host, or the gateway of a home host), its bandwidth limit, firmware, when it was created and since when it is billed, the balance it reserves, and its ID.
  • Hardware: what its host’s offering shows (the CPU model and benchmark, the memory’s type and speed, the root disk’s RAID and the disks, and the CPU, RAM and PCIe inventory), with a link to rent another instance like it while that offering is listed, or Sold out.
  • Price: its prices; the gateway’s only for a home instance, the address’s for a cloud instance whose provider charges for it.
  • cloud-init: how cloud-init in the instance ended the latest boot: done, done with warnings (degraded), failed with errors, or not reported yet. A boot with warnings or errors lists what cloud-init reported.
  • Now: current metrics, which keep updating (Pause updates holds them). Traffic under Now is in the bit/s unit it fills, such as kbit/s or Mbit/s.
  • For a home instance, Gateway traffic; see Gateway traffic of a home instance.

instance get, and --json for either command, show all of an instance:

  • its size (vCPUs, RAM, and root disk), firmware, location, provider, and host mode;
  • image: the image its root disk now holds, which after a restore is the backup’s;
  • active_job, while a job runs on the instance or one of its backups: the job’s kind, current step, and progress. It names the job that holds the instance, such as a restore, rather than a backup deletion that runs beside it;
  • last_restore, the newest backup restored over the instance, and restored_from_backup_id, the backup the instance was created from;
  • name, what the website and ghost call the instance, and hostname, the hostname Gigahost set in the instance’s system at its creation or last reinstall;
  • guest_initialization, what cloud-init in the instance reported of its latest boot: done, degraded or error, with its messages and when it came;
  • for a deleted instance, when it was deleted (deleted_at) and when its billing ended (billing_ended_at).
ghost instance rename <INSTANCE_UUID> shop
ghost instance delete shop --yes
  • Every command that takes an instance’s ID also takes its name, as instance list shows it, in any case. ghost instance delete shop --yes first prints the ID the name stands for. A name two instances share needs the ID.
  • instance rename gives an instance another name, by the rules of a hostname: a lowercase RFC 1123 hostname of at most 253 bytes.
  • A rename changes only what the website and ghost show, at once and without a job, in any state but deleted; the instance’s system and its hostname stay as they are. A reinstall’s --hostname changes the hostname and leaves the name.

The power buttons, in the instance’s header above every tab, follow its state: Stop, Reboot and Reset while it runs, Start while it is stopped.

Action What it does
Stop (stopped) Asks the instance’s operating system to shut down, again every five seconds while it runs, and forces it off if it has not after two minutes
Reboot (reboot) Does the same and starts the instance again, keeping its address, so an instance whose system ignores the request is rebooted all the same, up to about two minutes later. It finishes once the operating system starts, which can be a little before SSH answers
Reset (reset) Forces the instance off at once, without asking it, as a reset button does, and starts it again like a reboot
Start (running) Starts a stopped instance
  • Use a reset for an instance that hangs.
  • An instance that starts no operating system within five minutes fails the reboot or reset with guest_boot_timeout, and keeps running.
  • An instance that is paused, or that never got as far as starting its operating system, cannot act on the request and is forced off at once.
  • A stopped instance cannot be rebooted or reset: the request is refused with instance_stopped.

Asking for the state an instance is in already, running for a running instance or stopped for a stopped one, sends nothing to the host: the answer is a job that has already succeeded, whose result says changed: false, and --wait returns at once.

An instance counts as running only when its system has reported a reading since its last power change, reinstall, upgrade, or restore; otherwise running goes to the host, which starts an instance whose system powered itself off. A reboot always goes to the host.

Every action stays on its page and shows its progress in place, without reloading the page. Stopping, rebooting, deleting, reinstalling, upgrading, restoring and resetting ask you to confirm first.

The Console tab opens at the newest lines and follows new output by itself, about every five seconds, while you are scrolled to the end; Pause updates holds it still while you read.

The console shows the end of what the instance’s system wrote to its serial console: the boot messages of its kernel and system, a kernel panic, cloud-init’s result, or why a system does not come up.

  • The host sends it within about ten seconds of the instance’s system writing it.
  • It is shown without the escape sequences that color or restyle a terminal.
  • Once the platform has started the instance again, for a reset, a reboot, a stop and start, an upgrade, a reinstall or a restore, the output is what the instance’s system wrote since. The end of what it wrote before, at most 64 KiB too, comes first, above the line --- the platform started the instance again here --- (previous_boot in --json). So a long boot does not push out the kernel panic you reset it for.

Reinstall, on the Settings tab, accepts your root SSH public keys, cloud-init user data and an optional first-boot command (an SSH key or cloud-init user data is needed). It reinstalls the system the instance runs, unless you choose another. The form checks the SSH keys, the hostname and the first-boot command before sending anything.

  • The reinstalled instance starts running even if it was stopped before.
  • Reinstalling is free, so to start over on the same size, reinstall the instance rather than delete it and create another, which costs the creation fee again.
  • Log in as root: the image’s usual default user, such as ubuntu, gets no keys. Saved SSH keys are installed as on a creation.
  • A failed bounded attempt leaves the instance in failed state with its allocation fenced; repeat reinstall explicitly to delete any partial replacement and try again.
  • An image that starts no operating system within five minutes fails the reinstall with guest_boot_timeout, which is not retried, and leaves the instance powered off: reinstall another image or delete the instance.

Upgrade, on the Settings tab, lists the sizes of the host the instance can take, each with its prices and what the upgrade adds to the balance the instance holds. A size the host has no room for at the moment is shown and cannot be chosen.

An instance can be upgraded to a larger size of its host in place: more vCPUs, memory or disk, and no less of anything. From a size of N vCPUs that has a mid-step above it, the mid-step of 2N vCPUs keeps the memory and disk and adds vCPUs, and the next size doubles the vCPUs, memory and disk.

  • The instance is shut down, given the size’s CPUs, memory and disk, and started again if it was running. It keeps its disk, its address and its hostname.
  • What the upgrade adds to the hold is the new size’s hold less the current size’s, at the days of its base price the instance was created with.
  • From the moment the host reports the new shape the instance pays the size’s prices as the catalog offers them now, and a price change the provider had given notice of before no longer applies to it.
  • Should the upgrade fail on the host, the instance is left stopped with its old size and terms, and what the upgrade took is given back; start it again or retry.
  • A root filesystem grows into a larger disk on the next boot where cloud-init runs, which every catalog image does; on another system grow it yourself.
  • The list is empty while the host takes no new instances, or while its traffic price is above what the platform accepts now.
  • An upgrade to an offering of another host is refused with offering_not_on_host, since an upgrade does not move an instance.
  • One to the instance’s own size or a smaller one is refused with not_an_upgrade, which names in what the offering is smaller.
  • When the host has no room for the size, the refusal is capacity_unavailable, naming what the host lacks beside what the instance holds, and so it is while the host where the instance runs takes no new instances.
  • Each refusal points to ghost instance upgrades.

Deleting an instance on the website asks you to confirm first.

  • Deleting an instance keeps its backups, which stay billed for storage until you delete them.
  • An instance whose creation failed can be deleted once its host has cleaned it up, and that deletion completes at once.
  • Deleting a deleted instance again returns the same deletion job.
  • An instance created from a hosted backup waits up to 15 minutes for you to authorize its restore, holding its capacity and balance meanwhile; its Overview offers to delete it meanwhile. Deleting it then ends its creation: the creation counts as a failure you caused (restore_authorization_abandoned), so its creation fee and restore charge are not refunded, and the deletion gives back the rest once the host has removed the instance.
  • What happens to the address is under An address after deletion.

The Usage tab (/instances/INSTANCE_ID/usage) shows the history each day, each UTC month when you choose Monthly (?resolution=monthly), or every 15 minutes when you choose 15 min (?resolution=15m).

  • It shows its CPU as the busy share of its vCPUs, its memory, traffic in and out, disk read and written, and under Charges what each period was charged (what the charges mean).
  • A 15-minute period shows up a little after it ends.
  • Today (UTC) leads the days with its usage so far and what its billed periods were charged.
  • A month is the sum of its days, the current one with today so far, and a page shows at most 12 months.

The Billing page has three tabs:

  • Charges and credits (/billing), which you can filter by instance and by kind;
  • Deposits (/billing/deposits);
  • SLA credits (/billing/sla-credits).

What each row and total means is on Pricing and billing.

ghost account notifications
ghost account notifications mark-read <NOTIFICATION_UUID>...
ghost account notifications mark-read --all
ghost account notifications mark-unread <NOTIFICATION_UUID>

Lifecycle warnings such as provider retirement and unrecoverable-host notices are durable and can be listed independently of jobs, and marked read. A low-balance warning that ends is marked read by itself; see The warning.