Uruchom produkcyjną automatykę

Spis treści

Katalog na dane
Plik Compose
Uruchom stack
Testy
Podsumowanie
Co dalej?

Ten wpis pokazuje, jak uruchomić Home Assistanta w środowisku produkcyjnym — stabilnie, bezpiecznie i w sposób, który nie rozpadnie się przy pierwszym restarcie serwera.

Nie będzie tu „magii”. Będzie porządna baza, na której dalej zbudujesz całą automatykę.

Co będzie potrzebne?

Do uruchomienia Home Assistanta w wersji produkcyjnej potrzebujesz tylko trzech rzeczy:

katalogu na dane na serwerze,
pliku docker-compose,
przygotowania stacka w Portainerze.

To wszystko. Reszta to już konsekwencja dobrego startu.

Krok 1 — katalog na dane pomiń

Jeśli przeszedłeś przez wpis Dobra struktura katalogów pod usługi — jesteś w domu.

Jeśli nie — wystarczy, że utworzysz katalog na dane Home Assistant. W moim setupie to:

/opt/homeassistant

Jeśli go nie masz:

sudo mkdir /opt/homeassistant

To będzie jedno źródło prawdy dla:

konfiguracji,
backupów,
integracji.

Krok 2 — plik compose (PROD) pomiń

W katalogu PROD(lokalnie na komputerze) utwórz plik:

home-automation.yml

i wklej:

services:
  homeassistant:
    image: "ghcr.io/home-assistant/home-assistant:2025.12"
    container_name: homeassistant
    restart: always
    environment:
      - "TZ=${TZ}"
    volumes:
      - "${HOMEASSISTANT_DATA}/config:/config"
      - "/etc/localtime:/etc/localtime:ro"
    privileged: true
    network_mode: host
    healthcheck:
      test: "curl --fail http://localhost:8123/ || exit 1"
      interval: 15s
      timeout: 10s
      retries: 3

Tak — konfiguracja jest inna niż w wersji DEV. I bardzo dobrze. DEV służy do testów, PROD ma być nudne i stabilne.

Co tu się właściwie dzieje?

services - Lista usług w stacku.

Tu mamy jedną — Home Assistant.

image

image: "ghcr.io/home-assistant/home-assistant:2025.12"

Dlaczego nie używamy latest?

latest → świetne na DEV
przypięta wersja → bezpieczeństwo w produkcji

W środowisku produkcyjnym kluczowa jest powtarzalność i przewidywalność. Dlatego zamiast latest używamy konkretnego tagu wersji.

Co oznacza tag 2025.12?

Tag 2025.12 oznacza:

zawsze najnowszy build z wydania grudniowego 2025,
bez ryzyka, że nagle wskoczy wersja z innego miesiąca,
bez niespodzianek po automatycznym redeployu.

Masz poprawki błędów z danego wydania, ale nie łapiesz zmian, które mogą wprowadzić regresje.

Moja strategia aktualizacji

Aktualizuję Home Assistanta raz w miesiącu i trzymam się zasady:

produkcja = zawsze jedna wersja major wstecz

Dzięki temu mam już poprawione bugi, omijam problemy świeżych wydań oraz aktualizacja jest świadomą decyzją, a nie przypadkiem.

Tip Przy pierwszym uruchomieniu ustaw tag na wydanie sprzed 2 miesięcy. W sekcji z testami przejdziesz cały proces aktualizacji.

restart: always

Kontener:

padnie → wstanie,
host się zrestartuje → HA też.

Produkcja nie pyta „czy chcesz wrócić?”. Produkcja ma wracać sama.

environment

- "TZ=${TZ}"

Strefa czasowa przekazywana z Portainera.

Dzięki temu:

nie trzymasz wrażliwych danych w repo,
masz jeden punkt zarządzania zmiennymi środowiskowymi.

volumes

"${HOMEASSISTANT_DATA}/config:/config"

Tu dzieje się magia trwałości.

To oznacza:

/config w kontenerze

katalog na serwerze podany w zmiennej HOMEASSISTANT_DATA.

Bez zmiennej wyglądałoby to tak:

/opt/homeassistant/config:/config

Dlaczego zmienne są lepsze?

nie wrzucasz ścieżek do GitHuba,
możesz zmienić lokalizację bez edycji compose,
masz czystsze repo i bezpieczniejszą infrastrukturę.

Drugi mount:

"/etc/localtime:/etc/localtime:ro"

Synchronizacja czasu z hostem — tylko do odczytu (ro).

privileged: true

W produkcji Home Assistant często:

korzysta z USB,
obsługuje Zigbee / Bluetooth,
czyta statystyki hosta.

Tryb privileged daje mu dostęp do tych zasobów bez kombinowania z uprawnieniami.

network_mode: host

To kluczowy element.

Dzięki temu:

Home Assistant działa bez NAT-a Dockera,
automatyczne wykrywanie urządzeń działa poprawnie,
multicast, mDNS, SSDP — wszystko widoczne w sieci lokalnej,
działa WOL dla urządzeń w sieci lokalnej.

Krótko:

HA zachowuje się tak, jakby był uruchomiony bezpośrednio na hoście.

W automatyce domowej to ogromna różnica.

healthcheck

healthcheck:
    test: "curl --fail http://localhost:8123/ || exit 1"
    interval: 15s
    timeout: 10s
    retries: 3

To mechanizm, który pozwala Portainerowi ocenić:

czy Home Assistant naprawdę działa, a nie tylko „jest uruchomiony”.

Jak to działa?

co 15 sekund Portainer odpytuje HA,
jeśli nie dostanie odpowiedzi — uznaje kontener za unhealthy.

To mały detal, ale w produkcji robi ogromną różnicę.

Krok 3 — uruchomienie stacka pomiń

W Portainerze:

1 Dodaj nowy stack.

2 Nazwij go np.:

home_automation

3 Wskaż plik z repo (PROD/home-automation.yml).

4 Ustaw zmienne środowiskowe:

TZ - nazwa strefy czasowej, Europe/Warsaw
HOMEASSISTANT_DATA - na katalog na dane, np.: /opt/homeassistant

lub podczas dodawania zmiennych kliknij Advanced mode i wklej

HOMEASSISTANT_DATA=/opt/homeassistant
TZ=Europe/Warsaw

5 Kliknij Deploy the stack.

Weryfikacja

Portainer => containers

homeassistant-container

Weryfikacja w przeglądarce:

http://IP_SERWERA:8123

homeassistant-first-page

Jeśli zobaczysz ekran powitalny Home Assistanta — właśnie uruchomiłeś produkcyjne środowisko automatyki domowej

Tip — sprawdź, czy dane naprawdę są bezpieczne

To idealny moment, żeby:

utworzyć konto Administratora w Home Assistant i ustawić silne hasło.

Dlaczego właśnie teraz? Bo w tym momencie Home Assistant zaczyna zapisywać dane w katalogu na serwerze — a my chcemy mieć 100% pewności, że wszystko trafia tam, gdzie powinno.

Testy pomiń

Test 1 — czy dane zapisują się na dysku?

Wejdź na serwer i wykonaj:

ls -al /opt/homeassistant/config

Powinieneś zobaczyć zawartość katalogu config, w którym Home Assistant zapisuje m.in.: konfigurację

jeśli katalog jest pusty:

sprawdź poprawność ścieżki w zmiennej HOMEASSISTANT_DATA upewnij się, że nie ma literówki w zmiennej

Możesz też szybko zweryfikować, czy dane nie zapisały się gdzieś indziej:

ls -la /opt/

Jeśli zobaczysz więcej niż jeden katalog typu homeassistant — to znak, że gdzieś po drodze wkradł się błąd w ścieżce.

Opcje naprawy

Opcja 1 — najszybsza (gdy system jest świeży) UTRATA DANYCH

Jeśli masz tylko utworzone konto użytkownika i nic więcej nie skonfigurowałeś:

1 Popraw zmienną HOMEASSISTANT_DATA w stacku Portainera.

2 Zrestartuj kontener:

przejdź do Containers,
zaznacz kontener Home Assistanta,
kliknij Restart.

Gotowe — kontener zapisze dane już w poprawnej lokalizacji.

Opcja 2 — poprawna technicznie (porządkujemy dane)

Jeśli chcesz mieć porządek i przenieść dane do właściwego katalogu:

1 Zatrzymaj kontener Home Assistanta w Portainerze.

2 Na serwerze sprawdź, gdzie faktycznie są dane, np.:

ls -la /opt

3 Jeśli dane są w złym katalogu, zmień jego nazwę na poprawną:

sudo mv /opt/homeassistant_wrong /opt/homeassistant

(zamień homeassistant_wrong na rzeczywistą nazwę błędnego katalogu)

4 W stacku Portainera popraw zmienną:

HOMEASSISTANT_DATA=/opt/homeassistant

5 Uruchom ponownie kontener.

Od tego momentu Home Assistant będzie korzystał z właściwej lokalizacji danych.

Test 2 — magia volumes (czyli prawdziwa persystencja danych)

Skoro masz już utworzonego użytkownika — czas na test, który najlepiej pokazuje sens używania volume.

Krok 1 — usuń kontener

Tak, naprawdę 😄

1 Wejdź w zakładkę Containers w Portainer.

2 Zaznacz kontener homeassistant.

3 Kliknij Remove.

Nie martw się — danych nie usuwasz, bo one żyją poza kontenerem.

Krok 2 — redeploy stacka

1 Przejdź do Stacks.

2 Wybierz home_automation.

3 Kliknij Pull and redeploy.

homeassistant-redeploy-stack

4 Gdy pojawi się okno potwierdzenia:

kliknij Update,
nie zaznaczaj opcji Re-pull image and redeploy.

Po chwili kontener uruchomi się ponownie i wróci do zakładki Containers.

Test 3 — aktualizacja przez GitOps

1 Otwórz plik compose w edytorze (np. VS Code).

2 Zmień tag obrazu:

2025.12 => 2026.1 - nowy tag to obecny miesiąc -1 dla bezpieczeństwa

3 Zapisz zmiany i wypchnij je do repozytorium.

4 Poczekaj chwilę — maksymalnie tyle, ile ustawiłeś w Portainer w opcji GitOps updates (u nas: do 5 minut) + czas na pobranie nowego obrazu.

5 Resztę zrobi Portainer automatycznie:

wykryje zmianę w repo,
pobierze nowy obraz,
utworzy nowy kontener,
zatrzyma i usunie stary.

Czas niedostępności usługi to tylko czas startu Home Assistanta — czyli dokładnie tyle, ile trwa uruchomienie kontenera.

Podsumowanie pomiń

Masz teraz:

stabilny stack,
trwałe dane,
przewidywalne aktualizacje,

fundament pod:

backupy,
monitoring,
automatyzacje,
integracje.

Od tego momentu Home Assistant nie jest już „projektem”. Jest pełnoprawną usługą w Twojej infrastrukturze.

Właśnie w taki sposób będziemy dodawać kolejne klocki do systemu:

1 definiujesz usługę w pliku compose,

2 wypychasz zmiany do repozytorium,

3 Portainer automatycznie wykonuje redeploy stacka.

I nie zawsze będzie to oznaczało tworzenie nowego stacka. W tym samym pliku home_automation możesz jako kolejną usługę dodać np.:

zigbee2mqtt,
esphome,
mqtt,
czy dowolny inny komponent
nie polecam, ale możesz w jednym stacku postawić całe środowisko

Jedno commit → push → automatyczny redeploy i infrastruktura rozszerza się sama — bez klikania w UI.

Dobrze przygotowane stacki dają Ci:

swobodę rozbudowy,
bezpieczeństwo zmian,
pełną kontrolę nad wersjami,
i spokój przy aktualizacjach.

I dokładnie tak powinno wyglądać środowisko produkcyjne — a nie tylko testowa zabawka uruchomiona „na chwilę”.

Konfiguracja/Uruchom Home Assistant

Sugerowane posty

Automatycznego deploy usług

Pierwsze kroki w HomeAssistant

myhomecontrol.pl