Günlük diziniDockup / saha notu
Note / self-host-filebrowser

2026'da File Browser'ı Self-Host Etme: Volume'lar, Hesaplar ve Güvenli Paylaşım

Docker, portlar, kalıcı veriler, TLS, güvenlik, yedekler ve üretimde kullanımı engelleyen hataları kapsayan pratik bir File Browser self-hosting rehberi.

File Browser'ı yalnızca bir Docker image'ı olarak değil, küçük bir sistem olarak ele alın. File Browser'ın kullanıcıya sunduğu amaç nettir: eklenmiş bir volume için web file manager; ancak deployment, yalnızca kısıtlı bir kullanıcı oluşturabildiğinizde, dosya yükleyip yeniden adlandırabildiğinizde, metin düzenleyebildiğinizde, bir paylaşım oluşturabildiğinizde ve kullanıcının kendisine atanmış root dizininin dışına çıkamadığını doğrulayabildiğinizde kabul edilebilir.

Bu ayrım, operatörlerin local test sonrasında karşılaştığı hata durumunu ortaya çıkarır: mount edilen dosyalar, container'ın okuyamadığı host permission'larını kullanır. Ayrıca backup ve upgrade planını test edilebilecek kadar somut hâle getirir.

File Browser'daki tüm kalıcı verileri bulun

Container image'ı yeniden indirilebilir; sunulan dosyalar ile File Browser database'i ve ayarları yeniden oluşturulamaz. Bootstrap işleminden önce /srv yolunu 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 Compose dosya adına güvenmek yerine etkin mount'u inceleyin ve runtime user'ın File Browser'ın yazmasını beklediği konumlara yazabildiğini kontrol edin.

Saklama politikasını ve off-host hedefini belirleyin, ardından production'a dokunmadan recovery sürecini prova edin. Tatbikat yalnızca sunulan dosyalar, kullanıcılar, scope'lar, paylaşımlar ve ayarlar geri geldiğinde ve kısıtlı bir hesabın sınırları içinde kaldığı doğrulandığında başarılı sayılır. Database tabanlı state için storage snapshot'larını, point-in-time recovery ile snapshot'ların karşılaştırılması bölümünde açıklandığı gibi application-consistent export'larla birlikte kullanın.

Production'a benzeyen ilk instance'ı çalıştırın

İlk File Browser çalıştırma komutunu, bir pull request'te incelenebilecek kadar tekrarlanabilir tutun.

docker run -d \
  --name file-browser \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v file-browser-data:/srv \
  -v file-browser-db:/database \
  -v file-browser-config:/config \
  filebrowser/filebrowser:latest

Gerçek veriler oluştuktan sonra latest kullanmayın. Çalışan digest'i, container user'ını ve mount ownership'ini kaydedin. Tam bir test boyunca application log'unu takip edin — kısıtlı bir kullanıcı oluşturun, dosya yükleyip yeniden adlandırın, metin düzenleyin, bir paylaşım oluşturun ve kullanıcının kendisine atanmış root dizininin dışına çıkamadığını doğrulayın — ardından route'u production trafiğine açmadan önce varsa migration'ları not edin.

File Browser runtime sınırını belirleyin

File Browser için process health ile product health birbirinden ayrıdır. Port 80 yanıt veriyor olabilir, ancak kullanıcıya sunulan işlem yine de başarısız olabilir. Local runtime gereksinimi, database'i ve ayarları için ayrı bir kalıcı path'tir. Bunu acceptance workload altında doğrulayın; boşta çalışan bir health check kaynağın yeterli olduğunu kanıtlayamaz.

Anlamlı configuration değişikliklerinden sonra şu readiness çalışmasını kullanın: kısıtlı bir kullanıcı oluşturun, dosya yükleyip yeniden adlandırın, metin düzenleyin, bir paylaşım oluşturun ve kullanıcının kendisine atanmış root dizininin dışına çıkamadığını doğrulayın. Pahalı external check'leri liveness probe'larından uzak tutun; böylece bir provider kesintisi restart loop'a neden olmaz. Capacity çalışmalarında, page request'lerinden çok File Browser'ın gerçek yükünü yansıtan temel disk throughput'unu, upload boyutunu, eş zamanlı download'ları ve directory sayısını takip edin.

Public origin'i belirsiz olmaktan çıkarın

File Browser için tek bir HTTPS hostname sunun; raw port 80'i private tutun. UI'ı HTTPS üzerinden yayınlayın, ancak sunulan root'u dikkatle sınırlandırın. Böylece browser'ların ve API client'larının birbiriyle yarışan iki farklı adres öğrenmesi engellenir.

Temiz bir client'tan bilinen başarılı işlemi çalıştırın ve ilk başarısız request'i inceleyin. DNS veya TLS hatalıysa custom-domain rehberini kullanın. Route doğrulandıktan sonra “mount edilen dosyalar, container'ın okuyamadığı host permission'larını kullanıyor” durumunu ayrı bir application teşhisi olarak ele alın.

File Browser release gate'i

Küçük ve disposable bir File Browser fixture'ı oluşturun ve bunu her release için saklayın. Fixture gerçek workflow'u çalıştırmalıdır: kısıtlı bir kullanıcı oluşturun, dosya yükleyip yeniden adlandırın, metin düzenleyin, bir paylaşım oluşturun ve kullanıcının kendisine atanmış root dizininin dışına çıkamadığını doğrulayın. Image digest'ini, external hostname'i, dependency adresini ve beklenen sonucu kaydedin; böylece sonraki operatör bu rehberi yorumlamak zorunda kalmadan testi tekrarlayabilir.

Fixture'ı üç kez çalıştırın. İlkinde fresh deployment kullanın. İkincisinde kalıcı state'e dokunmadan container'ı değiştirin. Üçüncüsünde backup'ı boş bir ortama restore edin. Üçüncü çalıştırma yalnızca sunulan dosyalar, kullanıcılar, scope'lar, paylaşımlar ve ayarlar geri geldiğinde ve kısıtlı bir hesabın sınırları içinde kaldığı doğrulandığında başarılı sayılır. Her çalıştırma sırasında temel disk throughput'u, upload boyutu, eş zamanlı download'lar ve directory sayısı çevresindeki latency ve resource kullanımını kaydedin; bu değerler rastgele bir CPU yüzdesi yerine alert'ler için baseline oluşturur.

Son olarak negative path'i kasıtlı olarak test edin: bu sınırla ilişkili resource veya format limitinin yakınında zararsız bir input gönderin: mount edilen dosyalar, container'ın okuyamadığı host permission'larını kullanıyor. File Browser'ın state'i bozmadan görünür bir şekilde başarısız olduğunu doğrulayın, doğru koşulu geri yükleyin ve başarılı işlemi tekrarlayın. Bu dört sonucu içeren bir release kaydı, dashboard ekran görüntülerinden veya tek seferlik bir curl yanıtından daha güçlü kanıttır.

Capacity ve upgrade kontrolleri

Boşta çalışan bir health check, File Browser hakkında çok az şey söyler. Temel disk throughput'unu, upload boyutunu, eş zamanlı download'ları ve directory sayısını izleyin; ardından kullanıcıların deneyimlediği belirti üzerinden alert oluşturun: “kısıtlı bir kullanıcı oluştur, dosya yükleyip yeniden adlandır, metin düzenle, bir paylaşım oluştur ve kullanıcının kendisine atanmış root dizininin dışına çıkamadığını doğrula” işleminin başarısız olması. Liveness'i local ve ucuz tutun; readiness migration'ları veya initialization durumunu bildirsin, ancak restart storm'a neden olmasın.

Riskli upgrade alanı, sunulan dosyalar ayrı bir mount'ta bulunsa bile File Browser database ve settings migration'larının önemli olmasıdır. Release notes'ları okuyun, state'in snapshot'ını alın, hedef version'ı restore edilmiş bir kopya üzerinde deploy edin ve acceptance action'ı tekrarlayın. Mount edilen dosyalar, container'ın okuyamadığı host permission'larını kullanıyorsa state'i silmek veya gelişigüzel redirect eklemek yerine client request'ini ilk ilgili application log girdisiyle ilişkilendirin.

File Browser'ın sahip olduğu yetkileri azaltın

Bootstrap credential'ları geçicidir; trust model kalıcıdır. File Browser'da dedicated share yerine / veya bir secrets directory sunulmasına ve host root yerine dedicated bir directory sunarak her hesaba ihtiyaç duyduğu en dar file scope'unu vermeye dikkat edin.

File Browser'ın bu baseline'da zorunlu bir bootstrap secret'ı yoktur; bunun yerine gerçek administrator hesabını veya upstream authentication'ı koruyun. Image'ı gereksiz Linux capability'leri olmadan çalıştırın ve yalnızca public application route'unu açığa çıkarın. Secret değerlerini kaydetmeden administrator etkinliklerini görünür tutun.

Platform katmanı için Dockup kullanın

File Browser için Dockup, image ile kalıcı bir service arasındaki sınırda en fazla faydayı sağlar. Compute Dockup'a veya ekli server'ınıza ait olsa da route'u 80'e, TLS'i, secret değerlerini ve storage'ı container değişimleri boyunca bağlı tutar.

Application bilgisini kullanarak tamamlayın: UI'ı HTTPS üzerinden yayınlayın, ancak sunulan root'u dikkatle sınırlandırın; local gereksinimi, yani database ve ayarlar için ayrı bir kalıcı path'i doğrulayın; ardından şu doğrulamayı çalıştırın: kısıtlı bir kullanıcı oluşturun, dosya yükleyip yeniden adlandırın, metin düzenleyin, bir paylaşım oluşturun ve kullanıcının kendisine atanmış root dizininin dışına çıkamadığını doğrulayın. Sonucu bir deployment check olarak saklayın; böylece bir sonraki image update'i container status'una göre değil, davranışa göre değerlendirilir.

Sık sorulan sorular

Production deployment için File Browser'ın neye ihtiyacı vardır?

File Browser container'ını port 80 üzerinden tek bir HTTPS origin'e route edin. Local runtime gereksinimi, database'i ve ayarları için ayrı bir kalıcı path'tir. Kısıtlı bir kullanıcı oluşturabildiğinizi, dosya yükleyip yeniden adlandırabildiğinizi, metin düzenleyebildiğinizi, bir paylaşım oluşturabildiğinizi ve kullanıcının kendisine atanmış root dizininin dışına çıkamadığını doğrulayamadığınız sürece File Browser'ı hazır kabul etmeyin.

Hangi File Browser verileri backup'a dahil edilmelidir?

/srv yolunu kalıcı hâle getirin ve sunulan dosyalar ile File Browser database ve ayarlarını aynı recovery manifest'ine dahil edin. Temiz bir File Browser restore'u yalnızca sunulan dosyalar, kullanıcılar, scope'lar, paylaşımlar ve ayarlar geri geldiğinde ve kısıtlı bir hesabın sınırları içinde kaldığı doğrulandığında başarılıdır.

Reverse proxy arkasında File Browser için HTTPS gerekir mi?

Public File Browser origin'i için HTTPS kullanın ve port 80'i internal route üzerinde tutun. File Browser ayarını doğru uygulayın: UI'ı HTTPS üzerinden yayınlayın, ancak sunulan root'u dikkatle sınırlandırın. File Browser için HTTPS, credential'ları veya kullanıcı içeriğini aktarım sırasında korur ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

File Browser upgrade'i nasıl test edilmelidir?

Mevcut File Browser state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. File Browser database ve settings migration'ları önemli olduğu için özellikle dikkatli olun; sunulan dosyalar ayrı bir mount'ta bulunsa bile bu durum geçerlidir. Data-migration ve rollback sınırları anlaşılana kadar önceki File Browser image'ını saklayın.