Homarr zelf hosten in 2026: dashboards, secrets en live tegels

Een Homarr-container kan groen zijn terwijl de functionaliteit waar gebruikers om geven niet werkt. Bij Homarr is dat verborgen probleem meestal dat widgets geen verbinding kunnen maken met services omdat ze host-local adressen gebruiken. Deze handleiding beschouwt “een board maken, een servicetegel toevoegen, één integratie met credentials configureren en na een herstart de live status en zoekfunctie controleren” als de acceptatietest en werkt de deployment vanuit dat resultaat terug.

Homarr heeft een specifieke rol in de stack: een doorzoekbaar dashboard met live tegels voor self-hosted services. De productievraag is daarom niet of poort 7575 één keer antwoord geeft, maar of state, dependencies en het publieke adres na een herstart, update en restore met elkaar blijven overeenkomen.

Definieer eerst wat succes voor Homarr betekent

Laat de Homarr-image niet per ongeluk de productiearchitectuur bepalen. De image levert een proces op 7575; opslag, routing en externe vereisten hebben nog steeds bewust gekozen lifecycles nodig. De vereiste voor de lokale runtime is persistente app-data plus credentials voor live-integraties. Dit hoort thuis in het capaciteits- en mountplan, met een eigenaar en een meetbare limiet.

De deployment is klaar voor diepgaandere tests zodra deze een board kan maken, een servicetegel kan toevoegen, één integratie met credentials kan configureren en na een herstart de live status en zoekfunctie kan bevestigen. Volg de transactie in de logs en houd widget request fan-out, downstream API-latency, de omvang van app-data en het aantal gelijktijdige dashboardclients in de gaten. Die observaties laten zien of de huidige topology het juiste component isoleert.

Oefen de risicovolle wijziging aan Homarr

Een groene container is noodzakelijk, maar niet voldoende. De service-level indicator is het succesvol voltooien van “een board maken, een servicetegel toevoegen, één integratie met credentials configureren en na een herstart de live status en zoekfunctie bevestigen”, terwijl de waarschijnlijke druksignalen widget request fan-out, downstream API-latency, de omvang van app-data en het aantal gelijktijdige dashboardclients zijn.

Change control is belangrijk omdat Homarr-schema-migraties en de continuïteit van de encryptiesleutel invloed kunnen hebben op opgeslagen integratiecredentials. Bewaar de oude image, test migraties met gekopieerde state en documenteer of rollback na de schemawijziging wordt ondersteund. Als widgets geen verbinding kunnen maken met services omdat ze host-local adressen gebruiken, diagnosticeer dan de eerste boundary die afwijkt van de werkende omgeving.

Leg een bekende goede Homarr-deployment vast

Maak verkeer van de eerste gebruiker niet tot de acceptatietest voor Homarr. Bereid ongevaarlijke voorbeeld-state voor en voer de volledige actie “een board maken, een servicetegel toevoegen, één integratie met credentials configureren en na een herstart de live status en zoekfunctie bevestigen” uit. Noteer de exacte publieke URL, het resultaat, de image-referentie en het loginterval dat bij de run hoort.

Vervang de container en herhaal dit zonder de data opnieuw op te bouwen. Herstel vervolgens naar een lege host; de herstelvoorwaarde is dat boards, gebruikers, integraties en custom assets terugkomen en dat widgets met credentials opnieuw verbinding maken. Observeer widget request fan-out, downstream API-latency, de omvang van app-data en het aantal gelijktijdige dashboardclients bij elke run en definieer een alert rond degradatie van de transactie, niet rond metrics van een inactieve container.

Eén laatste controle moet expres mislukken: dien ongevaarlijke input in vlak bij de resource- of formatlimiet die bij deze boundary hoort: widgets kunnen geen verbinding maken met services omdat ze host-local adressen gebruiken. Controleer of het Homarr-bericht de relevante boundary benoemt in plaats van data te verwijderen of een eindeloze restart te veroorzaken. Herstel de geldige toestand en bevestig dat dezelfde voorbeeldtransactie slaagt. Houd deze korte oefening in de releasechecklist.

Start de eerste productieachtige instance

De eerste container moet eenvoudig te verwijderen en opnieuw aan te maken zijn. Houd data buiten de writable layer, bind poort 7575 alleen waar de proxy erbij kan en geef configuratie tijdens runtime door.

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

Pin de image na de eerste test. Lees de vroegste startupfout in plaats van het laatste restartbericht, controleer elke mount met docker inspect en volg de logs terwijl je een board maakt, een servicetegel toevoegt, één integratie met credentials configureert en na een herstart de live status en zoekfunctie bevestigt. Die volgorde maakt onderscheid tussen een verkeerd imagecommando en een dependency- of permissieprobleem.

Volumes zijn alleen de eerste herstel-laag

Voor Homarr begint veilige redeployment bij boards, gebruikers, integraties, secrets en custom assets. Mount /appdata vóór de bootstrap, schrijf ongevaarlijke voorbeelddata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Test het pad door de container te vervangen terwijl de ongevaarlijke voorbeelddata nog bestaat; zo komen mounts aan het licht die één directory te hoog of te laag wijzen.

Test vervolgens disaster recovery op een lege host. Gebruik waar nodig een application-consistente database-export en controleer of boards, gebruikers, integraties en custom assets terugkomen en widgets met credentials opnieuw verbinding maken. De handleiding voor databaseback-ups die je hebt teruggezet biedt een sterker doel dan alleen controleren of er een archiefbestand is aangemaakt.

Voorkom dat proxy-succes applicatiefalen verbergt

De browser, API-client en Homarr moeten het eens zijn over één origin. Stel daarvoor de externe HTTPS-hostname en toegestane origins in. Behoud de oorspronkelijke host en het oorspronkelijke protocol en zorg ervoor dat poort 7575 niet beschikbaar is als concurrerend publiek adres.

De handleiding voor het oplossen van een onbereikbare site helpt onderscheid te maken tussen een onbereikbare route en een applicatie die wel antwoord geeft. Dat onderscheid is hier belangrijk: widgets kunnen geen verbinding maken met services omdat ze host-local adressen gebruiken. Alleen het eerste probleem los je op met ingress-wijzigingen; voor het tweede zijn inspectie van Homarr-logs, state of workload nodig.

Sluit tijdelijke toegang voor de installatie af

Een veilige Homarr-deployment begint met het verwijderen van bevoegdheden. Wijzig de encryptiesleutel niet nadat integratiesecrets zijn opgeslagen; houd in plaats daarvan SECRET_ENCRYPTION_KEY stabiel, bescherm het bewerken van boards en beperk elke widgetcredential tot de benodigde scope.

Genereer SECRET_ENCRYPTION_KEY één keer, houd deze buiten Git en bewaar hem bij het recovery-manifest, omdat wijzigen ervan versleutelde of ondertekende applicatiestate ongeldig kan maken. Beperk administratorroutes, gebruik private DNS voor dependencies en controleer elke bind mount. Wanneer logs centraal worden verzonden, filter dan secrets en private content voordat ze de server verlaten.

Verplaats het herhaalbare infrastructuurwerk naar Dockup

Voor Homarr is Dockup het nuttigst op de grens tussen een image en een duurzame service. Het houdt de route naar 7575, TLS, secretwaarden en opslag gekoppeld tijdens het vervangen van containers, ongeacht of de compute van Dockup of van je gekoppelde server komt.

Rond af met applicatiekennis: stel de externe HTTPS-hostname en toegestane origins in; bevestig de lokale vereiste — persistente app-data plus credentials voor live-integraties; en voer deze verificatie uit: maak een board, voeg een servicetegel toe, configureer één integratie met credentials en bevestig na een herstart de live status en zoekfunctie. Bewaar het resultaat als deploymentcontrole, zodat de volgende image-update op gedrag wordt beoordeeld en niet op de containerstatus.

Veelgestelde vragen

Wat heeft Homarr nodig voor een productiedeployment?

Routeer de Homarr-container op poort 7575 via één HTTPS-origin. De vereiste voor de lokale runtime is persistente app-data plus credentials voor live-integraties. Beschouw Homarr pas als klaar wanneer je een board kunt maken, een servicetegel kunt toevoegen, één integratie met credentials kunt configureren en na een herstart de live status en zoekfunctie kunt bevestigen.

Welke Homarr-data hoort in een back-up?

Maak /appdata persistent en neem boards, gebruikers, integraties, secrets en custom assets op in hetzelfde recovery-manifest. Een schone Homarr-restore is pas geslaagd wanneer boards, gebruikers, integraties en custom assets terugkomen en widgets met credentials opnieuw verbinding maken.

Heeft Homarr HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Homarr-origin en houd poort 7575 op de interne route. Pas de Homarr-instelling correct toe: stel de externe HTTPS-hostname en toegestane origins in. Voor Homarr beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het voor consistent clientgedrag dat afhankelijk is van de origin.

Hoe test je een upgrade van Homarr?

Herstel de huidige Homarr-state naar een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat Homarr-schema-migraties en de continuïteit van de encryptiesleutel invloed kunnen hebben op opgeslagen integratiecredentials. Bewaar de vorige Homarr-image totdat de grenzen van datamigratie en rollback duidelijk zijn.