Installing Homestead - homestead-lab/homestead GitHub Wiki
For a new home self-hosting setup, choose k3s: it is Homestead's preferred and most widely tested platform.
The cluster guides - k3s, RKE2, Harvester, an existing cluster - each end with Homestead running. This page is what they share: what got installed, the first sign-in, and looking after Homestead afterwards.
| Object | What it is |
|---|---|
Deployment homestead
|
Homestead itself: one small container, no database, running as a non-root user on a read-only filesystem |
Service homestead, port 8088 |
its address on your LAN |
Claim homestead-data, 2 GiB |
settings, job history, long-term stats, the audit log |
Secret homestead-auth
|
user accounts (salted PBKDF2 password hashes), kept apart from the data volume |
ServiceAccount, ClusterRole homestead
|
what Homestead may do in the cluster |
DaemonSet homestead-nodeprobe
|
installed automatically, one per host: temperatures, host devices, every disk, drive health |
Everything Homestead creates is named homestead-* or carries homestead.io/*
labels and annotations, so it is easy to find with kubectl. There is one
Homestead per cluster. The plain manifest installs it into lab; the Helm
chart into its own namespace, with your apps in lab.
Both install the same objects - the chart is generated from the manifest.
-
Helm (
oci://ghcr.io/homestead-lab/charts/homestead) takes values instead of edits, andhelm uninstallremoves it (your apps, their namespace and Homestead's data volume are kept). -
The manifest (
deploy/deploy.yaml) needs only kubectl, and is what the k3s script uses.
Updates are the same either way: Homestead updates itself, below.
The interactive installer enables a Host Console by default on k3s and RKE2 servers and workers. It replaces the first local console's login screen with live CPU, RAM, uptime, IP addresses and local disk usage. Server nodes also show cluster members, readiness, Kubernetes versions and Homestead's service address.

The dashboard uses green for healthy nodes, amber for warnings or cordoned nodes, and red for unavailable APIs, failed nodes or high resource usage. CPU, per-core load, memory and disk usage have coloured bars, with a rolling CPU history graph. Usage turns amber at 75% and red at 90%. Narrow terminals stack the panels and keep the full view available by scrolling.

The logo, history graph and usage bars use Unicode Braille dots, like btop.
The house outline and two white infrastructure layers are rasterised from
Homestead's logo, sized for tall terminal cells. Press A to switch between
dots and plain characters if the console font lacks Braille glyphs. Non-Unicode
locales use plain characters automatically; host-console.py --ascii also
forces that view.
Workers show local health; cluster details require a server's local kubeconfig.
Harvester keeps its native console.
Press Enter, Q or Escape for the normal authenticated login prompt. Use the arrow keys or Page Up/Down to scroll. The screen returns after logout. SSH and other consoles work as usual. Host metrics refresh every two seconds; cluster status refreshes every fifteen seconds and shows API failures.

Choose No at the Host Console question, or set HS_CONSOLE=no for unattended
installation. To enable or disable it later, use Configure host status console
in the installer menu, or run the downloaded installer:
sudo sh install.sh --console
sudo sh install.sh --no-consoleIn Homestead, the host console is an add-on for the whole cluster: Settings → Cluster → Add-ons → Host console, with one On/Off switch. While it's on, Homestead keeps every Ready host on the console bundled with the running Homestead:
- it installs the console on hosts that don't have it, including hosts that join later
- it updates hosts when Homestead carries a newer console, so updating Homestead rolls the console out across the cluster
Turned off, it's removed from every host. Homestead works through a couple of hosts every ten minutes, and the row lists each host's state. A host that fails is tried again an hour later. On a cluster set up before this setting existed, the console counts as on where the installer turned it on. Harvester hosts keep their native console.
Changes take effect on the next boot or logout, so installation does not interrupt a logged-in administrator. The console needs systemd, agetty and Python 3 with curses; the installer installs Python if needed. It reads local metrics and Kubernetes status without displaying credentials or providing an unauthenticated shell. The screen is visible to anyone with physical or remote console access.
For manual removal, delete only
/etc/systemd/system/[email protected]/50-homestead-console.conf, then run
sudo systemctl daemon-reload. Normal login returns on the next boot or logout.
Open http://<address>:8088. The first visit asks for an administrator's name
and password, and that account can then add others under Settings → Users and access → Add user:
| Role | Can |
|---|---|
| viewer | see everything, change nothing |
| operator | deploy, edit, move, start and stop containers and VMs, open consoles |
| admin | everything, including users, hosts, hardware, imports and cluster settings |
Sessions last 12 hours of inactivity, or 30 days with Keep me signed in, and never more than 90 days. Changing a password signs that account out everywhere.

The first time an administrator signs in, Homestead opens its setup guide
(/setup): six chapters - Is it healthy?, Reach it, Keep data safe,
Make it yours, Connect and First apps - each step a sentence on why it
matters, the cluster as it is now (a diagram where it helps: quorum, the VIP,
copies across nodes, the HTTPS path from a phone), and one thing to do.
- Homestead checks each step itself, every time: a VIP set, backups configured, disks in use, the default storage class matching the nodes, notifications on. A step done and since undone shows again. Skip puts one aside; Bring it back returns it.
- Admins see every chapter. Everyone else sees the steps that are theirs: appearance, installing it on their phone, and notifications.
- It covers what new clusters most often miss: two servers (no node can fail until there is a third), getting HTTPS - needed to install Homestead on a phone and get notifications - with a Cloudflare Tunnel or Tailscale set up from the step, disks Longhorn is not using yet, a default class with too many or too few copies, an encrypted export of Homestead's own settings, and a second administrator.
- Until it is done, the Dashboard says Setup: 9 of 21; Hide from the Dashboard removes that, and Settings → Homestead → Setup guide always opens it.
The setup guide walks through all of these; in short:
- Settings → Homestead - check Homestead's own health: every background task, the node probe, Samba, backup storage. See Settings.
- Check node telemetry. Homestead installs the node probe automatically, unless explicitly declined in the installer. It adds temperatures, host devices, disks and SMART drive health. Review its status in Settings → Homestead.
- Networking → Workload VIPs - keep a few addresses for apps (Harvester, or MetalLB). See Networking.
- Data protection → Plans - snapshots and backups in one go. See Data protection.
- Name it - Settings → Homestead → About this installation → Site name shows under the logo, handy with more than one cluster.
When a release comes out, a Homestead button with the new version appears on the top bar. It, and Settings → Updates, show the version you run, the new one with a link to its release notes, and the helpers Homestead runs beside it (the SMB and NFS servers and the object store used for moves). Update opens the same reviewed rollout apps get: helpers first, Homestead last, the old image kept for rollback. The page reconnects by itself while Homestead replaces itself. Homestead and its helpers are platform containers, so they are hidden on Containers and not counted among app updates; see Settings.
Each release carries the permissions it needs, and Homestead brings its own role up to date when it starts. An install older than that feature needs to be given that right once:
kubectl apply -f https://raw.githubusercontent.com/homestead-lab/homestead/main/deploy/rbac.yamlSettings shows this line whenever Homestead finds it cannot update its role. Use the version-pinned command shown there. The RBAC-only manifest does not replace your Deployment, Service address, configuration or volumes. Avoid reapplying the full install manifest over a customised installation just to gain a new permission.
For a Helm-managed installation, update the existing release using its actual
release name and namespace (shown by helm list -A). For example:
helm upgrade homestead oci://ghcr.io/homestead-lab/charts/homestead -n homestead --version 2.8.167 --reuse-values --set-string image.tag=2.8.167 --wait --timeout 5mThis preserves saved values while explicitly updating the image even if an older tag was pinned. If a HelmChart controller or GitOps manages the release, update its desired version/values there instead of competing with the controller.
After updating, check the installed version, Permissions, and Homestead's
ready status. From v2.8.167, host power control defaults on but still requires an
administrator's impact review and passes no safety blocker automatically. An
explicit ENABLE_NODE_POWER=false stays disabled; changing an environment
setting restarts Homestead, not the host.
The Service is plain HTTP, for your LAN. To reach Homestead from elsewhere - and to install it as an app with push notifications on your phone - put it behind HTTPS. The reference's Cloudflare Tunnel section covers doing that safely: Homestead can change anything in the cluster, so it belongs behind Cloudflare Access (or a VPN), never published bare.
helm uninstall homestead -n homesteadYour apps keep running, and so do the lab namespace and Homestead's data
volume. Delete the homestead-auth Secret yourself if you want the accounts
gone too.
Do not kubectl delete -f deploy.yaml to remove a manifest install: the
manifest also declares the lab namespace, and deleting a namespace deletes
every app and volume in it. Delete Homestead's own objects instead:
kubectl -n lab delete deployment/homestead service/homestead serviceaccount/homestead
kubectl delete clusterrolebinding/homestead clusterrole/homesteadThe homestead-data claim is kept until you delete it from Volumes.
Cluster-wide things Homestead may have made stay too: the PriorityClasses of
the priority tiers, and the hot-spare taint on standby hosts. Set every
critical and low app back to Normal first (or remove priorityClassName
from them yourself): pods running now carry on, but Kubernetes refuses every
new pod that names a class that is gone, so an app still naming one cannot
restart, update or move to another host. Then remove both; the second command
takes the taint off every host that has it, and says not found for each one
that does not, which is expected:
kubectl delete priorityclass homestead-critical homestead-low --ignore-not-found
kubectl taint nodes --all homestead.io/standby-