Indeks dnevnikaDockup / bilješka s terena
Note / self-host-homarr

Kako samostalno hostati Homarr u 2026.: nadzorne ploče, tajne i pločice uživo

Praktični vodič za samostalno hostanje Homarra koji obuhvaća Docker, portove, trajne podatke, TLS, sigurnost, sigurnosne kopije i kvarove koji onemogućuju upotrebu u produkciji. Korak po korak.

Homarr container može biti zelen, dok je funkcija do koje je korisnicima stalo neispravna. Kod Homarra se taj skriveni kvar najčešće očituje tako da widgeti ne mogu dohvatiti servise jer koriste lokalne adrese hosta. Ovaj vodič kao test prihvaćanja uzima postupak „izradi nadzornu ploču, dodaj pločicu servisa, konfiguriraj jednu integraciju s vjerodajnicama i nakon ponovnog pokretanja potvrdi status uživo i pretraživanje” te deployment gradi unatrag od tog rezultata.

Homarr u stacku ima jasno definiranu ulogu: searchable dashboard s pločicama uživo za self-hostane servise. Produkcijsko pitanje stoga nije odgovara li port 7575 jednom, nego nastavljaju li stanje, dependencies i javna adresa biti usklađeni nakon ponovnog pokretanja, ažuriranja i vraćanja iz sigurnosne kopije.

Najprije definirajte uspjeh za Homarr

Nemojte dopustiti da Homarr image slučajno odredi produkcijsku arhitekturu. Image osigurava proces na portu 7575, no storage, routing i vanjski zahtjevi i dalje trebaju pažljivo definirane životne cikluse. Lokalni runtime zahtjev čine trajni podaci aplikacije i vjerodajnice za live integracije. To treba biti dio plana kapaciteta i mountova, uz jasno definiranog vlasnika i mjerljivo ograničenje.

Deployment je spreman za detaljnije testiranje kada može izraditi nadzornu ploču, dodati pločicu servisa, konfigurirati jednu integraciju s vjerodajnicama te nakon ponovnog pokretanja potvrditi status uživo i pretraživanje. Pratite transakciju u logovima i nadzirite fan-out zahtjeva widgeta, latenciju downstream API-ja, veličinu podataka aplikacije i broj istodobnih klijenata nadzorne ploče. Ta opažanja pokazuju izolira li trenutna topologija odgovarajuću komponentu.

Uvježbajte rizičnu promjenu Homarra

Zeleni container nužan je, ali nije dovoljan. Service-level indicator je uspješan završetak postupka „izradi nadzornu ploču, dodaj pločicu servisa, konfiguriraj jednu integraciju s vjerodajnicama i nakon ponovnog pokretanja potvrdi status uživo i pretraživanje”, dok su vjerojatni pokazatelji opterećenja fan-out zahtjeva widgeta, latencija downstream API-ja, veličina podataka aplikacije i broj istodobnih klijenata nadzorne ploče.

Upravljanje promjenama važno je jer Homarr schema migrations i kontinuitet encryption keyja mogu utjecati na pohranjene vjerodajnice integracija. Sačuvajte stari image, testirajte migracije na kopiranom stanju i dokumentirajte podržava li se rollback nakon promjene schemе. Ako widgeti ne mogu dohvatiti servise jer koriste lokalne adrese hosta, dijagnosticirajte prvu granicu koja se razlikuje od radnog okruženja.

Zabilježite poznato dobar deployment Homarra

Nemojte promet prvih korisnika koristiti kao test prihvaćanja Homarra. Pripremite bezopasno ogledno stanje i provedite cijeli postupak „izradi nadzornu ploču, dodaj pločicu servisa, konfiguriraj jednu integraciju s vjerodajnicama i nakon ponovnog pokretanja potvrdi status uživo i pretraživanje”. Zabilježite točan javni URL, rezultat, referencu imagea i interval logova povezan s izvođenjem.

Zamijenite container i ponovite postupak bez ponovne izgradnje podataka. Zatim izvršite oporavak na praznom hostu; uvjet oporavka jest da se nadzorne ploče, korisnici, integracije i prilagođena sredstva vrate te da se widgeti s vjerodajnicama ponovno povežu. U svakom prolazu pratite fan-out zahtjeva widgeta, latenciju downstream API-ja, veličinu podataka aplikacije i broj istodobnih klijenata nadzorne ploče te definirajte alert oko degradacije transakcije, a ne oko metrika neaktivnog containera.

Jedna završna provjera trebala bi namjerno završiti neuspjehom: pošaljite bezopasan unos blizu ograničenja resursa ili formata povezanog s ovom granicom: widgeti ne mogu dohvatiti servise jer koriste lokalne adrese hosta. Provjerite identificira li poruka Homarra odgovarajuću granicu umjesto da pokrene brisanje podataka ili beskonačno ponovno pokretanje. Vratite valjano stanje i potvrdite da ista ogledna transakcija ponovno uspijeva. Ovu kratku vježbu zadržite na kontrolnom popisu za release.

Pokrenite prvu instancu oblikovanu prema produkciji

Prvi container trebao bi se moći jednostavno obrisati i ponovno izraditi. Držite podatke izvan writable layera, vežite port 7575 samo tamo gdje mu proxy može pristupiti i prosljeđujte konfiguraciju tijekom runtimea.

docker run -d \
  --name homarr \
  --restart unless-stopped \
  -p 127.0.0.1:7575:7575 \
  -v homarr-data:/appdata \
  -e SECRET_ENCRYPTION_KEY=replace-with-a-long-random-value \
  ghcr.io/homarr-labs/homarr:latest

Nakon početnog testa fiksirajte image. Pročitajte najraniju startup grešku umjesto završne poruke o ponovnom pokretanju, provjerite svaki mount pomoću docker inspect i pratite logove dok izradite nadzornu ploču, dodate pločicu servisa, konfigurirate jednu integraciju s vjerodajnicama te nakon ponovnog pokretanja potvrdite status uživo i pretraživanje. Taj slijed razlikuje neispravnu naredbu za image od problema s dependencyjem ili dozvolama.

Volumes su tek prvi sloj oporavka

Kod Homarra sigurnost redeploya počinje s nadzornim pločama, korisnicima, integracijama, tajnama i prilagođenim sredstvima. Montirajte /appdata prije bootstrapanja, upišite bezopasne ogledne podatke i zamijenite container kako biste dokazali da je taj put doista trajan. Testirajte put tako da zamijenite container dok bezopasni ogledni podaci postoje; time ćete otkriti mountove usmjerene jedan direktorij previsoko ili prenisko.

Zatim testirajte disaster recovery na praznom hostu. Prema potrebi upotrijebite export baze podataka konzistentan s aplikacijom i provjerite vraćaju li se nadzorne ploče, korisnici, integracije i prilagođena sredstva te ponovno povezuju li se widgeti s vjerodajnicama. Vodič za sigurnosne kopije baze podataka koje ste testirali vraćanjem pruža bolji cilj od puke provjere je li arhivska datoteka izrađena.

Spriječite da uspjeh proxyja prikrije neuspjeh aplikacije

Browser, API client i Homarr moraju se slagati oko jednog origina. Da bi to bilo tako, postavite vanjski HTTPS hostname i dopuštene origine. Sačuvajte izvorni host i protokol, a port 7575 držite nedostupnim kao konkurentsku javnu adresu.

Vodič za rješavanje problema kada je web-stranica nedostupna pomaže razlikovati nedostupnu rutu od aplikacije koja odgovara. Ta je razlika ovdje važna: widgeti ne mogu dohvatiti servise jer koriste lokalne adrese hosta. Promjene na ingressu rješavaju samo prvi slučaj; drugi zahtijeva pregled Homarrovih logova, stanja ili workloadа.

Zatvorite privremeni pristup za postavljanje

Siguran deployment Homarra počinje uklanjanjem ovlasti. Nemojte mijenjati encryption key nakon pohrane tajni integracija; umjesto toga, zadržite SECRET_ENCRYPTION_KEY stabilnim, zaštitite uređivanje nadzornih ploča i ograničite svaku vjerodajnicu widgeta.

Generirajte SECRET_ENCRYPTION_KEY jednom, nemojte ga spremati u Git i sačuvajte ga uz recovery manifest jer njegova promjena može poništiti šifrirano ili potpisano stanje aplikacije. Ograničite administrativne rute, za dependencies koristite private DNS i pregledajte svaki bind mount. Kada se logovi centralno prikupljaju, filtrirajte tajne i privatni sadržaj prije nego što napuste server.

Premjestite ponovljivi infrastrukturni rad u Dockup

Za Homarr je Dockup najkorisniji na granici između imagea i trajnog servisa. Održava rutu do porta 7575, TLS, vrijednosti tajni i storage povezanima tijekom zamjene containera, neovisno o tome nalazi li se compute u Dockupu ili na vašem priključenom serveru.

Završite s poznavanjem aplikacije: postavite vanjski HTTPS hostname i dopuštene origine; potvrdite lokalni zahtjev — trajne podatke aplikacije i vjerodajnice za live integracije; te provedite ovu provjeru: izradite nadzornu ploču, dodajte pločicu servisa, konfigurirajte jednu integraciju s vjerodajnicama i nakon ponovnog pokretanja potvrdite status uživo i pretraživanje. Rezultat zadržite kao deployment check kako bi se sljedeće ažuriranje imagea procjenjivalo prema ponašanju, a ne prema statusu containera.

Često postavljana pitanja

Što je Homarru potrebno za produkcijski deployment?

Usmjerite Homarr container na portu 7575 kroz jedan HTTPS origin. Lokalni runtime zahtjev čine trajni podaci aplikacije i vjerodajnice za live integracije. Nemojte Homarr smatrati spremnim dok ne možete izraditi nadzornu ploču, dodati pločicu servisa, konfigurirati jednu integraciju s vjerodajnicama te nakon ponovnog pokretanja potvrditi status uživo i pretraživanje.

Koji Homarr podaci pripadaju sigurnosnoj kopiji?

Ustrajno pohranite /appdata i u isti recovery manifest uključite nadzorne ploče, korisnike, integracije, tajne i prilagođena sredstva. Uspješno vraćanje Homarra potvrđeno je tek kada se nadzorne ploče, korisnici, integracije i prilagođena sredstva vrate te se widgeti s vjerodajnicama ponovno povežu.

Zahtijeva li Homarr HTTPS iza reverse proxyja?

Za javni Homarr origin koristite HTTPS, a port 7575 zadržite na internoj ruti. Ispravno primijenite Homarrovu postavku: postavite vanjski HTTPS hostname i dopuštene origine. Za Homarr HTTPS štiti vjerodajnice ili korisnički sadržaj tijekom prijenosa te održava dosljedno ponašanje klijenta osjetljivo na origin.

Kako testirati nadogradnju Homarra?

Vratite trenutačno Homarr stanje u izolirani deployment, primijenite kandidatnu verziju i ponovite njegovu transakciju prihvaćanja. Obratite posebnu pozornost jer Homarr schema migrations i kontinuitet encryption keyja mogu utjecati na pohranjene vjerodajnice integracija. Zadržite prethodni Homarr image dok ne razjasnite granice migracije podataka i rollbacka.