Home mode

Home mode suits servers that have reliable outbound Internet access but cannot route a dedicated public address directly to each guest. Gigahost provides each rented VM with managed public connectivity.

Before you start

In addition to the shared requirements, a home host should have:

• A stable wired network connection.
• Enough sustained upload bandwidth for the guests you plan to offer.
• No restrictive outbound firewall or short idle-session timeout.
• A router and ISP plan that permit the intended server workload.

A static residential IP, inbound port forwarding and a public address for every guest are all unnecessary.

Keeping the LAN uplink unchanged

The normal dependency installer is all this mode needs:

sudo gigahost-install-hypervisor-deps
sudo gigahost-install-hypervisor-deps --check

Attaching the host’s normal LAN interface to a VM bridge is not needed for Gigahost, and it is best avoided: home-mode guest networks are isolated from your household LAN.

The mode asks for no bridge name or LAN interface setup. Enrollment and tenant VMs use agent-owned isolated bridges.

A guest’s traffic never leaves through your connection. All of it goes through the guest’s hosted gateway, which gives it its public address, and your household LAN and your own address are not reachable from it. The gateway drops a guest’s outgoing mail (TCP 25 and 465) unless Gigahost lifted the block for the guest’s account. This keeps a guest from putting the platform’s addresses on blocklists.

Several home hosts on one network

Home hosts that share a local network (the same subnet behind the same router) find each other on their own, and connect through an encrypted WireGuard mesh over that network. That includes hosts of another provider on the same network, such as a housemate’s. Customers’ instances on two such hosts, with a Dedicated IP or a Shared IP, then reach each other through your network rather than through their gateways, which saves your connection’s upload for everything else. Inside the mesh each instance has an address of its own, which each host translates to and from the instance’s public address, so the instances see each other exactly as through the gateways. This traffic stays within each instance’s bandwidth limit. What an instance on your host sends over the mesh on your network is billed to its renter at the LAN mesh price, $1.00/TiB, and all of it is your earnings, with no platform fee: held like your other earnings for the instance’s SLA tier, and counted against your SLA credits as they are. The bytes billed are the lower of your host’s count and the receiving host’s, so traffic is billed once both hosts have counted it, and what the receiving host does not count is not billed. What your host’s instances receive is free, and so is what another host’s instances send them (that host’s provider earns it).

Meshing with another provider’s host carries none of that provider’s customers’ traffic through yours: each host carries only its own customers’ traffic, as through the gateways, and accepts from the other only traffic from that host’s instances. To reach the other host’s instances directly, though, each host learns more of the other than the gateways show. Your host learns the other host’s ID and LAN address, and the public addresses of its customers’ instances (with the ports of a Shared IP), and whether it is up; the other host learns the same of yours. So on a shared network each provider can tell which public addresses run on the other’s machine. If you would rather not share that, a network of your own for your hosts (another router, or a VLAN on a subnet of its own) keeps them apart.

If a link between two of the hosts drops after it carried traffic (the other host stops answering, goes offline, or leaves the network), you get a notification, “LAN mesh link lost”, at most once a day for each network: it names the first link that dropped, and any others that drop the same day send no further notification. An outage that takes all the hosts offline together for a few minutes, such as a power cut or the line going down, sends none. The instances between the two hosts use their gateways in the meantime and take the mesh again once the link is back. The notification names the other host if it is one of yours, and otherwise says it is a host of another provider and gives its LAN address.

The instances’ addresses inside the mesh come from 100.80.0.0/12. If other software on your host uses addresses there (Tailscale, for example, numbers its devices anywhere in 100.64.0.0/10), the agent reports them as it does for the tunnels, and Gigahost gives no instance on your host, or on a host it meshes with, an address among them. That covers up to 4,096 addresses of the range for each host, a large tailnet’s worth; prefixes shorter than /16 are left alone. If your host uses more of it, such as a Headscale network numbered there, the rest is left alone too: instances may get addresses there, and your host carries their traffic over the mesh as usual, ahead of that software’s own routes. Numbering such a network in 100.64.0.0/12 instead keeps the two apart. An instance that already holds an address your software starts using (a device joined your tailnet since) gets a new one, at most once a day; until then the link between your host and that instance’s host takes no new connections over the mesh. A host that does not mesh with yours never keeps addresses from your instances by what it reports, and one that does keeps at most those 4,096.

Each host uses a UDP port of its own for the mesh, one of 27500 to 28500 that no other host on its local network uses, so several hosts behind one router never compete for a port; nothing needs setting up on the router for it. If a host runs a firewall of its own (ufw, for example) that drops UDP from the local network, it helps to allow UDP 27500 to 28500 from the local network and to let that firewall pass what arrives on the ghmesh interface and is forwarded between it and the VMs’ bridges. A host keeps its port when it moves to another network or router, unless a host there already uses it. If another program on the host already uses the host’s port, the host moves to another free port of the range by itself, up to three times; after that it stays off the mesh, its instances using their gateways, until the port is free again. A firewall that passes the hosts’ pings but drops the forwarded traffic loses the traffic between the instances, because the hosts switch the connection on once the pings are answered; if the pings are dropped as well, the hosts keep using the gateways, and nothing else changes.

Hosts across the internet

Your host also meshes, across the internet, with the hosts where the same customer runs instances: another home host, yours or another provider’s, or a cloud host. The customer’s instances, with a Dedicated IP or a Shared IP, then reach each other directly rather than through the gateway, which saves your connection’s upload. Only that customer’s traffic takes the link: another customer’s instances on the same two hosts still use their gateways, and your host accepts from the other only what goes between that customer’s instances. What an instance sends over such a link is billed to its renter at the WAN mesh price, which is Gigahost’s, as the gateways’ traffic is: a home host earns nothing for traffic across the internet.

The hosts reach each other at the address and port your router gives the host’s mesh port on the internet (a cloud host at its address and UDP port 902), so the hosts your host meshes with learn your home’s public address, as any address on the internet can be seen. A host behind a router that changes a connection’s port for every address it sends to meshes over IPv4 only with cloud hosts, and with other home hosts over IPv6 where both have it (below); nothing else changes for it. After a new router, the hosts find out again what it does within a few minutes, and keep the links they have meanwhile. A firewall of your own on the host does best to let UDP 27500 to 28500 in from the internet, over IPv4 and IPv6, as your router already does for what the host sent first.

Where your connection has IPv6, your host meshes over it with the other home hosts that have it too. IPv6 needs no address translation, so the other host reaches yours at its own IPv6 address and mesh port, also behind a carrier-grade NAT, where many homes share one IPv4 address and the port changes for every destination, which keeps such a home off the mesh over IPv4. Both hosts send to each other at once, so your router’s IPv6 firewall lets the other’s packets in as replies, as for any connection your host starts: nothing needs opening on the router. The hosts yours meshes with then learn its IPv6 address. A link over IPv6 that does not come up within a few minutes uses IPv4 or the gateways as before, and IPv6 is tried again within the hour, or as soon as an address changes. Your host uses a stable global IPv6 address of the interface its IPv6 default route uses, never a temporary one; a host that has none, for instance one that does not accept router advertisements, meshes over IPv4 alone. It also sends from that address: the agent adds a route of protocol 157 for each other host’s IPv6 address, and removes it with the link.

Configuring home mode

1. To find the closest allowed location slug, run ghost catalog locations.

2. In /etc/gigahost/hypervisor.toml, add the mode and set the location that the shared settings already hold to that slug, so that each key appears once:

   mode = "home_gateway"
   location = "<NEAREST_LOCATION>"

   The beginning of the configuration then looks like this:

   backend_url = "https://api.gigahost.cloud"
   host_label = "home-bkk-1"
   location = "th-bangkok"
   mode = "home_gateway"

3. Enrollment and service setup come next; they are described in Setting up a host.

Gigahost runs your instances’ gateways in the hosted region nearest to the location, and tries the next nearest regions when that one has no room for a new gateway.

The VM’s network on your host

Each VM gets a private bridge and WireGuard interface. The agent disables IPv6 on both and installs a per-VM firewall before either interface is brought up.

• Only the VM’s assigned IPv4 address can pass between that bridge and its gateway tunnel. Attempts to reach the hypervisor, management LAN or another VM, or to forward a spoofed source address, are dropped.
• The guest’s interface has an MTU of 1420, the tunnel’s. Both your host and the gateway clamp the MSS of TCP connections through the tunnel to 1380 in each direction, so full-size packets are not lost on the way.

Offering capacity

When you publish capacity, it helps to leave room for the resources the host operating system needs. It is also best to advertise only the performance and availability that the machine and its Internet connection can sustain.

A home host keeps the catalog’s operating-system images downloaded ahead of demand, so that a customer’s new or reinstalled VM does not wait minutes for its image over your connection. How it works, and its settings, are under The image cache.

Gateway tiers

Every VM gets a Dedicated IP on a hosted gateway. Customers choose a public-connectivity tier when they create a VM:

Tier	Gateway	The VM’s address
shared_bandwidth	Shared with other home VMs, in one of a few central regions, the one nearest to your server	The gateway forwards every protocol and port of the VM’s address to the VM
high_bandwidth	The VM’s own, in the region nearest to your server, which exists as long as the VM does; its traffic rate is lower	The gateway’s: every protocol and port of it reaches the VM but port 27492, which the gateway keeps

A shared_bandwidth VM’s address stays the VM’s for as long as the VM exists, also when Gigahost moves the VM to another gateway. After the VM is deleted, the address rests for an hour and is then given to a later VM, so a VM’s address may have been another customer’s before.

Gateway charges

Gigahost publishes each tier’s gateway base charge per 30-day month and gateway traffic rate per TiB.

• The customer pays both to the platform, on top of your prices, and sees them before creation; the catalog shows the gateway traffic rate and yours as one combined rate.
• The gateway base charge starts when the VM’s address or its own gateway exists and is billed in 15-minute intervals, prorated over the 30-day month, until the VM is deleted.
• When Gigahost changes a tier’s prices, existing VMs get the same 90-day notice and increase limit as for a change of your own prices.

When there is no room

The number of gateways and addresses Gigahost can run is limited. While there is no room for another home VM, or for one of a tier, the catalog leaves your offerings or that tier out. Gigahost does not accept a creation and answers it with capacity_unavailable; nothing is charged for it.

Traffic metering

The hosted gateway meters the VM’s traffic, and the counters of your hypervisor are never billed. Billing uses the gateway’s WireGuard counters for the tunnel to your host:

• traffic toward the guest counts as the gateway sends it into the tunnel;
• traffic from the guest counts as it arrives from your host;
• inbound traffic that the gateway’s firewall drops, such as a flood, never enters the tunnel and is not billed.

The gateway also counts what arrives, what it passes on (outbound, only the VM’s own packets), and what it drops in each direction; the customer sees these figures on the instance’s Overview for information only.

When a new VM becomes active

A new VM becomes active, and its own billing starts, once it runs and its gateway reports a fresh WireGuard handshake with your host.

• Neither the VM nor your host gets a separate reachability check. Gigahost runs the gateway and its public address, and your host’s connection is covered by the network tests it runs after enrollment and by each VM’s handshake.
• The gateway has up to 15 minutes to be created, up to 15 more to become ready, and a limited time to report the handshake.

When the handshake does not arrive in time, the creation fails:

• Gigahost gives up the VM’s place on the gateway, and your host removes the guest VM and what its creation left there, its WireGuard key included.
• If Gigahost or your host reboots meanwhile, the same cleanup resumes, and the VM holds its capacity on your host until it is done.
• Unless the customer caused the failure, their creation charge and every gateway base charge are refunded.

Tunnel addresses

Each VM’s tunnel uses a /30 from 100.64.0.0/10, chosen per home host. Other software on the host may use the same range, such as Tailscale, Headscale, or another WireGuard or carrier-grade NAT setup.

• The agent reports the prefixes of that range that other interfaces and routes on the host use.
• New tunnels avoid those of /16 or narrower as well as 100.100.100.0/24 and 100.115.92.0/23, which Tailscale keeps for its own use.
• A tunnel whose /30 would still overlap another interface’s address, or a network of /16 or narrower, fails instead of being set up.
• The agent also gives each tunnel interface a link-local /32 address, since some kernels forward nothing that arrives on an interface without an IPv4 address; no traffic uses that address as its source.

How a change of those prefixes reaches Gigahost is under Inventory.

Operational checks

Once the host is online and taking rentals, you can run the checks described in Checking a new host.