Athom recently released the Homey Self-Hosted Server as an official Docker image (ghcr.io/athombv/homey-shs), which means you can now run the Homey smart home platform on your own hardware instead of a Homey Pro appliance. That raises a fun question for those of us running VMware Cloud Foundation at home or in the lab: where does a container like this land in a VCF 9.1 environment? A vSphere Pod on the Supervisor, a VKS cluster, or a plain Docker VM?
The short answer: put it in a small Linux VM in a workload domain. The longer answer is more interesting, because this little container is a nice case study in why some workloads fundamentally don’t fit vSphere Pods — and why that is by design.
What the Homey container actually needs
The requirements from Athom’s documentation are modest: a Linux-based OS (Debian or Ubuntu), an Intel/AMD or Arm 64-bit CPU, 1 GB of RAM and 1 GB of storage. But two lines in the Docker Compose file do all the architectural heavy lifting:
services:
homey-shs:
image: ghcr.io/athombv/homey-shs:latest
container_name: homey-shs
restart: unless-stopped
network_mode: host
privileged: true
volumes:
- ~/.homey-shs:/homey/user
network_mode: host and privileged: true — Homey wants to sit directly on the LAN with a dedicated IP address, because it relies on mDNS multicast for device discovery, and it wants near-unrestricted access to the host kernel. Athom explicitly notes that virtual machines should use bridged networking so the server is reachable on the LAN. The server listens on four ports: 4859 (HTTP + Socket.io), 4860 (HTTPS + Socket.io), and 4861/4862 for the Homey Bridge server (v1/v2). All persistent state lives in a single volume.
Keep those two Compose lines in mind — they decide the placement discussion below almost on their own.
The recommended option: a small Linux VM in a workload domain
This is by far the most practical route in VCF 9.1, and it takes about fifteen minutes:
- Deploy a small VM (Ubuntu or Debian, 2 vCPU, 2 GB RAM, 20 GB disk is plenty) on an NSX segment — overlay or VLAN-backed — that has Layer 2 reachability to your IoT and smart home devices. mDNS discovery works within the subnet, so placement on the right segment matters more than sizing.
- Install Docker and start the container with the Compose file above (docker compose -f homey-shs.yml up --detach).
- Open ports 4859–4862 in the NSX distributed firewall (and gateway firewall if applicable), then pair the server with your Athom account via my.homey.app.
- For Zigbee, Z-Wave and Thread you need radios. The clean way in a virtual environment is a Homey Bridge on the network, which talks to the server over ports 4861/4862. The alternative — a USB dongle with ESXi USB passthrough — works, but pins the VM to a host and breaks vMotion and DRS, which defeats much of the purpose of running it on VCF in the first place.
- Put the ~/.homey-shs volume in your backup scope, or simply protect the whole VM with your VADP-based backup product. That one directory holds the entire configuration.
The Kubernetes option: VKS
Could you run this on a vSphere Kubernetes Service cluster instead? Technically, yes. VKS worker nodes are ordinary Linux VMs with a full kernel, so a pod with hostNetwork: true and privileged: true, plus a PersistentVolumeClaim through the vSAN CSI driver, will run fine. But you gain very little: Homey is a single-instance stateful appliance, it would share the node’s IP address, and mDNS discovery becomes harder to reason about. Kubernetes adds operational surface without adding value here. If you already run everything on VKS as a matter of principle, it works — otherwise, keep it simple.
Why vSphere Pods are off the table
The Supervisor’s native vSphere Pods might seem like the elegant answer — no VM to manage, no VKS cluster to maintain. But privileged containers and vSphere Pods fundamentally don’t mix, and it is worth understanding why.
On regular Kubernetes, a pod runs as a set of processes on a node: a Linux machine with one kernel shared by dozens of pods. privileged: true means “give this container near-total access to that node kernel” — all capabilities, direct access to /dev, the ability to load kernel modules and manipulate the host network stack, with seccomp and AppArmor out of the way. That is exactly what Homey uses (together with host networking) to sit directly on the LAN.
A vSphere Pod works fundamentally differently. The Supervisor runs every pod through the CRX runtime as its own stripped-down virtual machine directly on ESXi, with a dedicated, slimmed Photon kernel per pod. There is no shared node kernel to get privileged access to — the “host” is the ESXi hypervisor itself, and that is deliberately never exposed to a workload. This is precisely the selling point of vSphere Pods: VM-grade isolation for every single pod. Allowing privileged access would break that security model, so the Supervisor simply doesn’t support it.
For the same reason, every pod spec that refers to a “node” is unavailable:
- hostNetwork — there is no host network stack to join; the pod’s vNIC attaches to an NSX segment
- hostPath volumes — there is no node filesystem
- hostPID and hostIPC — no shared process or IPC namespaces
- Device passthrough — no way to hand a USB Zigbee dongle to a CRX pod
Homey Self-Hosted Server asks for almost exactly the list of things vSphere Pods deliberately don’t offer. That is not a limitation to work around; it is two security models that point in opposite directions.
Conclusion
VCF 9.1 gives you three ways to run containers, and this workload sorts them out neatly. vSphere Pods are excluded by design — their per-pod micro-VM isolation is incompatible with a privileged, host-networked container. VKS can do it, but brings Kubernetes overhead to a single-instance appliance that doesn’t benefit from it. A small Ubuntu VM on the right NSX segment, running Docker with the official Compose file, gets you a fully supported Homey server with vMotion, DRS, HA and your regular backup tooling — exactly the qualities you run VCF for.
