Home Assistant in Docker pe VPS: ce merge si cum il configurezi

Home Assistant e cel mai apropiat lucru de o telecomanda universala pe care il are lumea casei inteligente: un singur dashboard, un singur motor de automatizari si mii de integrari care fac becurile, termostatele, prizele, senzorii si serviciile cloud de la producatori diferiti sa vorbeasca intre ele. Cei mai multi il ruleaza pe o cutiuta langa router. Dar poate nu vrei inca un dispozitiv prin casa, poate administrezi mai multe locuri deodata (apartamentul tau, casa parintilor, o cabana), sau pur si simplu vrei sa-l accesezi de oriunde, pe o adresa HTTPS ca lumea, fara sa deschizi porturi pe routerul de acasa. In situatiile astea, un VPS devine un loc interesant pentru el. Interesant, nu magic: unele lucruri merg mai bine decat acasa, altele au nevoie de un tunel inapoi catre reteaua ta, iar cateva pur si simplu nu functioneaza dintr-un data center. In tutorialul asta instalam Home Assistant cu docker compose pe un VPS proaspat, il punem in spatele HTTPS, conectam integrari cloud si construim un tunel WireGuard pentru dispozitivele locale care chiar au nevoie de el.

Proiectul e pe home-assistant.io , e open source sub licenta Apache 2.0 si e administrat de Open Home Foundation. Tot ce folosim aici e imaginea oficiala de container Home Assistant, plus doua unelte open source cunoscute: Caddy pentru HTTPS si WireGuard pentru tunelul spre casa.

De ce ai rula Home Assistant pe un VPS (si cand nu merita)

Hai sa fim sinceri de la inceput, pentru ca asa iti salvam un weekend. Home Assistant a fost gandit sa fie local first: sta in casa ta, vorbeste cu dispozitivele prin reteaua de acasa si continua sa mearga si cand pica internetul. Mutat pe un VPS, modelul asta se schimba.

Ce castigi:

• Nimic de pazit acasa. Fara carduri SD corupte, fara alimentatoare care cedeaza, fara cutii sub televizor. VPS-ul sta intr-un data center cu alimentare si retea redundante.
• Acces de la distanta curat. Un nume de domeniu real, cu certificat HTTPS valid, accesibil din aplicatia de telefon de oriunde, fara port forwarding acasa si fara sa conteze daca providerul iti da IP public (multe conexiuni de acasa din Romania stau in spatele CGNAT).
• O singura instanta pentru mai multe locatii. Un VPS poate ajunge in mai multe case prin tuneluri separate, sau pur si simplu aduna la un loc dispozitivele conectate la cloud, oriunde ar fi ele.
• Ideal pentru setup-uri bazate pe cloud. Daca majoritatea dispozitivelor tale vorbesc deja cu cloud-ul producatorului (multe prize Wi-Fi, aspiratoare robot, pompe de caldura, date meteo, preturi la energie), Home Assistant are nevoie doar de internet, iar un VPS are din plin.

Ce pierzi:

• Rezistenta la caderi de internet. Daca pica internetul acasa, VPS-ul nu mai ajunge la dispozitivele de acolo, deci automatizarile care depind de ele se opresc pana revine conexiunea.
• Hardware direct. Un VPS nu are port USB pentru un stick Zigbee, Z-Wave sau Bluetooth.
• Descoperirea automata. Multe dispozitive se anunta singure in reteaua locala (mDNS, SSDP). Anunturile astea nu ies niciodata din casa ta.

Tipuri de instalare si de ce Container e varianta potrivita pe VPS

Home Assistant suporta oficial cateva metode de instalare. Home Assistant OS e un sistem de operare complet pe care il scrii pe un dispozitiv dedicat sau intr-o masina virtuala, cu Supervisor si magazin de add-on-uri. Home Assistant Container e doar aplicatia, impachetata ca imagine Docker, pe care o rulezi pe orice server Linux pe care il administrezi deja. Metodele mai vechi, Core si Supervised, au fost declarate depreciate de proiect in 2025, deci pentru instalari noi pe un server folosit si la altele, Container e alegerea corecta.

Daca n-ai mai folosit containere: un container e un pachet usor care contine o aplicatie si tot ce ii trebuie ca sa ruleze, izolat de restul sistemului, dar folosind acelasi kernel ca serverul gazda. Docker e unealta care ruleaza containere, iar Docker Compose ne lasa sa descriem mai multe containere intr-un singur fisier YAML si sa le pornim impreuna.

Singurul compromis: instalarile Container nu au magazin de add-on-uri. Nu e o problema atat de mare cat pare, pentru ca add-on-urile sunt si ele tot containere. Orice ai fi instalat ca add-on (un broker MQTT, Zigbee2MQTT, ESPHome) poate rula ca serviciu obisnuit in acelasi fisier compose.

Ce functioneaza pe un VPS si ce are nevoie de VPN

Inainte sa instalezi ceva, verifica lista ta de dispozitive in tabelul de mai jos. E cea mai importanta parte din articol.

Regula simpla: daca Home Assistant poate ajunge la un dispozitiv dupa adresa IP si port, poate ajunge la el si printr-un tunel. Daca dispozitivul depinde de faptul ca e in acelasi segment de retea locala (descoperire multicast, IPv6 link-local, un cablu USB), nu va merge dintr-un data center. Pentru Zigbee, solutia curata e sa tii acasa un dispozitiv mic cu Zigbee2MQTT care trimite mesajele MQTT catre Home Assistant prin tunel.

De ce ai nevoie

• Un VPS cu Debian 13 sau Ubuntu 24.04, minim 1 vCPU, 2 GB RAM si 20 GB disc. Recomandam clar un VPS KVM (vezi nota despre LXC din sectiunea de depanare).
• Un utilizator cu sudo cu care te poti loga prin SSH.
• Un domeniu sau subdomeniu pe care il controlezi, de exemplu ha.exemplu.ro, cu o inregistrare A catre IP-ul public al VPS-ului. Daca adaugi si o inregistrare AAAA, trebuie sa indice adresa IPv6 a VPS-ului.
• Pentru dispozitivele locale: un dispozitiv Linux mic, mereu pornit, acasa (un Raspberry Pi e perfect) sau un router care suporta WireGuard. Ai nevoie de el doar la pasul 7.
• Cam o ora, din care mare parte e asteptat dupa descarcari.

In tot articolul, inlocuieste ha.exemplu.ro cu domeniul tau, IP_VPS cu adresa serverului si 192.168.1.0/24 cu plaja retelei de acasa.

Home Assistant cu docker compose, pas cu pas

Iata toata procedura dintr-o privire. Fiecare numar de mai jos corespunde unui titlu “Pasul”, ca sa stii mereu unde esti.

Pasul 1: Pregatesti VPS-ul

Logheaza-te prin SSH, actualizeaza sistemul si seteaza fusul orar. Home Assistant foloseste fusul orar pentru automatizari (“porneste centrala la 6:30”), deci conteaza mai mult decat pe un server web obisnuit.

sudo apt update && sudo apt full-upgrade -y
sudo timedatectl set-timezone Europe/Bucharest
timedatectl

Ultima comanda ar trebui sa arate Time zone: Europe/Bucharest si System clock synchronized: yes.

Urmeaza firewall-ul. Un firewall decide ce porturi (usi numerotate prin care serviciile de retea accepta conexiuni) sunt accesibile din internet. Deschidem SSH (22), HTTP (80, necesar pentru validarea certificatului) si HTTPS (443 pe TCP, plus UDP pentru HTTP/3). Pe Ubuntu, ufw e deja instalat dar inactiv; pe Debian nu e instalat, deci prima linie e necesara acolo si nu strica nimic pe Ubuntu.

sudo apt install -y ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 443/udp
sudo ufw enable
sudo ufw status verbose

Permite mereu portul 22 inainte de ufw enable, altfel iti inchizi singur accesul la server. In rezultat ar trebui sa vezi cele patru reguli marcate ALLOW IN.

Daca actualizarea a instalat un kernel nou, reporneste acum. Pe Ubuntu poti verifica fisierul-semnal:

[ -f /var/run/reboot-required ] && echo "Reboot needed" || echo "No reboot flag"

Pe Debian fisierul asta nu e creat implicit, deci comanda va spune mereu “No reboot flag”. Acolo regula e simpla: daca apt a instalat un pachet linux-image nou, ruleaza sudo reboot.

Pasul 2: Instalezi Docker Engine si Compose

Instalam Docker din repository-ul oficial Docker, care ne da un Docker Engine actual si pluginul Compose v2 (comanda docker compose, cu spatiu). Aceleasi comenzi merg si pe Debian, si pe Ubuntu, pentru ca citesc numele distributiei din /etc/os-release.

sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/$(. /etc/os-release && echo "$ID")/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/$(. /etc/os-release && echo "$ID") $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Verifica daca merge:

sudo docker run --rm hello-world
sudo docker compose version

Ar trebui sa vezi “Hello from Docker!”, apoi o linie de versiune de forma Docker Compose version v2.x.x. Serviciul Docker porneste automat la boot pe ambele distributii. In ghidul asta folosim sudo docker ... peste tot; ai putea adauga utilizatorul in grupul docker, dar tine minte ca apartenenta la grupul asta inseamna, practic, acces de root.

Pasul 3: Scrii fisierul docker compose

Tinem totul intr-un singur folder, /opt/homeassistant: fisierul compose, configuratia Caddy si datele Home Assistant.

sudo mkdir -p /opt/homeassistant
cd /opt/homeassistant
sudo nano compose.yaml

Lipeste continutul asta:

services:
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    container_name: homeassistant
    restart: unless-stopped
    environment:
      TZ: Europe/Bucharest
    volumes:
      - ./config:/config
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "127.0.0.1:8123:8123"
    networks:
      - ha_net

  caddy:
    image: caddy:2
    container_name: caddy
    restart: unless-stopped
    depends_on:
      - homeassistant
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks:
      ha_net:
        ipv4_address: 172.30.10.10

networks:
  ha_net:
    ipam:
      config:
        - subnet: 172.30.10.0/24

volumes:
  caddy_data:
  caddy_config:

Ce face fiecare parte:

• image: stable indica mereu ultima versiune Home Assistant. E comod, dar docker compose pull va sari la o noua versiune lunara, cu posibile schimbari incompatibile. Daca preferi actualizari controlate, inlocuieste stable cu un tag de versiune exact, de forma AN.LUNA.PATCH, asa cum apare pe pagina de release-uri a proiectului, si schimba-l constient. caddy:2 fixeaza versiunea majora, ceea ce e sigur.
• volumes: ./config e locul unde Home Assistant isi tine configuratia, baza de date si backup-urile. Fiind un folder pe server, supravietuieste actualizarilor de container. Montarea /etc/localtime tine ceasul containerului sincronizat cu serverul.
• ports: "127.0.0.1:8123:8123": Home Assistant asculta doar pe adresa locala a VPS-ului, deci nu e accesibil direct din internet. Conteaza, pentru ca porturile publicate de Docker ocolesc ufw, asa ca le restrangem chiar la sursa.
• networks: o retea privata cu plaja fixa si o adresa fixa pentru Caddy (172.30.10.10). Avem nevoie de adresa asta la pasul 5, ca sa-i spunem lui Home Assistant in ce proxy sa aiba incredere.

Poate observi ca documentatia oficiala foloseste network_mode: host si privileged: true. Exista ca Home Assistant sa vada reteaua locala pentru descoperire si sa acceseze dispozitive USB. Pe un VPS nu exista retea de acasa de descoperit si nici stick USB, asa ca renuntam la ambele si castigam izolare.

Verifica daca fisierul e valid:

sudo docker compose config --quiet

Daca nu apare nimic, sintaxa e corecta. Un mesaj de eroare iti arata linia cu problema, de obicei o indentare gresita (YAML cere spatii, nu tab-uri).

Pasul 4: Prima pornire si onboarding prin tunel SSH

Deocamdata pornim doar Home Assistant. Imaginea are peste un gigabyte, deci prima descarcare dureaza un minut-doua.

cd /opt/homeassistant
sudo docker compose up -d homeassistant
sudo docker compose logs -f homeassistant

Asteapta pana log-ul nu mai curge repede, apoi apasa Ctrl+C (opresti doar urmarirea log-ului, nu containerul). Testeaza local:

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8123

Raspunsul trebuie sa fie 200. Acum, de ce nu deschidem direct adresa publica? Pentru ca primul om care ajunge la un Home Assistant proaspat isi creeaza contul de proprietar. Nu vrem pagina asta in internet, nici macar cinci minute. Folosim in schimb un tunel SSH: o redirectionare securizata a unui port de pe laptopul tau catre server, prin conexiunea SSH pe care o ai deja. Pe calculatorul tau (Linux, macOS sau Windows 10/11, toate au client SSH inclus) ruleaza:

ssh -L 8123:127.0.0.1:8123 utilizator@IP_VPS

Lasa sesiunea deschisa si intra in browser pe http://localhost:8123. Asistentul de onboarding iti cere sa:

1. Creezi contul de proprietar. Foloseste o parola lunga si unica, contul asta controleaza casa ta.
2. Setezi locatia casei. Alege casa reala pe harta, nu data center-ul, altfel rasaritul, vremea si automatizarile de prezenta vor fi gresite.
3. Alegi unitatile de masura, moneda si preferintele de analytics.
4. Verifici dispozitivele descoperite. Lista va fi goala sau aproape goala pe un VPS. E normal si asteptat.

Pasul 5: Configurezi proxy-urile de incredere

Un reverse proxy e un server care primeste cererile din internet si le transmite unei aplicatii din spatele lui. Al nostru va fi Caddy. Home Assistant respinge intentionat cererile venite prin proxy pana nu ii spui in ce proxy sa aiba incredere, iar fara setarea asta orice cerere prin Caddy se termina cu “400: Bad Request”.

Deschide fisierul de configurare generat de Home Assistant la prima pornire:

sudo nano /opt/homeassistant/config/configuration.yaml

Adauga blocul asta la final (pastreaza liniile existente):

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.30.10.10
  ip_ban_enabled: true
  login_attempts_threshold: 5

use_x_forwarded_for il face pe Home Assistant sa citeasca adresa reala a clientului din header-ul adaugat de Caddy. trusted_proxies limiteaza increderea la adresa fixa a lui Caddy. ip_ban_enabled cu pragul 5 blocheaza un IP dupa cinci logari esuate, si blocheaza atacatorul real, nu pe Caddy, tocmai datorita primelor doua linii.

Valideaza configuratia si reporneste:

cd /opt/homeassistant
sudo docker compose exec homeassistant python -m homeassistant --script check_config --config /config
sudo docker compose restart homeassistant

Verificarea afiseaza “Testing configuration at /config” si nicio eroare daca totul e in regula.

Pasul 6: Activezi HTTPS cu Caddy

Mai intai confirma ca domeniul indica VPS-ul. De pe server:

getent hosts ha.exemplu.ro

Rezultatul trebuie sa contina IP-ul VPS-ului. Acum creeaza fisierul de configurare Caddy. Fa asta inainte sa pornesti Caddy: daca fisierul nu exista, Docker creeaza in locul lui un folder numit Caddyfile, iar Caddy nu va porni.

sudo nano /opt/homeassistant/Caddyfile

{
    email tu@exemplu.ro
}

ha.exemplu.ro {
    reverse_proxy homeassistant:8123
}

Asta e toata configuratia. Caddy obtine un certificat gratuit Let’s Encrypt, il reinnoieste automat, redirectioneaza HTTP spre HTTPS si gestioneaza conexiunile WebSocket pe care se bazeaza interfata Home Assistant. homeassistant:8123 functioneaza pentru ca, in aceeasi retea compose, containerele se gasesc intre ele dupa numele serviciului. Adresa de email e folosita doar pentru avertizari despre expirarea certificatelor.

cd /opt/homeassistant
sudo docker compose up -d caddy
sudo docker compose logs caddy | grep -i certificate
curl -sS -o /dev/null -w "%{http_code}\n" https://ha.exemplu.ro

In log cauta “certificate obtained successfully”. Comanda curl trebuie sa intoarca 200. Deschide https://ha.exemplu.ro in browser si logheaza-te cu contul de proprietar. La final, in Home Assistant mergi la Settings > System > Network si seteaza Home Assistant URL (Internet) la https://ha.exemplu.ro. Aplicatia de telefon si integrarile cu OAuth folosesc adresa asta.

Pastram maparea 127.0.0.1:8123 ca usa de urgenta: daca vreodata se strica Caddy sau DNS-ul, tunelul SSH de la pasul 4 tot te lasa sa intri.

Pasul 7: Conectezi dispozitivele de acasa prin WireGuard

Pasul asta e necesar doar pentru dispozitivele din reteaua de acasa. WireGuard e un VPN modern: doua masini isi schimba cheile publice si construiesc un tunel criptat peste UDP. Un detaliu important pentru acasa: partea de acasa initiaza conexiunea, deci nu ai nevoie de IP public sau port forwarding acasa, si merge si in spatele CGNAT.

Pe VPS, instaleaza WireGuard si genereaza o pereche de chei:

sudo apt install -y wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/vps.key; wg pubkey < /etc/wireguard/vps.key > /etc/wireguard/vps.pub'
sudo cat /etc/wireguard/vps.pub

Fa la fel pe dispozitivul de acasa (un Raspberry Pi cu Raspberry Pi OS sau Debian), numind fisierele home.key si home.pub, si instaleaza acolo si iptables cu sudo apt install -y wireguard iptables.

Creeaza /etc/wireguard/wg0.conf pe VPS cu sudo nano:

[Interface]
Address = 10.66.0.1/24
ListenPort = 51820
PrivateKey = LIPESTE_CONTINUTUL_vps.key

[Peer]
# gateway acasa
PublicKey = LIPESTE_CONTINUTUL_home.pub
AllowedIPs = 10.66.0.2/32, 192.168.1.0/24

AllowedIPs e in acelasi timp filtru si tabela de rutare: ii spune VPS-ului ca reteaua de acasa 192.168.1.0/24 se afla in spatele acestui peer. Deschide portul si porneste tunelul:

sudo ufw allow 51820/udp
sudo systemctl enable --now wg-quick@wg0

Pe dispozitivul de acasa, afla numele interfetei LAN cu ip -br addr (des eth0 sau end0), apoi creeaza /etc/wireguard/wg0.conf:

[Interface]
Address = 10.66.0.2/24
PrivateKey = LIPESTE_CONTINUTUL_home.key
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = LIPESTE_CONTINUTUL_vps.pub
Endpoint = IP_VPS:51820
AllowedIPs = 10.66.0.0/24
PersistentKeepalive = 25

Regula MASQUERADE face ca traficul venit de la VPS sa para ca vine de la Pi, asa ca dispozitivele si routerul raspund fara rute suplimentare. PersistentKeepalive tine tunelul deschis prin routerul de acasa. Activeaza forwarding-ul si porneste tunelul:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sudo systemctl enable --now wg-quick@wg0

Inapoi pe VPS, testeaza tunelul, apoi testeaza din interiorul containerului Home Assistant (inlocuieste IP-urile cu routerul tau si un dispozitiv real):

sudo wg show
ping -c 3 192.168.1.1
cd /opt/homeassistant && sudo docker compose exec homeassistant ping -c 3 192.168.1.50

wg show trebuie sa raporteze un “latest handshake” de acum cateva secunde, iar ambele ping-uri sa primeasca raspuns. Traficul din container ajunge in tunel pentru ca Docker traduce adresele containerelor cand ies din reteaua privata, deci nu e nevoie de configurare in plus pe VPS. Daca in locul unui Pi folosesti un router cu WireGuard (OpenWrt, MikroTik RouterOS 7 si altele), conceptele sunt identice: aceleasi chei, acelasi AllowedIPs si fie NAT, fie o ruta de intoarcere pentru 10.66.0.0/24.

Adaugi integrari cloud si de retea

Cu HTTPS functional, primul lucru de configurat e aplicatia de telefon pentru Android sau iOS: introduci https://ha.exemplu.ro, te loghezi si primesti urmarirea locatiei, senzorii din telefon si notificari push. Notificarile catre aplicatie merg fara niciun abonament platit.

Integrarile cloud se adauga din Settings > Devices & services > Add integration. Vreme, calendare, servicii de muzica, cloud-urile producatorilor de prize si aspiratoare, preturi la energie: toate au nevoie doar de internet spre exterior, iar VPS-ul are din belsug. Integrarile care leaga contul prin OAuth redirectioneaza browserul inapoi catre instanta ta, lucru care merge acum, dupa ce ai setat URL-ul extern.

Dispozitivele de retea prin tunel se adauga manual, dupa IP, pentru ca anunturile de descoperire nu trec prin tunel. De exemplu, integrarea Shelly cere IP-ul dispozitivului, ESPHome cere host si port (6053), integrarea Hue cere IP-ul bridge-ului si apoi apasarea butonului de pe el. Da-le acestor dispozitive IP-uri fixe (rezervari DHCP) in routerul de acasa, altfel o schimbare de adresa strica integrarea. Majoritatea sunt conexiuni initiate de Home Assistant, exact directia pe care o suporta tunelul nostru. Orice lucru de acasa care trebuie sa apeleze Home Assistant (un webhook, un script) poate folosi pur si simplu URL-ul public HTTPS.

Pentru Zigbee, ruleaza Zigbee2MQTT acasa, cu coordonatorul USB, si un broker MQTT (Eclipse Mosquitto) fie acasa, fie ca serviciu in plus in fisierul compose. MQTT e un protocol usor de tip publish si subscribe; Home Assistant se aboneaza la broker, iar dispozitivele apar automat prin MQTT discovery, care, spre deosebire de mDNS, trece fara probleme prin tunel. Daca brokerul ruleaza pe VPS, nu expune niciodata portul 1883 in internet: leaga-l de adresa WireGuard sau cere TLS si parole.

Cat VPS iti trebuie

Home Assistant e o aplicatie Python, iar consumul de RAM creste cu numarul de integrari si cu istoricul pastrat. Restul stack-ului e minuscul.

In practica, 1 vCPU si 2 GB RAM lasa loc confortabil pentru sistem, actualizari si varfurile de la pornire. Discul e resursa care creste pe nesimtite: baza de date de istoric (home-assistant_v2.db) se mareste la fiecare schimbare de senzor. Retentia implicita e de 10 zile; o poti ajusta din setarile recorder (purge_keep_days) si poti exclude senzorii foarte vorbareti care nu te intereseaza.

Actualizari si backup

Home Assistant scoate o versiune noua in fiecare luna, cu versiuni de patch intre ele. Inainte de fiecare actualizare, citeste sectiunea “Backward-incompatible changes” din release notes, apoi:

cd /opt/homeassistant
sudo docker compose pull
sudo docker compose up -d
sudo docker image prune -f

pull descarca imaginile noi, up -d recreeaza doar containerele a caror imagine s-a schimbat, iar prune sterge imaginile vechi ca sa elibereze spatiu. Datele din ./config raman neatinse.

Pentru backup, Home Assistant are o functie integrata in Settings > System > Backups, care merge si pe instalarile Container si salveaza arhivele in config/backups. Versiunile recente cripteaza backup-urile, deci pastreaza cheia de criptare intr-un loc sigur, fara ea backup-ul nu foloseste la nimic. Ca un al doilea strat, simplu, arhiveaza tot folderul cu Home Assistant oprit:

cd /opt/homeassistant
sudo docker compose stop homeassistant
sudo tar czf ~/ha-config-$(date +%F).tar.gz config compose.yaml Caddyfile
sudo docker compose start homeassistant

Apoi copiaza arhiva in afara serverului, de exemplu cu scp pe laptop. Un backup care sta doar pe acelasi VPS nu e un backup.

Depanare si greseli frecvente

• “400: Bad Request” in browser. Home Assistant nu are incredere in proxy. Verifica log-urile cu sudo docker compose logs homeassistant | grep -i proxy: mesajul arata IP-ul de la care a venit cererea. Trebuie sa corespunda cu trusted_proxies (172.30.10.10 in setup-ul nostru). Verifica si ca blocul http: nu apare de doua ori in configuration.yaml.
• Caddy nu obtine certificat. Inregistrarea A nu indica inca VPS-ul, portul 80 e inchis sau o inregistrare AAAA indica alt server. Repara DNS-ul, asteapta cateva minute, apoi sudo docker compose restart caddy.
• Caddy nu porneste, eroare despre un director. Ai pornit Caddy inainte sa creezi Caddyfile si Docker a creat un folder in locul lui. Ruleaza sudo docker compose stop caddy, sudo rm -r /opt/homeassistant/Caddyfile, creeaza fisierul si porneste din nou.
• “Pool overlaps with other one on this address space”. O alta retea Docker sau reteaua ta de acasa foloseste deja 172.30.10.0/24. Alege alta plaja privata si actualizeaza si fisierul compose, si trusted_proxies.
• Blocat dupa logari esuate. Ti s-a blocat propriul IP. Editeaza /opt/homeassistant/config/ip_bans.yaml, sterge intrarea ta si reporneste Home Assistant.
• WireGuard nu arata niciun handshake. De obicei o cheie inversata (fiecare parte are nevoie de cheia publica a celeilalte), UDP 51820 nepermis pe VPS sau un Endpoint gresit. sudo journalctl -u wg-quick@wg0 arata erorile de la pornire.
• VPS-ul da ping in casa, dar containerul nu. Plaja de acasa se suprapune cu o retea Docker, sau dispozitivul are propriul firewall. Testeaza cu alt dispozitiv si verifica ip route pe VPS pentru rute in conflict.
• O integrare de dispozitiv spune “cannot connect”. Descoperirea nu trece prin tunel. Adaug-o manual dupa IP si asigura-te ca IP-ul e rezervat in router.
• Orele din automatizari sunt decalate cu una-doua ore. Variabila TZ sau fusul orar al serverului e gresit. Corecteaza si recreeaza containerul cu sudo docker compose up -d.
• Containere LXC. Daca VPS-ul tau e un container LXC neprivilegiat, Docker merge doar daca nesting-ul e activat pe host, iar WireGuard are nevoie de modulul de kernel incarcat pe host, pentru ca un container nu poate incarca module de kernel. Un VPS KVM evita ambele probleme, de aceea il recomandam pentru proiectul asta.

Note de securitate

O instanta Home Assistant poate descuia usi, opri centrala si arata cine e acasa. Trateaz-o cu aceeasi grija ca pe un cont de email.

• Activeaza autentificarea in doi pasi pentru fiecare utilizator: click pe profil, apoi Security, si activeaza modulul pentru aplicatie de autentificare (TOTP).
• Tine portul 8123 pe localhost. Porturile publicate de Docker ocolesc ufw, deci un port publicat ca 8123:8123 ar fi public chiar si cu firewall-ul pornit. Fisierul nostru compose il leaga intentionat de 127.0.0.1.
• Pastreaza blocarea la logare activa si nu sterge trusted_proxies, altfel blocarile lovesc adresa gresita.
• Trateaza token-urile de acces pe termen lung ca pe niste parole. Creeaza cate unul pentru fiecare script sau dispozitiv, da-le nume clare si sterge-le pe cele nefolosite.
• Nu uita ce inseamna tunelul. Oricine obtine root pe VPS poate ajunge in reteaua ta de acasa prin WireGuard. Limiteaza expunerea din partea de acasa: pune pe Pi reguli de firewall care permit trafic doar spre IP-urile dispozitivelor de care are nevoie Home Assistant, nu spre tot LAN-ul. Regulile de pe VPS singure nu te protejeaza, pentru ca un VPS compromis le poate schimba.
• Actualizeaza ambele straturi. Serverul cu apt si containerele cu docker compose pull. Pe Ubuntu, actualizarile de securitate automate sunt activate implicit; pe Debian, instaleaza si activeaza pachetul unattended-upgrades.
• Tine backup-urile criptate si in afara serverului, iar cheia de criptare a backup-urilor Home Assistant separat de backup-uri.

Deci, merita Home Assistant pe un VPS?

Daca acasa ai mai ales dispozitive conectate la cloud, daca administrezi mai multe locatii sau vrei acces de la distanta solid, fara cutie acasa si fara port forwarding, un VPS e un loc foarte bun pentru Home Assistant. Setup-ul construit e mic si curat: un singur fisier compose, HTTPS care se reinnoieste singur, un port de administrare care nu atinge niciodata internetul si un tunel WireGuard doar pentru dispozitivele care chiar au nevoie de reteaua locala. Daca ai casa plina de senzori Zigbee si vrei ca becurile sa mearga si cand pica internetul, tine Home Assistant acasa si foloseste VPS-ul pentru ce face el cel mai bine: backup, monitorizare sau un bridge MQTT.

Poti porni cu un VPS din data center-ul nostru din Romania, cu latenta mica spre conexiunile de acasa din tara, si ai totul functional intr-o dupa-amiaza. Daca preferi sa nu te ocupi singur de Docker, certificate si chei VPN, echipa noastra de administrare servere poate instala, securiza si intretine tot stack-ul pentru tine.

Intrebari frecvente

Pot instala Home Assistant OS pe un VPS in loc de Docker?

Home Assistant OS e gandit pentru hardware dedicat sau o masina virtuala in care controleaza tot discul. Pe un VPS asta inseamna de obicei sa urci o imagine custom si sa renunti la server pentru orice altceva. Home Assistant Container e metoda suportata oficial pentru un server Linux pe care il administrezi tu, iar serviciile pe care le-ai fi instalat ca add-on-uri pot rula ca containere normale langa el.

Mai am nevoie de Home Assistant Cloud (Nabu Casa)?

Nu pentru acces de la distanta, pentru ca ai deja domeniul tau cu HTTPS. Abonamentul ramane comod pentru legarea Alexa sau Google Assistant fara configurare manuala si finanteaza proiectul. Cele doua variante pot coexista.

Latenta dintre VPS si casa mea e o problema?

In Romania, timpul dus-intors pana la un data center e de obicei intre 10 si 30 ms, ceea ce nu se simte cand aprinzi un bec sau citesti un senzor. Devine relevant doar pentru bucle de control foarte stranse sau pentru streaming de la mai multe camere de rezolutie mare, unde limita reala e viteza de upload de acasa.

Ce se intampla cand pica internetul acasa?

Integrarile cloud si aplicatia de telefon continua sa mearga, pentru ca nu depind de conexiunea de acasa. Dispozitivele accesibile doar prin tunel devin indisponibile pana revine conexiunea, iar automatizarile care le folosesc nu ruleaza. Daca asta e inacceptabil pentru tine, ruleaza Home Assistant acasa.

Pot folosi dispozitive Zigbee sau Bluetooth?

Nu direct, pentru ca un VPS nu are porturi USB sau radiouri. Zigbee merge bine prin Zigbee2MQTT pe un dispozitiv mic acasa, care trimite mesajele prin MQTT. Pentru Bluetooth, un proxy Bluetooth ESPHome acasa poate transmite datele prin tunel, dar asteapta-te la putina latenta in plus.