2026'da Beszel'i Self-Host Etme: Agent'lar, Özel Ağ ve Yedeklemeler

En kısa Beszel demosu, bir process'in 8090 portunu dinlediğini kanıtlar. Production için daha güçlü kanıt gerekir. Container değiştirildikten sonra bile şu senaryoyu başarıyla tamamlamalıdır: bir agent enroll etmek, CPU, memory ve disk grafiklerini izlemek, bir threshold alert tetiklemek ve hub yeniden başlatıldıktan sonra agent'ı yeniden bağlamak.

Beszel net bir amaçla deploy edilir: küçük bir container içinde lightweight server monitoring. En yaygın deployment tuzağı, hub'ın bir agent üzerindeki 45876 portuna erişememesi veya SSH key'in değişmiş olmasıdır. Bu nedenle public URL yönetimi ve kalıcı state, image'ın başlatılması kadar dikkat gerektirir.

Beszel runtime sınırını çizin

Beszel için process sağlığı ile ürün sağlığı birbirinden ayrıdır. 8090 portu yanıt veriyor olabilir, ancak kullanıcıya sunulan transaction hâlâ başarısız olabilir. Beszel'in network contract'ı, izlenen her makinede bir Beszel agent bulunmasıdır. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve Beszel'e kapsamı sınırlandırılmış bir service credential verin.

Anlamlı configuration değişikliklerinden sonra şu readiness çalışmasını yapın: bir agent enroll edin, CPU, memory ve disk grafiklerini izleyin, bir threshold alert tetikleyin ve hub yeniden başlatıldıktan sonra agent'ı yeniden bağlayın. Pahalı external check'leri liveness probe'larından uzak tutun; böylece bir provider kesintisi restart loop'a neden olmaz. Capacity çalışmaları agent sayısını, metrics retention'ı, hub storage'ını ve her agent'a özel port üzerinden sağlanan network reachability'yi takip etmelidir. Bu, Beszel'in gerçek yükünü page request'lerinden daha doğru yansıtır.

Public origin'i belirsiz olmaktan çıkarın

Browser, API client ve Beszel tek bir origin üzerinde anlaşmalıdır. Bunu sağlamak için hub'ı HTTPS üzerinden route edin ve agent port'larını private tutun. Original host ve protocol bilgisini korurken 8090 portunun competing public address olarak erişilebilir olmasını engelleyin.

site-down troubleshooting guide, erişilemeyen bir route ile yanıt veren bir application arasındaki farkı belirlemenize yardımcı olur. Bu ayrım burada önemlidir: hub bir agent üzerindeki 45876 portuna erişemiyor veya SSH key değişmiş olabilir. Ingress değişiklikleri yalnızca ilk sorunu çözer; ikinci sorun için Beszel log'larını, state'i veya workload'u incelemek gerekir.

İlk production'a uygun instance'ı çalıştırın

İlk container kolayca silinip yeniden oluşturulabilmelidir. Verileri writable layer dışında tutun, 8090 portunu yalnızca proxy'nin erişebileceği yerde bind edin ve configuration'ı runtime sırasında geçin.

docker run -d \
  --name beszel \
  --restart unless-stopped \
  -p 127.0.0.1:8090:8090 \
  -v beszel-data:/beszel_data \
  henrygd/beszel:latest

İlk testten sonra image'ı pinleyin. Son restart mesajı yerine en erken startup error'ını okuyun, her mount'ı docker inspect ile doğrulayın ve bir agent enroll ederken, CPU, memory ve disk grafiklerini izlerken, bir threshold alert tetiklerken ve hub restart'ından sonra agent'ı yeniden bağlarken log'ları takip edin. Bu sıra, hatalı bir image command'ini dependency veya permission sorunundan ayırır.

Bir sonraki soruyu yanıtlayan log'lar

Green bir container gerekli olsa da yeterli değildir. Service-level indicator, “bir agent enroll etmek, CPU, memory ve disk grafiklerini izlemek, bir threshold alert tetiklemek ve hub restart'ından sonra agent'ı yeniden bağlamak” işleminin başarıyla tamamlanmasıdır. Olası pressure signal'ları ise agent sayısı, metrics retention, hub storage ve her agent'a özel port üzerinden sağlanan network reachability'dir.

Change control önemlidir; hub ve agent version'ları birlikte test edilmelidir, çünkü protocol değişiklikleri sessiz monitoring boşlukları gibi görünebilir. Eski image'ı koruyun, migration'ları kopyalanmış state üzerinde test edin ve schema taşındıktan sonra rollback'in desteklenip desteklenmediğini dokümante edin. Hub bir agent üzerindeki 45876 portuna erişemiyorsa veya SSH key değişmişse, çalışan environment'tan farklı olan ilk boundary'yi teşhis edin.

Beszel için production acceptance çalışması

Gerçek kullanıcılar gelmeden önce Beszel için bir release worksheet hazırlayın. Bu worksheet'te pinned image, 8090 portu, canonical origin, persistent path'ler ve izlenen her makinedeki Beszel agent'ından sorumlu kişi belirtilmelidir. Şu transaction'ın beklenen sonucunu ekleyin: bir agent enroll etmek, CPU, memory ve disk grafiklerini izlemek, bir threshold alert tetiklemek ve hub restart'ından sonra agent'ı yeniden bağlamak.

Worksheet'i normal bir replacement işleminden ve temiz bir restore işleminden sonra kullanın. Recovery yalnızca system'ler, history ve alert'ler geri geldiğinde ve restore edilen her agent güncel metrics göndermeye yeniden başladığında kabul edilir. Ayrıca agent sayısını, metrics retention'ı, hub storage'ını ve her agent'a özel port üzerinden sağlanan network reachability'yi kapsayan kısa bir resource trace toplayın; gelecekteki capacity değişikliklerini aynı workload ile karşılaştırabilmek için bunu release'in yanında tutun.

Kontrollü bir failure ekleyin: test identity'sinin izlenen her makinedeki bir Beszel agent'ına erişimini geçici olarak engelleyin. Beszel'in sorunu doğru boundary'de raporladığını doğrulayın, geçerli durumu geri yükleyin ve transaction'ı yeniden çalıştırın. Bu, yalnızca başarıyı değil error visibility'yi de kontrol eder ve sağlıklı görünen bir interface'in bozuk bir worker'ı, callback'i veya database connection'ını gizlemesini önler.

Launch öncesinde Beszel restore sürecini tasarlayın

Tüm durable artifact'leri envantere alın: hub data'sı, user'lar, system'ler ve alert configuration. Bootstrap işleminden önce /beszel_data mount'unu oluşturun, zararsız sample data yazın ve bu path'in gerçekten persistent olduğunu doğrulamak için container'ı değiştirin. Yalnızca en büyük directory'yi değil, stored data'nın yorumlanma biçimini değiştiren configuration'ı da dahil edin.

Retention ayarlayın, backup'ları host dışında kopyalayın ve clean-room restore çalıştırın. Beszel drill'i; system'ler, history ve alert'ler geri geldiğinde ve restore edilen her agent güncel metrics göndermeye yeniden başladığında tamamlanır. Snapshot'lar planın parçasıysa, her mekanizmanın neleri kurtarabildiğini dokümante etmek için PITR versus snapshot guidance sayfasını kullanın.

Geçici setup erişimini kapatın

Yalnızca login formunu değil, Beszel'in gerçekleştirdiği action'ı da threat model kapsamına alın. Buradaki yüksek riskli hata, agent listener'larını network control olmadan internete açmaktır. Şu boundary'yi uygulayın: agent listener'larını private network'lerde tutun ve hub account'u ile enrollment key'lerini koruyun.

Bu baseline'da Beszel için zorunlu bir bootstrap secret yoktur; bunun yerine gerçek administrator account'unu veya upstream authentication'ı koruyun. Bir permission error'ını container'ı root olarak çalıştırarak veya host'u geniş kapsamlı mount ederek çözmeye çalışmayın. Agent sayısı, metrics retention, hub storage ve her agent'a özel port üzerinden sağlanan network reachability kullanıcılar tarafından tetiklenebiliyorsa resource limit'leri de security design'ın parçasıdır.

Tekrarlanabilir infrastructure işlerini Dockup'a taşıyın

Beszel için Dockup, bir image ile durable service arasındaki boundary'de en fazla faydayı sağlar. Compute Dockup'a veya bağlı server'ınıza ait olsa da route to 8090, TLS, secret value'lar ve storage'ı container replacement'ları boyunca birlikte korur.

Application bilgisini tamamlayın: hub'ı HTTPS üzerinden route edin ve agent port'larını private tutun; izlenen her makinede bir Beszel agent'ı bağlayıp test edin ve şu verification'ı çalıştırın: bir agent enroll etmek, CPU, memory ve disk grafiklerini izlemek, bir threshold alert tetiklemek ve hub restart'ından sonra agent'ı yeniden bağlamak. Sonucu bir deployment check olarak saklayın; böylece bir sonraki image update'i container status'a göre değil, davranışa göre değerlendirilir.

Sık sorulan sorular

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

Beszel container'ını 8090 portu üzerinden tek bir HTTPS origin'e route edin. Supporting network requirement, izlenen her makinede bir Beszel agent bulunmasıdır. Bir agent enroll edene, CPU, memory ve disk grafiklerini izleyene, bir threshold alert tetikleyene ve hub restart'ından sonra agent'ı yeniden bağlayana kadar Beszel'i ready kabul etmeyin.

Hangi Beszel verileri backup'a dahil edilmelidir?

/beszel_data'yı persistent hâle getirin ve hub data'sını, user'ları, system'leri ve alert configuration'ı aynı recovery manifest'ine dahil edin. Temiz bir Beszel restore'u yalnızca system'ler, history ve alert'ler geri geldiğinde ve restore edilen her agent güncel metrics göndermeye yeniden başladığında başarılı sayılır.

Beszel'in reverse proxy arkasında HTTPS kullanması gerekir mi?

Public Beszel origin'i için HTTPS kullanın ve 8090 portunu internal route üzerinde tutun. Beszel setting'ini doğru uygulayın: hub'ı HTTPS üzerinden route edin ve agent port'larını private tutun. Beszel için HTTPS, credentials veya user content'in transit hâlinde korunmasını ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Bir Beszel upgrade'i nasıl test edilmelidir?

Güncel Beszel state'ini isolated bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Hub ve agent version'larının birlikte test edilmesine özellikle dikkat edin; protocol değişiklikleri sessiz monitoring boşlukları gibi görünebilir. Data migration ve rollback boundary'leri anlaşılana kadar önceki Beszel image'ını saklayın.