Single-node Kubernetes.
A smart-home hub.

One server, several useful jobs

A home server earns its place by helping with everyday tasks. Open a document from a laptop or phone. Turn a meeting recording into text. Watch a film on the television. The next step is to let that same system respond to the physical home: movement, temperature and an open door.

My server already handles several of these jobs. It runs a single-node Kubernetes cluster: one physical computer provides the control plane and runs the applications. This creates a shared platform for deploying separate services and managing their configuration.

Not every service needs to run inside Kubernetes. Samba, for example, runs on the host. In this architecture, the server provides the hardware, Kubernetes hosts applications, and Home Assistant would provide the home-control layer. Each has a distinct responsibility.

Why use Kubernetes at home with only one node?

The practical benefit is a consistent way to operate multiple applications. You can describe which container should run, where its data belongs and how to check whether it is ready. Configuration records the intended system, so an update does not depend on remembering how a process was originally started.

Shared workloads deserve particular attention at home. Transcribing a long recording, scanning a media library and running a database can all compete for resources. Set appropriate requests and limits, then compare them with actual usage. They help manage allocation; they do not create extra memory or processing capacity. Kubernetes resource management.

The cost is maintaining the cluster itself: upgrades, networking, storage and recovery. If the whole project is Home Assistant and a couple of supporting services, Docker Compose or Home Assistant OS may require less effort. Kubernetes makes sense when it is already part of the household infrastructure, or when operating it is an intentional part of the project.

A single node gives services a common operating model. It does not make the computer highly available.

How Home Assistant, MQTT and Zigbee fit together

For the proposed setup, I would use Home Assistant for the interface and automation logic, Mosquitto as the MQTT broker, and Zigbee2MQTT to connect the broker to the Zigbee radio network. A SONOFF coordinator provides the radio interface.

A temperature sensor sends a reading over Zigbee. The coordinator receives it, Zigbee2MQTT publishes it to MQTT, and Home Assistant uses it in a dashboard or automation. A command to a compatible relay travels in the opposite direction. Device discovery requires the MQTT integration in Home Assistant and discovery enabled in Zigbee2MQTT. Integration documentation.

An alternative is ZHA, which connects a coordinator directly to Home Assistant. That Zigbee setup does not need a separate MQTT broker. Choose one owner for a coordinator: ZHA and Zigbee2MQTT cannot both use it at the same time. ZHA documentation.

For Kubernetes, the relevant installation is Home Assistant Container. It does not include the app installation mechanism available in Home Assistant OS; Mosquitto and Zigbee2MQTT must be deployed separately. This suits an owner willing to maintain each component. Home Assistant installation options.

SONOFF: USB by the server, or Ethernet near the sensors?

SONOFF is a brand covering different devices. Before configuring anything, identify the exact model, radio chipset and installed firmware. A consumer Zigbee Bridge should not be assumed to behave like a USB coordinator.

Option 1. A USB coordinator

The CC2652P-based ZBDongle-P uses the zstack adapter in Zigbee2MQTT. The EFR32MG21-based ZBDongle-E uses ember with compatible firmware. Similar-looking dongles need different settings. ZBDongle-P · ZBDongle-E.

USB is a reasonable fit when the server is in a suitable radio location. The deployment needs access to the device, a stable way to identify the adapter and placement of Zigbee2MQTT on the node with that USB port. After unplugging and reconnecting the dongle, verify that communication recovers; a running process alone is not enough.

Option 2. A network coordinator

SONOFF Dongle Max, model Dongle-M, supports Ethernet and PoE power. It can sit closer to the living area while the server stays in a utility room. This introduces a dependency on the switch and local network. Zigbee2MQTT recommends wired connectivity for remote adapters because Wi-Fi latency and packet loss can disrupt their serial protocol. Connecting Dongle Max · Adapter recommendations.

In either case, test coverage in the actual house. Compatible mains-powered devices can extend the Zigbee mesh; a battery sensor should not be counted on as a repeater. Check support for the exact device model and required features, rather than relying on the Zigbee logo alone.

Five automations worth starting with

The first automation should deliver a small, understandable benefit and be easy to test. These are design examples, not automations already verified on my server.

1. Night lighting. Motion in a hallway turns on a compatible lamp at low brightness. The light goes off after a defined period without further motion. Start with one area and retain ordinary manual control.
2. Bathroom humidity. A sensor reports humidity; Home Assistant compares it with a threshold and controls ventilation through a suitable relay. Separate on and off thresholds help avoid repeated switching.
3. An open window. After several minutes of ventilation, the system changes the mode of a compatible thermostat. Closing the window restores the previous setpoint. Test what happens if communication with the sensor is lost.
4. Water detection. A leak sensor triggers a local alert. Automatic shut-off is a separate project requiring a suitable valve actuator, manual control and testing. Critical household protection should remain independent of this server.
5. A button by the front door. One press turns off selected lights. Define the group explicitly, keeping refrigerators, networking equipment and other essential loads outside it.

Write down four things for each automation: the event, the condition, the action and how it ends or can be overridden. For example: “motion → after 11 p.m. → light at 15% → off after two minutes without motion.” That is a testable requirement other people in the household can understand.

What happens when the internet or server goes down?

A local Zigbee automation can be designed without a manufacturer's cloud. Independence from the internet, however, does not remove dependencies on power, the radio network or the home computer. The proposed architecture needs to be considered one failure at a time.

Some Zigbee devices support direct binding, such as a remote controlling a lamp. Commands can then bypass Home Assistant, but support and behaviour must be checked for the specific devices. Zigbee binding explained.

What to plan before pairing the first sensor

Persistent data and backups

Home Assistant configuration, Zigbee2MQTT data and any required broker data need to survive outside a container's writable filesystem. A PersistentVolume addresses storage lifecycle; it is not a backup. A copy on the same disk does not protect against that disk failing. Kubernetes storage.

I would keep application configuration and a supported coordinator backup on separate storage, protect them as sensitive data and test recovery. Whether a Zigbee network can migrate depends on the adapter and software in use.

One owner for the coordinator

One coordinator requires one active Zigbee2MQTT instance. An update must not create a second competing owner of the device. When using Helm, enable persistent storage explicitly and configure node placement for a USB adapter. Running Zigbee2MQTT on Kubernetes.

Networking and access

Do not expose management interfaces or MQTT to the public internet simply for convenience. Existing protected access to the home network can support remote management. Multicast discovery needs a separate network design; a regular Ingress does not solve it. Configure MQTT accounts and permissions for the topics they need.

A practical validation sequence

Connect one sensor and one controllable device. Verify readings and manual commands, then add a simple automation. Next, test application restarts, a server reboot and loss of the external internet connection, one at a time. An observed result is the basis for saying that a particular automation survives a particular failure.

When this architecture makes sense

My home server already brings together documents, email, media and audio processing. A smart home adds another set of events and actions to that computing platform. Clear responsibilities help: Kubernetes operates applications, Home Assistant holds the household logic, and SONOFF connects the software to Zigbee devices.

A small first setup is enough: a coordinator, a sensor, a lamp and one understandable automation. Once its dependencies are known and recovery has been tested, the system becomes easier to extend. Being able to explain and maintain each step is what makes a home platform useful over time.

Frequently asked questions