Home Assistant Container¶
Home Assistant ejecutado como container Docker/OCI standalone, sin Supervisor. Es el otro install method que queda supported después de release 2025.12 y la opción que mejor se presta a tratar HA "como un servicio más" en un host gestionado con IaC.
Contexto¶
Para este wiki, Container es el camino natural si el usuario quiere aplicar prácticas de software engineering al host (Docker Compose pinned, GitOps, observability uniforme con el resto del stack del homelab). El costo: no hay add-ons — Z2M, Mosquitto, ESPHome dashboard, etc., se corren como containers separados que el usuario administra. La pregunta clave es si ese costo se compensa con la disciplina ganada en el resto del stack.
Contenido¶
Qué es¶
- Container OCI (típicamente Docker) que corre sólo Home Assistant Core.
- Image oficial:
ghcr.io/home-assistant/home-assistant:<version>(tambiénhomeassistant/home-assistanten Docker Hub). - Sin Supervisor → sin gestión nativa de add-ons desde la UI. Cada servicio adicional (MQTT broker, Z2M, ESPHome) se corre como container separado.
Por qué siguió supported tras la deprecación 2025-05¶
- Es el path estándar para usuarios que ya corren un host Linux (Docker, K8s no recomendado — ver
analysis/why-not-kubernetespendiente). - Da control total del host al usuario.
- Cualquier runtime OCI compatible sirve (Docker, Podman, etc.).
Patrones de hardening conocidos (a profundizar en futuros ingests)¶
- Pin de versión explícito en
docker-compose.yml:image: ghcr.io/home-assistant/home-assistant:2026.2.0en lugar de:stableo:latest. Hace los rollbacks triviales (docker compose up -dcon tag anterior). - Backups manuales vía UI o snapshot del bind mount.
- Watchtower opcional pero con label
com.centurylinklabs.watchtower.enable=falseen HA si se quiere control humano sobre updates (recomendado por la fragilidad histórica de los upgrades).
Trade-offs vs HAOS¶
| Dimensión | Container | HAOS |
|---|---|---|
| Control del host | Total | Mínimo |
| Add-ons gestionados | No (corrés tus propios containers) | Sí, vía Supervisor |
| Co-locación con otros servicios | Fácil | Difícil |
| Affinity con IaC (Compose/Ansible/Terraform) | Alta | Baja |
| Backup/restore desde UI | Limitado | Completo |
| Onboarding para no-developers | Más exigente | Más simple |
Ver ../comparisons/ha-install-methods-2026 para la matriz completa.
Relaciones¶
- Reemplaza (oficialmente, post-2025.12): home-assistant-supervised (para usuarios que prefieren control total del host) y home-assistant-core.
- Es uno de: home-assistant install methods.
- Contrasta con: home-assistant-os.
- Complementa add-ons separados: Z2M container, Mosquitto, ESPHome dashboard (páginas por crear cuando se ingieran sus respectivos sources).
Citas / evidencia¶
- Tabla de migration paths oficial — ../sources/ha-deprecating-core-supervised-2025-05.
Abierto / gaps¶
- Documentar patrón canónico de Docker Compose con pin de versión + healthcheck + restart policy + bind mount para
/config(candidatojoinhomeshift.com/home-assistant-dockeren gaps media). - Estrategia de backups en Container: ¿UI backup local + sync a NAS? ¿snapshot del volumen vía borg/restic? Definir cuando se ingiera un source que lo trate explícitamente.
- ¿Hay forma supported de tener "el equivalente a add-ons" sin Supervisor? (sidecar containers, docker-compose profile groups). Pregunta abierta hasta cross-check.
- ¿Qué pasa con MQTT discovery cuando MQTT broker y HA están en containers separados con redes Docker? Documentar.