Native Kubernetes Deployment Support for Home Assistant

Feature Requests
1

Feature Request: Native Kubernetes Deployment for Home Assistant

Category: Core Architecture Enhancement
Type: New Deployment Mode
Priority: High Impact - Community Driven
Integration: Home Assistant Core / Supervisor

:bullseye: Executive Summary

This feature request proposes adding native Kubernetes deployment support to Home Assistant, alongside existing Home Assistant OS, Container, and Supervised installation methods. This enhancement would transform Home Assistant into a sophisticated, cloud-native platform capable of enterprise-grade scaling, multi-node deployments, and advanced operational capabilities through a custom Supervisor Operator.

:rocket: Problem Statement and Limitations

Existing Home Assistant deployment modes face limitations:

  • Single-node restriction: Limited scalability and redundancy.
  • Manual management: Lacks sophisticated orchestration, automation, and scaling.
  • Operational limitations: Missing DevOps practices, GitOps workflows, enterprise security, and advanced resource management.

These constraints limit Home Assistant’s adoption in enterprise, large-scale residential, and distributed scenarios.

:glowing_star: Proposed Solution: Kubernetes-Native Deployment Mode

Introduce a Kubernetes-native deployment leveraging a Supervisor Operator:

  • Manages Home Assistant lifecycle, add-ons, and configurations.
  • Implements Custom Resource Definitions (CRDs) such as HomeAssistantInstance, AddOn, and SupervisorConfig.
  • Supports horizontal/vertical scaling, geographic redundancy, and advanced security.
  • Provides operational excellence via GitOps, automated backups, monitoring, and observability.

:building_construction: Technical Architecture

Key components:

  • Kubernetes Operator: Uses controller-runtime, managing StatefulSets, Services, Ingresses, ConfigMaps, and Persistent Volumes.
  • Custom Resource Definitions (CRDs): Rich schemas managing deployments, add-ons, configurations, and dependencies.
  • Admission Webhooks: Ensure best practices, prevent misconfigurations.
  • Networking & Storage: Zero-trust network policies, service mesh integration, sophisticated storage management with automated backups.

:bar_chart: Benefits and Impact

  • Scalability: Handles complex automations, large device counts, distributed nodes.
  • High Availability: Kubernetes redundancy, health checks, disaster recovery.
  • Operational Excellence: GitOps workflows, automation, comprehensive monitoring.
  • Security: Zero-trust networking, fine-grained access, audit logging, compliance.
  • Community & Developer Growth: New integrations, AI/ML workloads, edge computing.

:bullseye: Community Benefits

  • Increased enterprise adoption and resources.
  • Expanded developer ecosystem for advanced add-ons.
  • Accelerated innovation in automation, AI integration, edge computing.

:wrench: Implementation Roadmap

Phased approach:

  • Phase 1: Core operator, basic Home Assistant deployments.
  • Phase 2: Advanced add-on management, dependency resolution.
  • Phase 3: High availability, multi-node scaling.
  • Phase 4: Enterprise security, compliance.
  • Phase 5: AI/ML integration, analytics.

:handshake: Community Engagement and Adoption

  • Early feedback, RFCs, prototype demonstrations.
  • Comprehensive documentation, education.
  • Migration tools, compatibility layers.
  • Enterprise validation, partnerships.

:chart_increasing: Success Metrics

  • Performance: Reliability, scaling speed, resource efficiency.
  • Adoption: Number of active deployments, community contributions.
  • Impact: Developer engagement, innovation acceleration.
  • Strategic: Market expansion, technology leadership.

:crystal_ball: Future Vision

  • AI integration for intelligent automations.
  • Edge computing for distributed scenarios.
  • Enterprise-grade platform evolution.
  • Expanded ecosystem for developers.

:bullseye: Call to Action

  • Community feedback, support, and prototype testing.
  • Development team guidance for technical alignment.
  • Collaborative resource planning and phased implementation.

Vote for and support Kubernetes deployment to expand Home Assistant’s capabilities and ecosystem. Your feedback is vital to shaping the platform’s future.

2

  1. Local (and simple) implementation is a core driver of the project so your request does not align at all with current goals and in my opinion is extremely unlikely to be implemented.

  2. Please don’t regurgitate LLM vomit like that again. 90% of it is generic unnecessary guff.

3

You seem to have a lot of experience with Kubernetes. So start coding. Any PR is welcome.

4

If you’re not interested or capable of constructive discussion, feel free to skip this post. Nobody forced you to read it—so if you can’t handle it respectfully, kindly keep your toxic and irrelevant comments to yourself.

5

I’ve actually already started and have seen multiple successful implementations in various repos. My post aimed to understand if there is an interest and openness from the core team to officially adopt Kubernetes-native deployments—before investing further effort. Glad to hear PRs are welcome :grimacing:

6

You don’t get it. Home Assistant is about local control. There is zero chance it will be developed into a core cloud application. There is no point asking for it. Buy all means feel free to follow this path yourself, others have, but it is not going to be an official installation method. If you understood anything about home assistant you wouldn’t even ask for it.

7

And Tom’s statement which you dismissed is probably not too far off.

They already support docker container. That’s as close as you’re probably gonna get. They have no interest in datacenter class kubernetes because and they’re right…

Home assistant isn’t designed for engineering enterprise scale solutions in the cloud… it’s for your home. (btw my day job is basically a cloud architect) I want this stuff running on iron or virtual as close to the house as possible…

8

I seem to recall one of the developers espousing exactly that in one of the recent live streams.

9
10

That was it. Thanks.

11

As written at the bottom of Franck’s article, I also want to Keep It Simple Stupid.

I’ve had quite a few bad experiences with unstable hardware, both storage and boards, and it usually happens when I’m away (Murphy’s law?). When it happens, I’m usually away and can’t fix it. The WAF factor is considerably lowered when this kind of stuff happens.

To solve hardware instability, I wish for a system that is at least moderately available, but still not Enterprise level 99.999%. Just enough so that it can handle that the Raspberry Pi dies. I want it to fix itself hands-off for when I’m away. I, for one, don’t think this simple wish is something that falls into the realm of “The enterprise smart home syndrome”.

Having zero interest in making smart home systems slightly highly available is just fine, but working against people who have an interest in this and even naming a syndrome after them I find is not helpful at all.

A container clustering solution is often quite OK to manage for people who work in IT, but it doesn’t need a full kubernetes cluster to have a fail-over feature. Having a pair of Raspberry Pi’s running in hot-spare mode is something that should be possible/feasible within the realm of non-enterprise smart homes.

It’s great for that time you’re away traveling and the rest of the family is still at home and the RPi breaks down.

A KISS High Available solution should in my opinion be something that the Home Assistant developers should welcome. :slight_smile:

12

ox·​y·​mo·​ron

: a combination of contradictory or incongruous words (such as cruel kindness)

broadly : something (such as a concept) that is made up of contradictory or incongruous elements

13

H aha, of course you’re right, there is no such thing as a simple answer to this problem. :joy: However there are more and less complicated solutions to this problem, and they are all at least a little bit complicated.

Still, ignoring the fact that hardware dies, and having zero solutions to the problem is also not good enough for a lot of us. This is problem exists for everyone, whether we’re working in IT or not. It’s usually the people working in IT that have the skills to try to fix this problem.

We can try to fix it in a more complicated or less complicated way, and the solution is quite often less complicated when built into the software instead of added later by external methods.

14

I’ve been running Home Assistant on a single-node cluster since April, and I see real value in the community creating a Helm chart and possibly a few CRDs. We could always build it ourselves and make it work—I’m happy to contribute to that effort. It doesn’t need to be an officially supported solution; anyone interested can collaborate, and we can help each other out.

As history has shown many times: build it, and they will come.

Footnote:
For context, my setup includes NFS storage, Zigbee2MQTT, Matter, and the new ZBT2 acting as an OpenThread border router. I also run Mosquitto, InfluxDB 2, AirConnect, and manage all secrets using External Secrets integrated with Bitwarden.

15

I have a lot of small pieces of hardware (mostly old laptops) that i’d like to use to deploy apps that are currently addons. Having the central management platform of homeassistant to pull all the management of these tools onto one place would have benefits.

I don’t have one piece of hardware that would be able to host all the addons, especially with the current VM deployment requirements, so being able to span multiple pieces of hardware that I’ve cobbled together would be great.

I work with Kubernetes for a living and would be interested in looking at whatever you have come up with so far, and contributing where I can.

16

Hello,
HA team has opened the Pandora’s box with add-ons as containers :slight_smile:

17

Hi. I currently have it running across two nodes and then use labels on nodes to indicate which node has bluetooth, zigbee, matter etc. Using this I set that as a requirement for certain deployments. I connect all add-ons via services and only expose the needed via Treafik. In this setup I let the scheduling over to the cluster based on the selectors and resources available.

18

Wanted to say that I also would like an option for highly (or at least moderately available) home assistant. Currently have it somewhat working using longhorn but its clunky. At least being able to move the DB out of the container would be a huge step forward.

Kubernetes support would be very nice as if I have a hardware issue, I do not want my home being effected. My current setup means there can be a few minutes of downtime which is way better than needing to restore a backup myself and the potentially hours of downtime but being able to spin up another container in seconds with no longhorn issues would be excellent.

I think this could also benefit those that are not running kubernetes in the future, even potentially used in the official hardware projects.

19

What is the status on this discussion? Has anyone started an initiative, @hahmad? And have you already looked at przemekhys/homeassistant-operator? I assume this would already do the job.

Nevertheless, I agree this might be overengienered. What is the added value? Why should someone favour this option over the other official options?

20

Y’know, I’ve seen this article before, and I always meant to write the contra-Frenck-on-simplicity response and never quite got around to it.

The summary, though, would be that in some cases Kubernetes deployment actually is the simple solution. (Docker Swarm might have been simpler, but Docker Swarm seems to be a dead product these days.)

If you have a small and simple smart home and aren’t hosting anything else significant, sure, get yourself a Home Assistant Green, or a Raspberry Pi to put HAOS on, and be happy.

(I don’t. Looking at the current usage metrics of just my HA container-without-database, it would come close to crushing a 4GB Pi dead. Add in the Postgres database and the auxiliary containers for image recognition, ESPHome, HA-MCP, Mosquitto, Node-RED, and Ring-MQTT needed to support it, and phut!)

But more to the point, it assumes that Home Assistant is the only, or close to it, thing you’re self-hosting, or that everything else is available and best suited to run as HA sub-apps. And for a lot of self-hosters, that isn’t even close to true.

And when you look at the big picture of hosting multiple containerized apps, the Home Assistant folks’ default position of wanting it to run on its own hardware or its very own virtual machine so it can own the container orchestrator (both very heavyweight demands in both usage and maintenance compared to the modal containerized app out there) starts to seem just a little… precious.

Now, to come at this from the other end as well, everyone arguing against k8s support seems to be imagining some super-complex enterprise-class massively-redundant system. Sure, but that’s a few homelabbers (or the denizens of r/homedatacenter) who are doing it for fun; they don’t need your support and probably don’t want it.

Whereas I suspect what most of the pro-k8s people have in mind is something more like this:

A redundant array of inexpensive servers.
A redundant array of inexpensive servers.1456Ă—2234 725 KB

i.e., put three cheap NUCs in a 3D-printed racklet, park them on the end of your desk running k3s or microk8s, and let them happily host every containerized app you’ll ever need for the next decade or so.

Not having to worry about hardware failures is gravy; having a mini-cluster that barely requires any maintenance[1] and which you can throw HA, and Grocy, and Spoolman, and DokuWiki, and Vaultwarden, and Calibre, and Gitea, and Mattermost, and Paperless, and Shaarli, and Transmute, and Plex, and qBittorrent, and whatever else you might want to use from the giant list of commonly self-hosted apps at without needing any special setup or thinking about hardware requirements is the killer app.

And much more simple, IMAO, than deploying them all manually, especially if they were to want custom VMs or hardware.

Now, for myself, I don’t have much invested in this: as long as Home Assistant Container exists I can write my own deployments, patch around the limitations, and make it work. Been doing it for years. It would be nice if the app store worked on k8s, given that it’s a full container orchestrator right there, but to be fair, I’d probably still use my own deployments for other apps anyway.

But what would be good for Home Assistant, in my opinion, is (a) noticing that a lot of smart-home people are also self-hosting-others-apps people, (b) noticing that there’s a pattern to how a lot of self-hosters host containerized apps, relative to which Home Assistant’s preferred methods of being hosted are a near-unique pain in the ass, and (c) not exiling people who prefer to follow the typical containerized-app pattern when it comes to HA to the land of “That’s unsupported, you weirdos, no help for you! And we will now lecture you on how you’re Doing It Wrong!”.

  1. Like, ten minutes a month to check log files and run apt update; apt upgrade, usually. ↩︎