Homepage zelf hosten in 2026: toegestane hosts, widgets en configuratie
Een praktische handleiding voor het zelf hosten van Homepage, met aandacht voor Docker, poorten, persistente data, TLS, security, backups en problemen die productiegebruik verhinderen. Inclusief checks.
Er zijn twee versies van ‘Homepage draaien’: er bestaat een container, of de service voert zijn daadwerkelijke taak uit. Alleen de tweede is relevant. Het bewijs bestaat hieruit: services en bookmarks laden, meerdere live widgets aanroepen, zoeken testen en opnieuw starten nadat je een YAML-configuratiebestand hebt bewerkt.
Homepage dient als startpagina met live widgets voor self-hosted services. De deployment moet de onderdelen achter dat gedrag behouden; een poort, een volume en een certificaat zijn inputs, niet het resultaat.
Kies de kleinst bruikbare Homepage-topologie
Een bruikbaar Homepage-diagram toont de publieke route, private poort 3000, de stategrens en alle ondersteunende vereisten. Markeer welke pijlen credentials bevatten en welke gewone user traffic transporteren. De externe vereiste voor Homepage is read-only configuratie plus credentials voor optionele service-widgets. Test outbound DNS, TLS en provider-gedrag zonder nog een inbound service te publiceren.
Bewijs het diagram met één echte actie: services en bookmarks laden, meerdere live widgets aanroepen, zoeken testen en opnieuw starten nadat je een YAML-configuratiebestand hebt bewerkt. De meeste druk komt waarschijnlijk van widget fan-out, trage downstream-API’s, DNS-resolutie en de refresh rate van het browserdashboard; monitor dat pad in plaats van alle HTTP-requests als gelijkwaardig te behandelen.
Upgrade Homepage zonder te gokken
De eerste bruikbare operationele metric voor Homepage is of de service services en bookmarks kan laden, meerdere live widgets kan aanroepen, zoeken kan testen en opnieuw kan starten nadat je een YAML-configuratiebestand hebt bewerkt. Combineer dat met saturation-signalen voor widget fan-out, trage downstream-API’s, DNS-resolutie en de refresh rate van het browserdashboard. Een process-only probe mag geen dure dependencies aanroepen of de container opnieuw starten omdat een upstream kortstondig niet beschikbaar is.
Behandel upgrades als datawijzigingen, omdat configuratiesleutels en widget-integraties kunnen veranderen. Valideer daarom YAML en provider-gedrag voordat je een image-update uitvoert. Pin versies, oefen op een herstelde state en houd de vorige image beschikbaar totdat een rollback geldig blijft. Wanneer de host wordt geweigerd of YAML-inspringing verhindert dat de configuratie wordt geladen, bewaar dan de logs van vóór de restart; daarin staat meestal de causale melding.
Een production acceptance run voor Homepage
Maak vóór de komst van echte users een release-worksheet voor Homepage. Deze moet de gepinde image, poort 3000, canonical origin, persistente paden en de eigenaar van read-only configuratie plus credentials voor optionele service-widgets benoemen. Voeg het verwachte resultaat van deze transactie toe: services en bookmarks laden, meerdere live widgets aanroepen, zoeken testen en opnieuw starten nadat je een YAML-configuratiebestand hebt bewerkt.
Gebruik de worksheet na een normale vervanging en na een clean restore. Recovery wordt alleen geaccepteerd als services, bookmarks, widgets en custom assets terugkomen en alle kritieke widgets downstream-fouten zichtbaar afhandelen. Verzamel ook een korte resource trace met widget fan-out, trage downstream-API’s, DNS-resolutie en de refresh rate van het browserdashboard; bewaar die naast de release, zodat toekomstige capaciteitswijzigingen met dezelfde workload worden vergeleken.
Voeg één gecontroleerde failure toe: blokkeer tijdelijk het testpad dat wordt gebruikt voor read-only configuratie plus credentials voor optionele service-widgets. Controleer of Homepage het probleem op de juiste boundary rapporteert, herstel de geldige conditie en voer de transactie opnieuw uit. Hiermee test je error visibility, niet alleen succes, en voorkom je dat een gezond ogende interface een defecte worker, callback of databaseverbinding verbergt.
Maak de startup van Homepage reproduceerbaar
Gebruik de container als een vervangbare runtime, niet als de locatie van de waarheid.
docker run -d \
--name homepage \
--restart unless-stopped \
-p 127.0.0.1:3000:3000 \
-v homepage-data:/app/config \
-e HOMEPAGE_ALLOWED_HOSTS=home.example.com \
ghcr.io/gethomepage/homepage:latest
Sta het outbound- of client-side pad toe dat nodig is voor read-only configuratie plus credentials voor optionele service-widgets en verifieer dit. Controleer de containergebruiker, writable paths en gebonden listener voordat je de service beschikbaar maakt. Voer de volledige actie uit — services en bookmarks laden, meerdere live widgets aanroepen, zoeken testen en opnieuw starten nadat je een YAML-configuratiebestand hebt bewerkt — en sla de exacte image reference op die het resultaat heeft opgeleverd.
Scheid vervangbare containers van blijvende data
De duurzame recovery-set bestaat uit configuratiebestanden, bookmarks, services en custom assets. Mount /app/config vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Een volume beschermt data tegen het vervangen van een container, maar niet tegen verlies van de host, per ongeluk verwijderen of corruptie op applicatieniveau.
Maak backups die de databron begrijpen: gebruik waar nodig logical dumps voor live databases en kopieer bestanden alleen vanuit een consistente state. Bewaar één encrypted kopie buiten de Homepage-host. Het acceptatiecriterium voor een restore is specifiek: services, bookmarks, widgets en custom assets komen terug en alle kritieke widgets handelen downstream-fouten zichtbaar af. De restore-tested backup guide legt uit waarom alleen job-succes onvoldoende is.
Domeinen, proxy headers en poort 3000
De browser, API-client en Homepage moeten één origin delen. Stel hiervoor allowed hosts in voor het exacte domein en de proxy-hostname. Behoud de oorspronkelijke host en het oorspronkelijke protocol en houd poort 3000 beschikbaar als concurrerend publiek adres.
De site-down troubleshooting guide helpt onderscheid maken tussen een onbereikbare route en een applicatie die antwoord geeft. Dat onderscheid is hier belangrijk: de host wordt geweigerd of YAML-inspringing voorkomt dat de configuratie wordt geladen. Alleen het eerste los je op met ingress-wijzigingen; het tweede vereist inspectie van Homepage-logs, state of workload.
Securitybeslissingen die specifiek zijn voor Homepage
Neem security-aannames uit een lokale tutorial niet automatisch over. Het specifieke aandachtspunt bij Homepage is dat widget API-keys in een public repository terechtkomen. Stel daarom in productie allowed hosts nauwkeurig in en bewaar widget API-keys in environment- of secret-backed configuratie in plaats van in een public repository.
HOMEPAGE_ALLOWED_HOSTS bepaalt gedrag en geen confidentiality; valideer het type en de waarde ervan en bewaar echte Homepage-credentials afzonderlijk. Beperk filesystem- en network access, bescherm setup-endpoints en definieer upload-, request- of execution-limits rond widget fan-out, trage downstream-API’s, DNS-resolutie en de refresh rate van het browserdashboard.
Waar Dockup werk wegneemt voor Homepage
Voor Homepage is Dockup vooral nuttig op de boundary tussen een image en een duurzame service. Het houdt de route naar 3000, TLS, secret values en storage gekoppeld tijdens containervervangingen, ongeacht of de compute bij Dockup of op je gekoppelde server staat.
Rond af met applicatiekennis: stel allowed hosts in voor het exacte domein en de proxy-hostname; sta read-only configuratie plus credentials voor optionele service-widgets toe en verifieer dit; en voer deze verificatie uit: services en bookmarks laden, meerdere live widgets aanroepen, zoeken testen en opnieuw starten nadat je een YAML-configuratiebestand hebt bewerkt. Bewaar het resultaat als deployment-check, zodat de volgende image-update op basis van gedrag en niet op basis van containerstatus wordt beoordeeld.
Veelgestelde vragen
Wat heeft Homepage nodig voor een production deployment?
Routeer de Homepage-container op poort 3000 via één HTTPS-origin. De externe delivery-vereiste is read-only configuratie plus credentials voor optionele service-widgets. Verklaar Homepage pas gereed nadat je services en bookmarks kunt laden, meerdere live widgets kunt aanroepen, zoeken kunt testen en opnieuw kunt starten nadat je een YAML-configuratiebestand hebt bewerkt.
Welke Homepage-data hoort in een backup?
Maak /app/config persistent en neem configuratiebestanden, bookmarks, services en custom assets op in hetzelfde recovery-manifest. Een clean Homepage-restore is alleen geslaagd wanneer services, bookmarks, widgets en custom assets terugkomen en alle kritieke widgets downstream-fouten zichtbaar afhandelen.
Heeft Homepage HTTPS nodig achter een reverse proxy?
Gebruik HTTPS voor de publieke Homepage-origin en houd poort 3000 op de interne route. Pas de Homepage-instelling correct toe: stel allowed hosts in voor het exacte domein en de proxy-hostname. Voor Homepage beschermt HTTPS credentials of user content tijdens transport en houdt het origin-sensitive clientgedrag consistent.
Hoe test je een Homepage-upgrade?
Restore de huidige Homepage-state naar een isolated deployment, pas de candidate version toe en herhaal de acceptance transaction. Let hier extra op, omdat configuratiesleutels en widget-integraties kunnen veranderen. Valideer daarom YAML en provider-gedrag voordat je een image-update uitvoert. Houd de vorige Homepage-image beschikbaar totdat de grens voor data-migratie en rollback duidelijk is.