2026'da Homepage'i Self-Host Etme: İzin Verilen Host'lar, Widget'lar ve Yapılandırma

“Homepage'i çalıştırmanın” iki farklı anlamı vardır: Bir container'ın mevcut olması veya servisin gerçek görevini tamamlaması. Önemli olan yalnızca ikincisidir. Buradaki doğrulama; servisleri ve yer imlerini yüklemek, canlı birkaç widget'ı çağırmak, aramayı test etmek ve bir YAML yapılandırma dosyasını düzenledikten sonra yeniden başlatmaktır.

Homepage şu amaçla kullanılır: self-host edilen servisler için canlı widget'lara sahip bir başlangıç sayfası. Dağıtım, bu davranışın arkasındaki parçaları korumalıdır; bir port, volume ve sertifika girdidir, sonuç değildir.

En küçük kullanılabilir Homepage topolojisini seçin

Kullanışlı bir Homepage diyagramı; herkese açık rotayı, özel port 3000'i, state sınırını ve tüm destek gereksinimlerini göstermelidir. Hangi okların kimlik bilgilerini, hangilerininse sıradan kullanıcı trafiğini taşıdığını işaretleyin. Homepage için harici gereksinim, isteğe bağlı servis widget'ları için salt okunur yapılandırma ile kimlik bilgileridir. Başka bir inbound servis yayınlamadan outbound DNS, TLS ve provider davranışını test edin.

Diyagramı tek bir gerçek işlemle doğrulayın: servisleri ve yer imlerini yükleyin, canlı birkaç widget'ı çağırın, aramayı test edin ve bir YAML yapılandırma dosyasını düzenledikten sonra yeniden başlatın. Muhtemel baskı; widget fan-out'u, yavaş downstream API'ler, DNS çözümlemesi ve tarayıcı dashboard'unun yenileme hızından kaynaklanır. Tüm HTTP isteklerini eşit görmek yerine bu yolu izleyin.

Homepage'i tahmin yürütmeden güncelleyin

Homepage için ilk anlamlı operasyonel metrik; servisleri ve yer imlerini yükleyebilmesi, canlı birkaç widget'ı çağırabilmesi, aramayı test edebilmesi ve bir YAML yapılandırma dosyasını düzenledikten sonra yeniden başlatılabilmesidir. Bunu widget fan-out'u, yavaş downstream API'ler, DNS çözümlemesi ve tarayıcı dashboard'unun yenileme hızı için saturation sinyalleriyle birlikte değerlendirin. Yalnızca process durumunu kontrol eden bir probe, pahalı bağımlılıkları çağırmamalı veya bir upstream kısa süreliğine kullanılamadığında container'ı yeniden başlatmamalıdır.

Yapılandırma anahtarları ve widget entegrasyonları değişebileceğinden güncellemeleri veri değişiklikleri olarak ele alın; bu nedenle image güncellemesinden önce YAML'ı ve provider davranışını doğrulayın. Sürümleri pin'leyin, geri yüklenmiş state üzerinde prova yapın ve rollback geçerli olmaya devam edene kadar önceki image'ı erişilebilir tutun. Host reddedildiğinde veya YAML girintisi yapılandırmanın yüklenmesini engellediğinde, yeniden başlatma öncesindeki log'ları saklayın; nedensel mesaj genellikle orada bulunur.

Homepage için production kabul çalıştırması

Gerçek kullanıcılar gelmeden önce Homepage için bir release çalışma sayfası hazırlayın. Bu sayfada pin'lenmiş image, port 3000, canonical origin, kalıcı yollar ve isteğe bağlı servis widget'ları için salt okunur yapılandırma ile kimlik bilgilerinden sorumlu kişi belirtilmelidir. Şu işlemin beklenen sonucunu ekleyin: servisleri ve yer imlerini yüklemek, canlı birkaç widget'ı çağırmak, aramayı test etmek ve bir YAML yapılandırma dosyasını düzenledikten sonra yeniden başlatmak.

Çalışma sayfasını hem normal bir replacement sonrasında hem de temiz bir restore sonrasında kullanın. Recovery yalnızca servisler, yer imleri, widget'lar ve custom asset'ler geri geldiğinde ve tüm kritik widget'lar downstream hatalarını görünür biçimde ele aldığında kabul edilir. Ayrıca widget fan-out'u, yavaş downstream API'ler, DNS çözümlemesi ve tarayıcı dashboard'unun yenileme hızını kapsayan kısa bir resource trace toplayın; gelecekteki kapasite değişikliklerini aynı workload ile karşılaştırabilmek için bunu release'in yanında saklayın.

Kontrollü bir hata da ekleyin: isteğe bağlı servis widget'ları için salt okunur yapılandırma ile kimlik bilgilerinin kullanıldığı test yolunu geçici olarak engelleyin. Homepage'in sorunu doğru sınırda raporladığını doğrulayın, geçerli koşulu geri getirin ve işlemi yeniden çalıştırın. Bu, yalnızca başarıyı değil hata görünürlüğünü de kontrol eder ve sağlıklı görünen bir arayüzün bozuk bir worker'ı, callback'i veya database bağlantısını gizlemesini önler.

Homepage başlangıcını tekrarlanabilir hâle getirin

Container'ı gerçeğin tutulduğu yer olarak değil, değiştirilebilir bir runtime olarak kullanın.

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

İsteğe bağlı servis widget'ları için salt okunur yapılandırma ile kimlik bilgilerinin gerektirdiği outbound veya client-side yolu açın ve doğrulayın. Dışarıya açmadan önce container kullanıcısını, yazılabilir yolları ve bound listener'ı inceleyin. Eksiksiz işlemi — servisleri ve yer imlerini yüklemek, canlı birkaç widget'ı çağırmak, aramayı test etmek ve bir YAML yapılandırma dosyasını düzenledikten sonra yeniden başlatmak — çalıştırın ve sonucu üreten tam image referansını kaydedin.

Değiştirilebilir container'ları kalıcı verilerden ayırın

Kalıcı recovery set'i yapılandırma dosyaları, yer imleri, servisler ve custom asset'lerden oluşur. Bootstrap işleminden önce /app/config'i mount edin, zararsız örnek veriler yazın ve bu yolun gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Bir volume verileri container replacement işleminden korur; ancak host kaybına, yanlışlıkla silinmeye veya application-level corruption'a karşı koruma sağlamaz.

Veri kaynağını anlayan yedeklemeler alın: gerektiğinde canlı database'ler için logical dump kullanın ve dosyaları yalnızca tutarlı bir state'den kopyalayın. Şifrelenmiş bir kopyayı Homepage host'undan ayrı bir yerde tutun. Restore için kabul kriteri nettir: servisler, yer imleri, widget'lar ve custom asset'ler geri gelmeli; tüm kritik widget'lar downstream hatalarını görünür biçimde ele almalıdır. Restore ile test edilmiş yedekleme rehberi, yalnızca job başarısının neden yeterli olmadığını açıklar.

Domain'ler, proxy header'ları ve port 3000

Browser, API client ve Homepage aynı origin üzerinde anlaşmalıdır. Bunu sağlamak için izin verilen host'ları tam domain ve proxy hostname için ayarlayın. Orijinal host ve protocol bilgisini korurken port 3000'in rakip bir public adres olarak erişilebilir olmasını engelleyin.

Site erişilemiyor sorun giderme rehberi, erişilemeyen bir route ile yanıt veren bir application arasındaki farkı anlamanıza yardımcı olur. Buradaki ayrım önemlidir: host reddedilmiş olabilir veya YAML girintisi config'in yüklenmesini engelliyor olabilir. Yalnızca ilk durum ingress değişiklikleriyle düzeltilir; ikinci durum Homepage log'larının, state'in veya workload'un incelenmesini gerektirir.

Homepage'e özgü güvenlik kararları

Güvenlik varsayımlarını yerel bir tutorial'dan devralmayın. Homepage'e özgü temel sorun, widget API key'lerinin public bir repository'ye commit edilmesidir. Bu nedenle production ortamında allowed host'ları tam olarak belirleyin ve widget API key'lerini public bir repository yerine environment veya secret-backed config içinde tutun.

HOMEPAGE_ALLOWED_HOSTS gizlilikten çok davranışı kontrol eder; türünü ve değerini doğrulayın, gerçek Homepage kimlik bilgilerini ayrı tutun. Dosya sistemi ve network erişimini kapsamlandırın, setup endpoint'lerini koruyun ve widget fan-out'u, yavaş downstream API'ler, DNS çözümlemesi ve tarayıcı dashboard'unun yenileme hızı çevresinde upload, request veya execution limit'leri tanımlayın.

Dockup, Homepage için hangi işleri ortadan kaldırır?

Homepage için Dockup, image ile kalıcı servis arasındaki sınırda en faydalı hâle gelir. Compute Dockup'a veya bağlı sunucunuza ait olsa da 3000 portuna giden route'u, TLS'i, secret değerlerini ve storage'ı container replacement işlemleri boyunca bağlı tutar.

Application bilgisini kullanarak süreci tamamlayın: izin verilen host'ları tam domain ve proxy hostname için ayarlayın; isteğe bağlı servis widget'ları için salt okunur yapılandırma ile kimlik bilgilerine izin verip bunları doğrulayın; şu doğrulamayı çalıştırın: servisleri ve yer imlerini yükleyin, canlı birkaç widget'ı çağırın, aramayı test edin ve bir YAML yapılandırma dosyasını düzenledikten sonra yeniden başlatın. Sonucu bir deployment check olarak saklayın; böylece bir sonraki image güncellemesi container durumuna göre değil, davranışa göre değerlendirilir.

Sık sorulan sorular

Production deployment için Homepage'in neye ihtiyacı vardır?

Homepage container'ını tek bir HTTPS origin üzerinden port 3000'e route edin. Harici delivery gereksinimi, isteğe bağlı servis widget'ları için salt okunur yapılandırma ile kimlik bilgileridir. Servisleri ve yer imlerini yükleyemiyor, canlı birkaç widget'ı çağıramıyor, aramayı test edemiyor veya bir YAML yapılandırma dosyasını düzenledikten sonra yeniden başlatamıyorsanız Homepage'i hazır kabul etmeyin.

Homepage'e ait hangi veriler yedeklenmelidir?

/app/config'i kalıcı hâle getirin ve yapılandırma dosyalarını, yer imlerini, servisleri ve custom asset'leri aynı recovery manifest'ine dahil edin. Temiz bir Homepage restore işlemi yalnızca servisler, yer imleri, widget'lar ve custom asset'ler geri geldiğinde ve tüm kritik widget'lar downstream hatalarını görünür biçimde ele aldığında başarılıdır.

Homepage reverse proxy arkasında HTTPS gerektirir mi?

Public Homepage origin'i için HTTPS kullanın ve port 3000'i internal route üzerinde tutun. Homepage ayarını doğru uygulayın: izin verilen host'ları tam domain ve proxy hostname için ayarlayın. Homepage için HTTPS, credentials veya kullanıcı içeriğinin aktarım sırasında korunmasını sağlar ve origin'e duyarlı client davranışının tutarlı kalmasına yardımcı olur.

Homepage güncellemesi nasıl test edilmelidir?

Mevcut Homepage state'ini izole bir deployment'a restore edin, aday sürümü uygulayın ve kabul işlemini tekrarlayın. Yapılandırma anahtarları ve widget entegrasyonları değişebileceğinden özellikle dikkatli olun; image güncellemesinden önce YAML'ı ve provider davranışını doğrulayın. Veri migration'ı ve rollback sınırı anlaşılana kadar önceki Homepage image'ını saklayın.