Skip to content
Gigahost Docs

Connecting and networking

Connecting with SSH

Section titled “Connecting with SSH”
ssh root@ADDRESS
ssh -p 1020 root@203.0.113.7   # an instance with a Shared IP

ghost instance create --wait ends with a line on stderr that says where the new instance is: instance ID (HOSTNAME) is running at ADDRESS. For an instance with a Shared IP it ends with the SSH command, such as ssh -p 1020 root@203.0.113.7. The instance’s Overview shows the address, and for a Shared IP the SSH command for the port that goes to the instance’s port 22.

  • The keys are installed for root, so root is the user to log in as. The image’s usual default user, such as ubuntu or debian, gets no keys and is not set up.
  • SSH password login is off.
  • Other users can be added with a --cloud-init-file.

App domains and CDN origins

Section titled “App domains and CDN origins”

In Settings, the HTTP proxy publishes an app on its managed hostname, for example app.node.example.test. With a Shared IP, select an existing incoming TCP forward; with a Dedicated IP, select the guest service port.

Each instance allows 10 active proxies by default. Creations and edits share a limit of 100 changed entries per account in a rolling 24 hours, across all your instances and ingresses. An operator can configure that limit. Each changed entry counts separately; deletes, unchanged saves and failed requests are free. Automatic gateway moves do not use your allowance.

Deleted names and proxy configuration history are kept for at least 90 days. Longer retention or a legal hold can postpone expiry. There is no numeric limit on deleted history. Saved entries keep their URLs when limits change. After history expires and operational routes drain, old names are freed for reuse by another account. Existing settings are captured when history starts; previously overwritten settings cannot be recovered.

HTTP mode provides managed HTTPS and connects to the guest over HTTP. Redirect HTTP to HTTPS starts enabled. Clear it to allow both public HTTP and managed HTTPS on that app. This is useful when a CDN needs an HTTP origin: configure the CDN to send the app’s managed hostname in its origin Host header. The HTTP Origin Host (optional override) changes the Host header sent to the guest. Public hostname (optional) adds an incoming plain-HTTP hostname; turn off Redirect HTTP to HTTPS to use it. Set a DNS-only direct CNAME from that routing hostname to the displayed managed target. Managed HTTPS remains available at the managed hostname; the routing hostname has no platform TLS certificate.

For example, set the routing hostname to origin.example.com and its CNAME to app.node.example.test. Configure the CDN origin request with Host: origin.example.com. Set the independent Host override to www.example.com when the guest expects that name. A CNAME does not select a route for a different incoming Host.

Redundant entries on different ingresses may use the same public hostname with several managed CNAME targets. Either a matching direct answer or a target for another current entry owned by your account for that same public hostname can prove DNS control, including when latency DNS returns only one region. A target for another account or a different public hostname cannot prove it. Flattened A/AAAA answers and proxied records do not prove ownership. Each ingress permits 1024 HTTP routing names, including pending and draining names. Deleted-name retention does not limit active HTTP routing names.

HTTPS provides a certificate for your custom public hostname and terminates TLS on the proxy. Set Public hostname and the displayed DNS-only CNAME; no additional DNS record is needed. The proxy connects to the guest over HTTP, with an independent Origin Host (optional override) when your app needs it. The proxy obtains and renews its certificate automatically, using HTTP validation on port 80. Its certificates, private keys and ACME account stay on that proxy and survive restarts. A failed renewal keeps the current valid certificate while the proxy retries. Renewal failure or an approaching expiry raises a platform incident for the operators. Initial and replacement certificate orders have a separate configurable account limit, defaulting to 100 per rolling 24 hours. Initial and replacement orders are spaced by at least an hour, with at most five per ingress and hostname per rolling 24 hours. Automatic renewals have no platform issuance quota. Each ingress permits 64 managed custom HTTPS names, including pending and draining names, within its shared 1,024 HTTP hostname slots.

The same public hostname can use several managed CNAME targets for redundancy. Each proxy manages its own certificate. Any matching proxy can answer HTTP validation using the short-lived public challenge held by the backend. Private certificate and ACME account keys stay on the issuing proxy. Keep public port 80 reachable for both initial issuance and automatic renewal.

HTTPS (passthrough) sends encrypted TLS directly to the guest, which serves and renews its own certificate. Plain HTTP always redirects in this mode, because the guest port expects TLS. The saved redirect preference is retained if you switch back to HTTP mode. For a custom TLS hostname, use a direct DNS-only CNAME to the managed target: CDN-proxied or flattened DNS answers are unsupported for ownership checks. A CDN can still use an HTTP origin when its DNS-only routing hostname points directly to the managed target and its origin request sends that hostname.

A changed app stays pending until the ingress supports and applies its configuration. Older ingress software can keep serving other apps while an app that allows plain HTTP or uses a routing hostname waits for an update. Routing hostnames require a current ingress worker. Managed custom HTTPS also requires support for local certificate automation and shared challenge lookup. Operators must retain V4-capable binaries once an ingress receives the new certificate-automation authority, even when it contains no custom names or the names are later removed; older binaries refuse its saved authority. Ingresses whose saved authority remains V3 retain their existing V3 rollback requirement.

Kinds of public address

Section titled “Kinds of public address”

Every instance reaches the internet one of these ways. The offering lists which it has, with their prices; the IP filter on Capacity and --ip dedicated|shared on ghost catalog offerings choose between the two kinds of address.

Host Address What the instance gets Choose it with
Cloud host Dedicated IP A public IPv4 address of its own from the host’s provider No --gateway-tier (the default)
Cloud host Shared IP A range of the host’s address’s ports --gateway-tier shared_ip
Home host Dedicated IP on a shared gateway Shared bandwidth: its own address on a shared gateway --gateway-tier shared_bandwidth
Home host Dedicated IP on a gateway of its own High bandwidth: the address of its own gateway --gateway-tier high_bandwidth
Home host Shared IP A range of a shared gateway’s address’s ports --gateway-tier shared_ip

What each costs is on Pricing and billing.

Home instances: gateway tiers

Section titled “Home instances: gateway tiers”

A home instance has a public IPv4 address on a hosted gateway, and home-mode offerings need a tier: shared_bandwidth, high_bandwidth or shared_ip. The spellings with a hyphen work too. On the website, a home instance starts with the shared bandwidth tier, at its default gateway location where it has one.

Tier Gateway What reaches the instance
shared_bandwidth Shares a gateway in one of a few central regions with other home instances Every protocol and port of its address
high_bandwidth A gateway of its own in the region nearest to the provider’s server, with a lower traffic rate; its address is the gateway’s Every protocol and port of the address but port 27492, which the gateway keeps
shared_ip Shares a shared gateway’s address with other instances A range of the address’s ports; see Shared IP and ports

Either way the instance’s traffic crosses the provider’s home connection, so it is not faster than that. The offering’s network readings show what that connection delivers, which is worth a look before paying for high_bandwidth.

When there is no room

Section titled “When there is no room”
  • An offering lists only the tiers there is room for now.
  • It names high_bandwidth in full_gateway_tiers while the platform can set up no gateway of its own for another instance; the website shows high bandwidth as At capacity then.
  • When the gateways have no room for the instance, Gigahost does not accept the creation, answers capacity_unavailable, and charges nothing. The message says what is short: no public address free at the location, with when one is free again and whether high_bandwidth could be placed, or no gateway that can be set up for high_bandwidth or has room for another shared_bandwidth instance.

Gateway location

Section titled “Gateway location”

The offering lists the locations with their distance, their gateway prices and a warning where traffic crosses a congested or long-haul path; the rent form shows each location’s distance and gateway prices, for a Shared IP as well as for shared bandwidth. With the Shared IP chosen, the form shows that tier’s prices at each location, and a location whose gateways have no free slice of an address is marked Full and cannot be chosen. Where none of the listed locations has a free slice on a path without a bottleneck, the form offers no choice for the Shared IP, and Gigahost places it at the closest location that has one, at the Shared IP’s price. The instance shows its gateway’s location. On its Settings tab, under Gateway, you can change the gateway: its tier, its location, or both.

A shared bandwidth or Shared IP home instance is reached through a shared gateway at one of a few locations.

  • The default is the closest to its host with room that crosses no bottleneck (a congested or long-haul path), unless you chose another when you created it.
  • You can choose a location across a bottleneck if you accept the bottleneck.
  • When no listed location without a bottleneck has room, Gigahost does not accept the creation and names the closest location with room, which you can choose.
  • When you change its gateway later, it gets a new public address, is unreachable for the seconds the change takes, and pays the new gateway’s prices from the change on, as the offering lists them.

Changing the gateway of a home instance

Section titled “Changing the gateway of a home instance”

A home instance can change its gateway’s tier between the Shared IP, shared bandwidth and high bandwidth, its location, or both. The Shared IP shares a gateway’s address, shared bandwidth gives the instance an address of its own on a shared gateway, and high bandwidth gives it a gateway of its own, whose address is the instance’s. The offering lists each tier’s prices, the shared tiers’ at each location, so you can compare before you choose.

On the instance’s Settings tab, Gateway shows its tier, location and price now. Below that it lists every other choice, a tier at a location, with its distance and the prices the tier takes there, a Shared IP at a location with no free slice marked Full. The charge of the change stands beside the choices and in the dialog that asks you to confirm. High bandwidth is one choice, a gateway of the instance’s own nearest to its host, with the tier’s prices and the minutes it takes; it is marked Full while no gateway of its own can be set up. A high bandwidth instance is offered the shared tiers at their locations. An account on a trial whose limits hold keeps a Shared IP, so it is offered locations for the Shared IP only.
  • A change costs the platform’s instance creation charge, the same as creating an instance, whichever tier and location you change to. That keeps a change from being cheaper than renting anew. The offering lists it as instance_creation_charge_microusd, and the website and ghost show it before anything is charged. A live trial credit pays it first, where the instance is on a trial host. A change of an instance whose gateway is being taken out of service costs nothing; see When a gateway is taken out of service.
  • The instance gets a new public address and is unreachable for the seconds the change takes. Your DNS records and the address you connect to need updating; a notice tells you the new address when the change is done.
  • The new gateway’s prices apply from the change on.
  • To high bandwidth, Gigahost first sets up the instance’s own gateway, which takes a few minutes. The instance stays on its gateway, reachable at its address, until the new one runs; only then does it move, at the new gateway’s address. When no gateway of its own can be set up now, the change is refused before anything is charged.
  • From high bandwidth, the instance’s own gateway is retired after the change, and its address goes with it: a gateway’s address cannot be kept for another gateway.
  • From shared bandwidth or high bandwidth to a Shared IP, the instance gets the new slice’s default ports forwarded: the first to port 22 and every other to the same number. Between two Shared IP locations the forwards stay as they are. From a Shared IP to shared bandwidth or high bandwidth, every port of the new address is the instance’s. A change of the ports within a slice is a different action; see Shared IP and ports.
  • A change needs the instance running or stopped, and no other job active on it. Your available balance must cover the charge, and a month of the new gateway’s higher base charge where it is higher, with the protected balance kept.
  • If the change fails for a reason other than yours, for instance when the new gateway cannot be set up, the instance stays on its old gateway with its address, and the charge is refunded.
  • A location with no gateway room for the tier, or a Shared IP at a location with no free slice, is refused with the closest location that has room, which you can choose.

When a gateway is taken out of service

Section titled “When a gateway is taken out of service”

Gigahost never moves an instance with a Dedicated IP to another address. When its gateway is taken out of service, a notice invites you to move the instance to another location at a time of your choosing and links to its Settings tab. The instance keeps running where it is until you do.

That move is Gigahost’s decision and not yours, so it costs nothing: the instance creation charge is waived, and your balance does not need to cover it. The Settings tab and ghost instance gateway show the change as free while the instance is on the retiring gateway, in the dialog and in the quote before --yes, and the same holds for ghost instance gateway-location, which the notice names. The waiver ends with the move: once the instance is on another gateway, a change of it costs the charge again.

Shared IP and ports

Section titled “Shared IP and ports”

The instance’s Overview shows the address with the SSH command for the port that goes to the instance’s port 22, every public port with the instance’s port it goes to, and the ports its outgoing connections leave from. You can change where a port goes on its Settings tab, under Ports.

An instance with a Shared IP has no address of its own. It shares a public address with other instances and gets a range of its ports, TCP and UDP.

  • It gets as many ports as the offering’s shared_ip_ports (20).
  • Each forwards to a port of the instance: by default the first to port 22, for SSH, and every other to the same number on the instance.
  • The instance’s outgoing connections leave from a range of source ports of its own, so other instances on the address cannot use them up. A packet the instance sends from the port a forward goes to leaves from that forward’s public port instead, so a peer that learns the address from it, as with a BitTorrent or WebRTC node, reaches the instance on the port it saw.
  • The gateway, or a cloud host’s router, follows a change within a minute and drops the connections of a port whose target changed.

Home instances with a Shared IP

Section titled “Home instances with a Shared IP”
  • A shared_ip home instance shares its gateway’s public address and is placed at a gateway location as a shared bandwidth instance is, --gateway-location included. The offering lists the Shared IP’s monthly base charge and traffic price at each location beside the shared bandwidth ones, and whether the location is full for it, that is, none of its gateways has a free slice of an address.
  • The price the offering lists at a location is the lowest of its gateways with a free slice, whoever runs them. Of the gateways at that price, a new instance gets a slice of the one with the largest share of its slices still free, so the location’s instances, their traffic and the effect of one gateway’s failure spread over those gateways. An instance stays on its gateway: none is moved to even them out.
  • Once the gateways at the lowest price are full, the offering lists the next price at the location, and an instance created then pays that one, also one created just as the last cheaper slice was taken.
  • When it moves to another gateway, by your choice or because its gateway is taken out of service, it gets that gateway’s address and other ports, each going where the one in its place went. A notice tells you the new address and ports when it moves, and your DNS records and the ports you connect to need updating.

Cloud instances with a Shared IP

Section titled “Cloud instances with a Shared IP”
  • A cloud offering whose hosts share their own address lists Shared IP beside Dedicated IP when you rent it (in the API, a shared_ip price among its network_prices beside the price without a tier).
  • An offering whose hosts have no address left may list only the Shared IP.
  • --gateway-tier shared_ip on such an offering gives the instance a slice of its host’s address instead of a Dedicated IP. There is no --gateway-location, since its address is its host’s.
  • It keeps its address and ports for as long as it exists.

Idle connections

Section titled “Idle connections”

On an instance with a Shared IP, home or cloud, the gateway forgets an outgoing TCP connection that has been idle for about 2 hours, and gives its source port back: the connection’s next packet then fails. TCP keepalive, or anything else the connection sends within the 2 hours, keeps it open.

Instances on the same host

Section titled “Instances on the same host”

Instances on the same host, cloud or home, reach each other at their public addresses and ports, as they would from the internet. An instance with a Shared IP is reached at its address’s forwarded ports. The instance that receives sees the sender’s public address, and for a Shared IP one of the sender’s outgoing ports. On any host, a packet the sender sends from the port a forward goes to arrives from that forward’s public port instead, as it does from the internet. This traffic stays on the host, so it is not billed, and mail between such instances is not blocked, since it never leaves the host. It keeps to each instance’s bandwidth limit, as its other traffic does.

Instances on one local network

Section titled “Instances on one local network”

Two home instances on two hosts of the same provider that share one local network, each with a Dedicated IP or a Shared IP, reach each other straight over that network rather than through their gateways, once the hosts have found each other there. They still reach each other at their public addresses and ports (a Shared IP at its forwarded ports), and the instance that receives sees what it would see through the gateways: the sender’s public address, and for a Shared IP one of the sender’s outgoing ports, or its forward’s public port when it sends from the port the forward goes to. Nothing changes for them but the speed and the latency. The traffic between the two hosts is encrypted, it is not billed, and mail between the two is not blocked, since it never leaves the provider’s network. It keeps to each instance’s bandwidth limit.

The ports a gateway keeps of its own address, and a Shared IP’s ports without a forward, keep going through the gateways. When the two hosts lose sight of each other on their network, new connections go through the gateways again within about 15 seconds. Open connections carry on there when their addresses and ports stay the same: those of a Dedicated IP, and those of a Shared IP to or from one of its forwarded ports; they may pause for a few seconds while both hosts switch. A Shared IP’s other open connections, from its outgoing ports, leave its gateway from another port, so they end and the application reconnects. While an instance on either host is created, deleted or given another address or forward, new connections between the two hosts’ instances go through their gateways for up to about a minute, until both hosts know the change.

Your instances on different hosts

Section titled “Your instances on different hosts”

Your own instances on two different hosts, two home hosts in different places or a home host and a cloud host, each with a Dedicated IP or a Shared IP, reach each other directly across the internet rather than through the home side’s gateway, where the hosts’ internet connections allow it. A cloud host reaches any home host this way; two home hosts reach each other where both their routers keep a connection’s port the same toward every address (most home routers do), and otherwise keep using their gateways. Nothing changes for your instances: they reach each other at their public addresses and ports (a Shared IP at its forwarded ports), and the instance that receives sees what it would see through the gateways: the sender’s public address, and for a Shared IP one of the sender’s outgoing ports, or its forward’s public port when it sends from the port the forward goes to. The traffic between the hosts is encrypted.

Only your own instances reach each other this way. Another customer’s instance on one of the same hosts still reaches yours through the gateways, as before. A path that cannot carry full-size packets (some PPPoE or DS-Lite lines) is not used, so no connection stalls on it. A Shared IP’s ports without a forward keep going through the gateways, as on one local network.

When a home line changes its address, as many do every day, the hosts find each other again within a minute or so; in the meantime your instances use their gateways. Open connections carry on there when their addresses and ports stay the same: those of a Dedicated IP, and those of a Shared IP to or from one of its forwarded ports. A Shared IP’s other open connections, from its outgoing ports, end, and the application reconnects.

Bandwidth limits

Section titled “Bandwidth limits”

Every instance’s bandwidth is limited, each direction alike, by how it reaches the internet and its size:

How it reaches the internet Limit
A Shared IP, home or cloud 20 Mbit/s
Home, Dedicated IP on a shared gateway (shared bandwidth) 100 Mbit/s
Home, a gateway of its own (high bandwidth) No limit
Cloud, Dedicated IP, up to 15 vCPUs 50 Mbit/s per vCPU: 200 Mbit/s with 4 vCPUs, 750 Mbit/s with 15
Cloud, Dedicated IP, 16 vCPUs or more No limit
  • A home instance’s limit is applied on its gateway and on its host, at the same rate, so it is no lower than the table says: its host holds back its uploads before they leave the home connection, where a burst would slow its neighbours, and its traffic with other instances on the host, which never reaches the gateway, keeps to the limit too. A cloud instance’s limit is applied on its host.
  • Capacity, the offering page and the rent form show each choice’s limit beside its traffic price, and the instance’s Overview shows its own as Bandwidth. The quote ghost instance create prints names the limit of the chosen network, and ghost instance get shows an instance’s as bandwidth.
  • An upgrade gives the instance its new size’s limit, and a change of these limits by Gigahost reaches a running instance without a restart.

Mail

Section titled “Mail”

An instance cannot send mail straight to other mail servers: its outgoing TCP connections to port 25 and to port 465 (SMTPS) are dropped, on every host. That way an instance that sends spam cannot put the addresses of its host or of Gigahost’s gateways on blocklists.

  • Mail can be sent through a mail service instead, with a login on port 587 (submission) or through its HTTPS API, which every instance may use.
  • Receiving mail works on every port.
  • The API and ghost instance get show outgoing_mail_allowed on each instance, false unless support lifted the block for your account.
  • To have it lifted, open a support ticket in the networking category saying what the mail is for. Once lifted, every instance of the account sends freely within a minute, running ones too.
  • The block is lifted for legitimate mail on the condition that the account sends no spam, as the Acceptable Use Policy says, and it can be put back if it does.

MTU of a home instance

Section titled “MTU of a home instance”

A home instance’s network interface has an MTU of 1420, that of the WireGuard tunnel to its gateway, and the MSS of TCP connections through the tunnel is clamped to 1380, so ordinary traffic needs no setting from you.

A tunnel of your own inside the instance, such as a WireGuard or other VPN server, carries its packets inside that one and needs a smaller MTU. 1340, the tunnel’s 1420 less WireGuard’s 80 bytes, works for WireGuard. With the default of 1420, its connections stall.

Gateway traffic of a home instance

Section titled “Gateway traffic of a home instance”

The instance’s Overview shows under Gateway traffic what its gateway counted over the last hour and the last day in each direction, incoming and outgoing apart.

A home instance’s gateway counts for the instance, in each direction:

  • what reached the gateway for the instance’s address;
  • what it passed on; outbound, this counts only the instance’s own packets, not the tunnel’s;
  • what its firewall dropped;
  • while the gateway carries no other instance, also the packets its tunnel toward the instance discarded while the tunnel was down.

These figures are for information only, and billing does not use them. What the gateway bills is under Traffic.

Rotating a home instance’s gateway keys

Section titled “Rotating a home instance’s gateway keys”
ghost instance rotate-gateway-keys <INSTANCE_UUID> --wait

This replaces a home instance’s WireGuard key on its host, which is the remedy when the key may be lost or compromised.

  • On a running instance, the tunnel to the gateway is down from the moment the host installs the new key until the gateway applies it, a few seconds, so connections through it may stall or drop. The job finishes once the gateway reports a handshake with the new key.
  • On a stopped instance, the host keeps the new key for the instance’s next start, and the job finishes without waiting for a handshake.

An address after deletion

Section titled “An address after deletion”

A cloud instance’s public IPv4 address rests for an hour after the instance is deleted, so that what is still meant for the instance, such as the traffic your DNS records send there, reaches no other customer meanwhile; after that another instance may get it.

  • The address rests only from other accounts. An instance you create within the hour on a host that can use the address gets it back at once, before any other free one, even where the catalog shows no address free for its size.
  • DNS records are best updated within the hour.
  • If you used an address before, plain ssh warns about a changed key when you reach a new instance there. ssh-keygen -R "[address]:port" removes the old line (ssh-keygen -R address for port 22). ghost keeps host keys per instance and does not warn.
  • The address of an instance whose creation failed was never the instance’s and is free at once, unless it was your own resting address, which keeps its rest from other accounts.
  • A shared_bandwidth home instance’s address rests for an hour too, from other accounts only, and your next instance at the same gateway location may take it back; a high_bandwidth home instance’s address goes with its gateway.
  • A Shared IP’s ports rest for an hour from every account, yours included, so an instance you create again gets other ports. A new instance takes ports that no instance had before, and when there are none, the ports that have been free the longest.