Skip to content
Gigahost Docs

Managing instances

The website

Section titled “The website”

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, a theme switch (Light or Dark; the website starts dark) 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.

Listing and inspecting instances

Section titled “Listing and inspecting instances”

Instances lists your newest instances, 50 at a time, by name. An instance’s page (/instances/INSTANCE_ID) has the tabs Overview, Usage, Mesh, Backups, Activity, Console and Settings.

  • The State column shows an icon for each state: running, stopped, provisioning, pending payment, deleting, failed and deleted each have a shape of their own, in the state’s colour. A job under way (a creation, an upgrade, a restore, a backup) shows a turning icon in its place, a still one when your system asks for reduced motion. Hovering over the icon, or reaching it with the keyboard, shows the state in words, and the job with its step; screen readers read the same words.
  • The list leaves the creation time and the traffic price to the instance’s own page, so its columns are the instance, its CPU load now, its state, address, vCPUs, RAM, disk, price a month, location and system. Beside each instance’s name are its tags, each a link to the instances that carry it. A shared IP instance’s address comes with the public port its SSH is reached on (203.0.113.7:1021), the one its connect command uses, and its copy button copies both.
  • The filters above the list narrow it to a state (or every state, deleted instances too), a location, a provider, a host type (cloud or home), a system, a tag (each with how many of your instances carry it), or names that start with what you type (an instance’s name is its hostname until you rename it). Each offers only what your current instances use. They apply as soon as one changes; a start that no name can have, such as one with a space or an underscore, simply lists none.
  • The list is in the order of the instances’ names, from A, until you choose another. The Instance, vCPU and Price / m headers sort it by the name, the size (vCPUs, then RAM, then disk) or the price a month the instance pays now, as the column shows it (a price change in effect, an upgrade, a home instance’s gateway and an address all count), and a second click turns the order round. The Sort by and Order filters do the same on a phone, where the list shows no headers, and Sort by can also sort by the creation time. Each sort starts its own way: names from A, the largest, the costliest and the newest first. Instances that tie follow each other by their creation time in the same direction.
  • Sorting by price works out what each instance pays at every read, so it is there for accounts of up to 10,000 current instances; with more, the list says so and links to it sorted by name.
  • The page’s address keeps the filters and the sort, so a link or the back button brings the same list back, and the list’s updates keep them too. When the filters hide every instance, the list says which ones did and links to the list without them.

The Overview tab

Section titled “The Overview tab”
  • Details: its hostname and tags, 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 its host’s CPU score, 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.
  • For a container instance, Details names its image in place of the operating system (a stock image by its name; your own as you named it, with the digest its tag was pinned to), its container’s status and its restart policy, and there is no cloud-init:
    • Running; Restarting at a time, while its restart policy waits to start it again after an exit; or Stopped;
    • how often it was started again since it was last started, and how its process last ended: its exit code or the signal that ended it, and why;
    • the restart policy: Always restart, Restart on failure or Never restart, what happens when the process exits by itself.
  • 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.

HTTP proxy domains

Section titled “HTTP proxy domains”

In Settings → HTTP proxy, choose Add domain or Edit beside an existing domain. Each card’s Save changes only that domain. Cancel restores its saved settings and closes the editor; on a new card it discards the draft. The address preview follows the subdomain as you type.

HTTP connects to the app’s HTTP port and accepts an optional Host header override. HTTPS passthrough requires your hostname and a direct DNS-only CNAME to the managed target shown on the card. The CNAME preview appears before you save, and the saved record stays visible. The app must serve its matching TLS certificate; the detailed networking instructions cover certificate and DNS requirements. Shared IP proxies use an incoming TCP forward; the status names its final guest port.

The default active limit is ten domains per instance. Separately, your account may reserve 100 names on each gateway across its instances. Removed names stay reserved to protect old links and cookies, so removing one does not free that budget. You can reuse a name already reserved to your account, including after an operator lowers the limit. A move to a gateway with no room marks affected domains as conflicts while the instance completes its move.

What ghost instance get shows

Section titled “What ghost instance get shows”

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;
  • tags, its tags, sorted, left out when it has none, and redundant_tags, those of them that are redundant;
  • 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).

Names instead of IDs

Section titled “Names instead of IDs”
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.

Tags

Section titled “Tags”

Tags are your own labels for grouping instances, such as env:prod, team-a or client-a, which the instance list and the backup list filter by.

ghost instance tag <INSTANCE_UUID> add env:prod team-a
ghost instance tag web-1 remove team-a
ghost instance tags
ghost instance list --tag env:prod
  • A tag is 1 to 32 lowercase letters, digits, hyphens, underscores, dots and colons. A tag in capitals, such as Prod, is refused rather than changed, so a tag reads as you typed it. An instance carries at most 20, each once.
  • Only you and the platform’s operators see an instance’s tags. They are never sent to its host, never shown to its provider, and never part of a public page.
  • instance tag adds or removes tags at once, without a job, in any state but deleted. Adding a tag the instance has, or removing one it lacks, changes nothing. On the website the instance’s Settings tab lists its tags, each with a button that removes it, and has a field that adds some, separated by commas or spaces.
  • instance tags lists your tags, each with how many of your instances that are not deleted carry it, the first 500 in alphabetical order; the instance list’s Tag filter offers the same.
  • A reinstall, an upgrade, a restore over the instance and a gateway change keep its tags. A deleted instance keeps them too, so its backups still list under them. An instance created from a backup starts with the tags the backup’s instance carries then, unless the creation names others (see Renting an instance).
  • The API changes them with POST /api/mut/v1/instances/{id}/tags, whose body names the tags to add and to remove, and lists them with GET /v1/instances/tags.

Redundant tags

Section titled “Redundant tags”

Two instances you run for redundancy, a pair of web servers or a database and its replica, help only if they do not fail together. Gigahost fills one host before the next, so without a hint both would usually land on the same host. Marking a tag they share redundant keeps them on different hosts.

ghost instance tag redundant web on
ghost instance tag redundant web off
  • A new instance that carries a redundant tag goes to a host of its offering that runs none of your other instances with that tag, filling the others as before. When every host of the offering with room already runs one, the creation is refused with the tag named, and a larger offering, or one at another location, may have a host left.
  • Each redundant tag is its own group: web and db spread independently, and an instance that carries both is kept apart from the instances of each. Tags without the flag, and other accounts’ instances, place as before.
  • An instance counts while it is not deleted (a failed one while its host still holds it), so deleting one frees its host for the next. The hosts are different machines, which may still be of the same provider and at the same location.
  • An instance created from a backup, or a restore into a new instance, places the same way, with the tags it starts with. An upgrade stays on its host and is not checked.
  • Marking a tag is refused while two of its instances share a host, and so is adding a redundant tag to an instance on the host of another that carries it; the refusal names the instances, and nothing changes. Clearing the flag and removing a tag always work.
  • instance tags shows which tags are redundant, and lists every redundant tag, also one that none of your instances carries now (with 0), so a flag you no longer need can be found and cleared. On the website a redundant tag’s chips carry a server’s icon; the switch is on the tag’s list, the Instances page filtered by that tag, beside the filter.
  • The API sets the flag with POST /api/mut/v1/instances/tags/{tag}/redundant and the body {"redundant": true} (or false), the tag’s colons written %3A.

Power

Section titled “Power”

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
  • A reset is the way to recover 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: Gigahost answers the request with instance_stopped.

A state the instance is in already

Section titled “A state the instance is in already”

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.

On the website

Section titled “On the website”

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 for your confirmation first.

Console

Section titled “Console”

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). A long boot therefore does not push out the kernel panic you reset it for.

The live console

Section titled “The live console”

The live console is the instance’s serial console as it runs, over SSH: you can watch a boot as it happens, answer a prompt the system stopped at, and log in when its network, its firewall or its SSH server keeps you out. It is there for virtual machines; a container instance has none, and its output is in its logs.

With ghost:

ghost instance console <INSTANCE_UUID>

ghost runs your system’s ssh and checks the console server’s host key against the one it was built with, so even the first connection is checked. The instance can be named by its name too.

With plain ssh, the user name is the instance’s ID:

ssh -p 2222 <INSTANCE_UUID>@console.gigahost.cloud

Once a key has opened a console by an instance’s ID (as ghost instance console always does), the instance’s name works as the user name too, where no other instance of your account has it. Anyone can save a public key on an account, and many are published, so the console takes a name from a key only once it has seen that the account holds the key: someone who saved your key cannot draw your session to an instance of theirs by giving it the same name. With one key on several accounts, a name that instances of two of them have opens neither; the ID always works.

The console server’s host key is an Ed25519 key with the fingerprint SHA256:kp6RsL9ErACM8gR1TJkQtl2PlkGkB1rPE7clCq5NVmk. ghost instance console checks it for you; if plain ssh shows another fingerprint, it is safest not to go on.

The console lets in a key you saved on your account (SSH keys), for your own instances: ssh offers the keys of your SSH agent or ~/.ssh as it does for any server. Any other key, or a name that is not one of your instances, gets the same Permission denied (publickey) after a second, whatever the reason: checking ghost account ssh-keys list and naming the instance by its ID usually finds it. After 10 refused connections from one address in 15 minutes, that address is refused until those 15 minutes have passed; a connection that logs in counts none, however many keys it tried first. Each key ssh offers that the console does not take costs a second, so with many keys in your SSH agent it helps to name the saved one: ssh -o IdentitiesOnly=yes -i ~/.ssh/<KEY> -p 2222 <INSTANCE_UUID>@console.gigahost.cloud.

The session starts with a short banner and the last screen of the console log, so a system that already stopped at a prompt shows it, then follows the console live.

Logging in. The console reaches the system’s own login: prompt, which asks for a password you set in the instance yourself (with passwd, say): the platform sets none, and root has no password unless you give it one. Without one, resetting the SSH access or a rescue boot is the way back in.

The menu. Ctrl-] followed by a key opens it; Ctrl-] itself never reaches the instance:

After Ctrl-] What it does
. or q Disconnects.
b Sends a break to the serial port. A Linux system with magic SysRq turned on takes it as SysRq, and the next key chooses the command.
r Resets the instance, as its reset button would, once you type yes.
p Powers it off and on again, a stop and then a start, once you type yes; the console attaches again when it runs.
? Shows the menu.

A reset and a power cycle are the instance’s own power actions: the same rules apply (a hold, a job under way, the daily job limit), and they show in the Activity tab as jobs you started. A power cycle is two jobs, and a hold lets a stop through but not a start, so a power cycle whose start would be refused is refused before it stops anything.

What it shows, and who sees it. What the console shows also goes into the console log, as anything the system writes to its console does; a password you type at a prompt is not shown, so it is not there either. The console’s traffic passes through the instance’s host and its provider’s agent, as the instance’s own traffic does: a provider is root on its host and can reach the same console. Typing secrets other than a password into the console is best avoided.

One session at a time. A new session of an instance takes over from the one open, which is told so and closed; an account can have as many sessions open at once as it has instances, and a few more. A session ends after an hour without input or output either way, when the instance is stopped or deleted, and within a minute of the key it logged in with being removed from your account, so removing a key you no longer trust also ends what it opened; the reason is shown before the connection closes. A session also ends when the platform’s console server restarts, during an update for example, which the Activity tab shows as a platform restart. Each session is listed in the instance’s Activity tab, with when it started and ended, the address it came from and the key’s fingerprint. Operators can open any instance’s console for support; each such session is recorded in the operator audit.

If you can’t reach your instance over SSH

Section titled “If you can’t reach your instance over SSH”

When a virtual machine still boots but its SSH server, its keys, its network settings or its firewall keep you out, resetting its SSH access is the quickest way back in, and it keeps everything on the disk. With a password you set in the instance, the live console lets you log in and fix it from the inside.

On the instance’s Settings tab, SSH access has Reset SSH access: your saved keys come checked, you can paste more, and Stop the firewall is there when a firewall rule may be the cause.

The platform restarts the instance (a stopped one is started), and at that boot cloud-init in it runs the platform’s reset once, as root:

  • the keys are added to root’s authorized_keys; the keys already there are kept;
  • the SSH server lets root in by key, from a setting that comes before every other one and stays after the reset, and is restarted, unless its configuration does not pass sshd -t: then it is left as it runs, and the report says why. Where the other users’ keys are read from stays as it was; if your configuration reads root’s keys from somewhere else, root’s authorized_keys is read beside it;
  • the platform’s network settings for the instance are applied again, in place of what its own configuration says;
  • with the firewall option, ufw, firewalld, nftables and iptables are stopped for that boot only, and start again at the next.

The result appears on the Overview tab and in ghost instance get (access_reset), part by part, a few minutes after the restart. The reset needs cloud-init in the instance: a system without it, with it turned off, or that does not get as far as its userspace reports nothing, and after 10 minutes the result says so. For such a system a rescue boot is the other way in. A container instance has no cloud-init; redeploying it is the way to a fresh start there.

Rescue boot

Section titled “Rescue boot”

When a virtual machine does not boot at all (a kernel or initramfs that fails, an fstab entry that drops it into emergency mode, a broken boot loader), or you cannot reach it even with a reset of its SSH access, a rescue boot lets you repair it without losing its disk. The instance boots the platform’s rescue system, a small Debian system that runs from memory, in place of its own, at its own addresses and with its own size, and its disk is attached to it unmounted.

On the instance’s Settings tab, Rescue has Rescue boot: your saved keys come checked, and you can paste more. Once the rescue system has started, the Overview tab shows its host key, the command to log in and End rescue.

In the rescue system you log in as root, by key only. The guest’s disk is /dev/vda (also /dev/disk/by-id/virtio-gigahost-guest), and nothing on it is mounted or assembled at boot. mount-guest mounts its root filesystem at /mnt with the local filesystems of its fstab, including those on LVM or software RAID, and the system directories a chroot needs; mount-guest --ro mounts it read-only. Then you can fix it as if you were inside it:

mount-guest
chroot /mnt
# edit /etc/fstab, reinstall a kernel, run grub-install ...
exit
umount-guest

fsck, LVM, mdadm, cryptsetup, parted, GRUB, nano and vim are there. An encrypted root is opened with cryptsetup open first, then mounted with mount-guest /dev/mapper/NAME.

The rescue system’s host key is new every time, and is not your instance’s own. The command ghost prints checks it: ghost files the key under a name of its own, ghost-rescue-<instance ID>, and SSH then accepts that key alone. With the plain ssh root@ADDRESS the Overview tab shows, we recommend comparing the fingerprint SSH asks about with the one shown beside it before you answer yes. If your SSH already knows the instance’s own key at that address, it refuses the rescue system’s as a changed key: ghost’s command is the way in then. Your instance’s own host key stays as it was, and is the one it answers with again once the rescue ends.

While the rescue lasts:

  • the instance is billed as running, as it uses its size on the provider’s host; the rescue system and its console run there as your own system does;
  • a backup, a restore, an upgrade, a reinstall, a change of its gateway, a reset of its SSH access and another rescue wait for its end, and so do the instance’s scheduled backups, which skip their runs and say so;
  • a reboot boots the rescue system again, and so does a start after the rescue system shut itself down;
  • the console shows the rescue system’s output.

To end the rescue, use End rescue on the Overview tab or

ghost instance rescue <INSTANCE_UUID> --exit

The instance boots its own system again from the same disk. If that system still does not boot, the end says so, and the rescue has ended all the same: a new rescue boot lets you carry on with the repair. A reset of the instance ends the rescue the same way, and a stop ends it and leaves the instance stopped: its next start boots its own system. A rescue boot is for virtual machines; a container instance is redeployed instead.

Logs

Section titled “Logs”

A container instance has a Logs tab beside Console, with what its container wrote, its standard output and error, at most the last 64 KiB since it was last started. It opens at the newest lines and follows new output about every five seconds, as the console does, and Pause updates holds it still. When the container was started again, the end of what it wrote before has a section of its own, Before the last start: the output that made it exit. ghost instance logs prints the same; see Reading a container’s logs.

The Console tab stays: it shows the instance’s serial console, where the platform’s init and the image’s own init system write.

Inside a stock image

Section titled “Inside a stock image”

A stock image runs the distribution’s own init system, so its commands work as on a VM:

  • poweroff inside it stops the instance, whatever its restart policy, and it stays stopped until you start it.
  • reboot inside it starts it again after a second, also whatever its restart policy.

Reinstalling

Section titled “Reinstalling”

Reinstalling is for a VM: a container instance has no operating system to reinstall, and is redeployed onto another image instead.

Reinstall, on the Settings tab, takes 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); the last two sit in a collapsed Advanced section. 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. To start over on the same size, reinstalling is cheaper than deleting the instance and creating 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. Repeating the reinstall deletes any partial replacement and tries 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. Reinstalling another image or deleting the instance are the ways forward.

Updating a container

Section titled “Updating a container”

Update refreshes a custom container’s current image tag from its registry. You can optionally select a new tag of the same registry and repository; that tag is saved for later updates. A digest reference stays on its pinned image unless you supply a tag. Stock images use pinned platform releases and do not support this action, with or without a tag. Use Change image and settings below, or ghost instance redeploy --stock-image, to select the stock image and SSH keys.

On a custom container’s Settings tab, Update shows the current image. Leave New tag empty to refresh that reference, or give a tag such as 1.28, then choose Update and confirm.

Update keeps all environment variables and secrets, entrypoint and command overrides, user, working directory, stop timeout, restart policy and configured volumes and kept paths. It also keeps the size, storage allocation, host, networking, public address and forwarded ports, including Shared IP port ranges and mappings. You do not need to resubmit them.

Configured kept paths and the VOLUME paths of the current and new images keep their data. Everything else on the root disk is replaced. The instance stops temporarily, then runs if it ran before or stays stopped if it was stopped. The host snapshots the root first; a failure before commit rolls back to it. If rollback fails, or the new image was already committed when the job failed, the instance may remain stopped; a committed new image remains installed. Starting the instance finishes the existing recovery steps. The job reports the error. Update is free and needs temporary room for the snapshot on the host.

Change image and settings

Section titled “Change image and settings”

A container instance can move to another image, or to another version of its image, on its own root disk. This keeps its address, its size and its paths that hold data, and replaces everything else on the disk with the new image.

Change image and settings, on the Settings tab of a container instance, starts as the instance is: the stock image it runs is chosen and marked current, or Custom image with the reference it runs, so redeploying the same tag moves to that tag’s newest version. A setting left as the form shows it stays as the instance has it:

  • The entrypoint, command, user and working directory of your own image show as the instance has them, empty where the image’s own applies; a value given replaces it. One the instance has cannot be emptied here, because a redeploy keeps a setting it is not given; starting from a new container’s settings takes the new image’s own instead.
  • The environment stays as it is unless Replace the environment is checked. The instance then gets exactly the variables given, or none. The page never shows the current values.
  • Kept paths lists the instance’s volumes, which can be removed or added to; the list is sent only when it differs.
  • A stock image gets the SSH keys checked and pasted, as a reinstall does.

Start from a new container’s settings makes the redeploy work like creating a new container on the same disk, as --reset does with ghost. The settings then start as a new container’s: the entrypoint, command, user and working directory empty, so the image’s own apply, the restart policy at its default, no environment variables and no kept paths. Whatever you fill in is used; the current environment and kept paths are dropped otherwise. Unchecking it brings the form back to the instance’s settings.

Choose Apply changes. Before anything is sent, the confirmation names the new image, lists the paths that keep their data and says what becomes of the environment, including when every variable is removed. The command under the form does the same with ghost, where an environment replaced by none is --env-file /dev/null and a new container’s settings are --reset.

The advanced ghost instance redeploy command remains available for scripts and for changing the repository or settings.

What is kept:

  • The instance’s volumes: the paths given with --volume when it was created, or at its last redeploy, such as /var/lib/app.
  • The VOLUME paths of the image the instance runs and of the new one, as Docker keeps them.

Everything else on the root disk is replaced by the new image. Data you want to keep is safest under one of those paths; a redeploy that names --volume replaces the instance’s volumes with the ones given, and --no-volumes keeps none of its own.

  • Settings left out stay as the instance has them: its environment, entrypoint, command, user, directory, stop timeout and restart policy. The ones given replace them, as at a creation. With --reset, the ones left out take a new instance’s defaults instead (no environment, the image’s own entrypoint and command, no volumes of its own).
  • Before it changes anything, the host takes a snapshot of the root disk. The instance is stopped while the new image is unpacked and runs afterwards if it ran before. A failure before commit rolls back to the snapshot, keeping the previous data and settings; the failure limits described above apply if rollback fails or commit has begun.
  • Without --yes, ghost says what the redeploy keeps and replaces and changes nothing. With --wait, it waits for the redeploy and ends with the image and digest the instance runs.
  • A stock image (--stock-image) gets your SSH keys, those given or the ones saved on your account now, as at a creation. Moving to a stock image is much like a reinstall: the distribution starts afresh, apart from the paths kept.
  • Redeploying is free. The host needs room for the snapshot while the redeploy runs; a host without it refuses the redeploy (host_lacks_room_to_redeploy), and trying again later is the way forward.
  • A new image that the registry refuses or that does not start is rolled back too, and the job’s error says so.
  • Rarely, the host cannot finish a redeploy: its rollback fails, or the new image is in place but the host could not end the redeploy (container_redeploy_committed, which leaves the new image the instance’s). The instance is then stopped, and starting it finishes the redeploy first.
  • A redeploy that no host can take for an hour, for example while the platform updates its hosts, fails without changing anything (redeploy_unavailable), and trying again later is the way forward.
  • A backup taken before a redeploy onto another image or version holds the old image’s disk, so it restores into a new instance rather than over this one; backups taken since restore over it as usual.

Upgrading

Section titled “Upgrading”

Upgrade, on the Settings tab, lists the sizes of the host the instance can take (its current size is listed, disabled, as Current), 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.

What an upgrade does

Section titled “What an upgrade does”
  • 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.
  • If the upgrade fails on the host, the instance is left stopped with its old size and terms, and what the upgrade took is given back. You can 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, growing it is up to you.
  • A container instance’s root filesystem grows by itself into a larger disk each time it starts, stock image or your own.

When there is no upgrade

Section titled “When there is no upgrade”
  • 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 gets offering_not_on_host, since an upgrade does not move an instance.
  • An upgrade to the instance’s own size or a smaller one gets not_an_upgrade, which names in what the offering is smaller.
  • When the host has no room for the size, the answer is capacity_unavailable, naming what the host lacks beside what the instance holds. It is the same answer while the host where the instance runs takes no new instances.
  • Each message points to ghost instance upgrades.

Changing the gateway

Section titled “Changing the gateway”

A home instance can change its gateway’s tier (Shared IP, shared bandwidth or high bandwidth), its location, or both, on its Settings tab under Gateway or with ghost instance gateway. A change costs the instance creation charge, gives the instance a new public address, and leaves it unreachable for a few seconds; the new gateway’s prices apply from then on. A change to high bandwidth takes a few minutes, while Gigahost sets up the instance’s own gateway. A failed change leaves the instance on its old gateway and refunds the charge. See Changing the gateway of a home instance for the choices, the ports and the charge.

Deleting

Section titled “Deleting”

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.

Usage history

Section titled “Usage history”

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). Above it, the instance’s monthly spending say what the coming 30 days will cost at its current use.

A home instance’s tab has three paths: Gateway, its usage, and WAN mesh and LAN mesh (?path=wan-mesh, ?path=lan-mesh), what it sent and received over the host mesh’s internet and local-network links each period. Sent bytes are billed at the path’s price, which the tab names; received bytes are free.
  • 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 Mesh tab

Section titled “The Mesh tab”

The Mesh tab (/instances/INSTANCE_ID/mesh) shows when the instance’s traffic takes the host mesh rather than its gateway, and over which links:

  • one row for each of your instances on another host it reaches over the mesh, by its name; on a local network, a separate row for each other customer’s instance that sent or received traffic, identified only by its public IP address (or an anonymous label when unavailable); its name and account remain private;
  • whether the link is local (LAN) or across the internet, whether it carries the traffic now (On the mesh) or the traffic is back on the gateways, and since when;
  • what the link carried this UTC month, today, or in the last 15 minutes (Monthly, Daily, 15 min): what the instance sent, billed at the link’s price (a cloud instance’s sending is its usual traffic), and what it received, free.

Other customers’ rows appear only when the selected period has traffic. Instances that share a public IP keep separate rows and traffic counts. The tab shows up to 1,024 active external peers and says when more are available; your own instances remain visible even when idle.

An instance without a link says why: the host mesh is off, its home host is behind a router whose NAT the mesh cannot get through to another home host, or no mesh peers with traffic are available. ghost instance mesh INSTANCE_ID prints the same.

The Billing page

Section titled “The Billing page”

The Billing page has three tabs:

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

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

Notifications

Section titled “Notifications”
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 stay available, can be listed independently of jobs, and can be marked read. A low-balance warning that ends is marked read by itself; see The warning.

When the operator needs to tell you something about your account, a host or a change of the terms, it arrives here too, marked From the operator, and stays for a year.