Home mode

Home mode is intended for 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 hypervisor 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.

You do not need a static residential IP, inbound port forwarding, or a public address for every guest.

Keep the LAN uplink unchanged

Run the normal dependency installer:

sudo ./install-hypervisor-deps.sh
sudo ./install-hypervisor-deps.sh --check

Do not attach the host’s normal LAN interface to a VM bridge merely for Gigahost. Home-mode guest networks are isolated from your household LAN.

No bridge name or LAN interface setup is required. 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, so that a guest cannot put the platform’s addresses on blocklists.

Configure home mode

Add these values to /etc/gigahost/hypervisor.toml:

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

Use ghost catalog locations to find the closest allowed location slug. The backend maps it to the nearest Vultr region, where the hosted gateways of your VMs run, and tries the next nearest regions when that one has no room for a new gateway.

The complete beginning of the configuration should now resemble:

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

Continue with enrollment and service setup.

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 may pass between that bridge and its gateway tunnel; attempts to reach the hypervisor, management LAN, another VM, or to forward a spoofed source address are dropped. The guest’s interface has an MTU of 1420, the tunnel’s, and 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 publishing capacity, allow for resources needed by the host operating system. Advertise only 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. The downloads take at most half the download bandwidth your host’s network tests measured, pause while a VM’s own download, a restore or a network test runs, and leave the larger of 5 GiB and a fifth of the cache’s filesystem free; the whole catalog takes about 10.4 GB. See image downloads ahead of demand for the settings.

Every VM gets a public IPv4 address of its own on a hosted gateway. Customers choose a public-connectivity tier, shared_bandwidth or high_bandwidth, when creating a VM:

• A shared_bandwidth VM shares a gateway 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. The 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.
• A high_bandwidth VM has a gateway of its own, in the region nearest to your server, which exists as long as the VM does. The VM’s address is the gateway’s: every protocol and port of it reaches the VM but port 27492, which the gateway keeps. Its traffic rate is lower.

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.

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, and a creation is refused with capacity_unavailable; nothing is charged for it.

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, and traffic from the guest 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.

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: the gateway and its public address are run by Gigahost, and your host’s connection is covered by the network tests it runs after enrollment and by each VM’s handshake. The gateway gets up to 15 minutes to be created and up to 15 more to become ready, and a bounded time to report the handshake. When it does not, 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. The durable job resumes the same cleanup after a backend or provider reboot, 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.

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, and 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.

Operational checks

After the host is online:

1. Create a small test VM through Gigahost.
2. Confirm that it obtains public connectivity without any router changes.
3. Test inbound SSH and outbound Internet access from the guest.
4. Reboot the host and verify that the hypervisor service and test VM recover.

If the home connection changes address, the agent reconnects automatically. Do not delete the hypervisor state file or re-enroll the same machine as a new host to solve a temporary connectivity problem.