PicoShare'ı 2026'da Self-Host Etme: Upload'lar, Paylaşılan Secret'lar ve Storage

PicoShare'ı self-host etmenin asıl değeri ilk docker run komutunda değil, ilk redeploy sonrasında ortaya çıkar. Upload'lar proxy limitlerine takıldığında veya ephemeral /data path'i nedeniyle dosyalar kaybolduğunda Docker yine de process'in tamamen sağlıklı olduğunu bildirebilir. Aşağıdaki deployment, gözlemlenebilir davranışlar etrafında tasarlanmıştır: bir dosya upload edin, fresh bir browser'dan indirin, expiration veya deletion'ı test edin ve seçilen size limitine yakın bir dosyayla yeniden deneyin.

PicoShare'ın amacı nettir: upload'ları link'lere dönüştüren minimal file sharing. Bu tanım, nelerin public kalması, nelerin private tutulması ve bir backup'ın neleri yeniden oluşturması gerektiğini gösterir.

PicoShare recovery sürecini ölçülebilir hâle getirin

PicoShare için bir recovery manifest'i oluşturun: /data içindeki upload edilmiş dosyalar ve PicoShare metadata'sı. Bootstrap işleminden önce /data'yı mount edin, zararsız sample data yazın ve path'in gerçekten persistent olduğunu kanıtlamak için container'ı değiştirin. Ownership ve boş disk alanını şimdiden kontrol edin; çünkü mount edilmiş ancak yazılamayan bir path, hiç persistence yokmuş gibi davranır.

Backup'ı çalışan server'dan ayrı bir failure domain'a alın. PicoShare'ı pin'lenmiş image'ından yeniden oluşturun ve upload edilmiş byte'ların ve metadata'nın geri geldiğini; mevcut link'lerden bir örneğin eşleşen hash'lere sahip dosyaları indirdiğini doğrulayın. Persistent volume rehberi, bu çalışmayı snapshot ve retention policy'ye dönüştürmenize yardımcı olur.

PicoShare'ın production yapısı

PicoShare HTTP process'i 4001 portunu dinler; bu portu application network'te tutun ve yalnızca platform route'unu publish edin. Local runtime requirement, durable bir data volume ve retained file'lar için yeterli disk alanıdır. Bu bilgileri image default'una bırakmak yerine beklenen capacity'yi, ownership'i ve failure mode'u dokümante edin.

Sınırı kısa bir contract olarak yazın: requirement'ın sahibi kim, hangi credential kullanılıyor, kabul edilebilir timeout nedir ve failure nasıl görünür? Ardından şu transaction'ı çalıştırın: bir dosya upload edin, fresh bir browser'dan indirin, expiration veya deletion'ı test edin ve seçilen size limitine yakın bir dosyayla yeniden deneyin. Çalışma sırasında disk capacity'yi, upload bandwidth'ini, proxy body limit'lerini ve concurrent download'ları gözlemleyin; çünkü bu workload, idle bir container'dan daha kullanışlı bir başlangıç boyutu sağlar.

PicoShare release gate'i

PicoShare smoke test'ini tekrarlanabilir bir release command'ına veya kısa bir runbook'a dönüştürün. Çıktısı şu sonucu kanıtlamalıdır: bir dosya upload edin, fresh bir browser'dan indirin, expiration veya deletion'ı test edin ve seçilen size limitine yakın bir dosyayla yeniden deneyin. Sonuçla birlikte application version'ı, container digest'ini, route hostname'ini ve test-data identifier'ını kaydedin.

Aynı kontrolü rutin bir container değişiminden sonra ve upload edilmiş dosyalarla /data içindeki PicoShare metadata'sını başka bir yerde restore ettikten sonra çalıştırın. Restore işlemi, upload edilmiş byte'lar ve metadata geri geldiğinde ve mevcut link'lerden bir örnek eşleşen hash'lere sahip dosyaları indirdiğinde başarılıdır. Disk capacity, upload bandwidth, proxy body limits ve concurrent downloads ile ilgili timing ve consumption değerlerini karşılaştırın; final action hâlâ başarılı olsa bile büyük bir değişiklik incelenmeye değerdir.

Ardından güvenli bir failure senaryosu çalıştırın: şu boundary ile ilişkili resource veya format limitine yakın, zararsız bir input gönderin: upload'lar proxy limitlerine takılıyor veya dosyalar ephemeral /data path'i nedeniyle kayboluyor. PicoShare'ın fault'u görünür hâle getirdiğini ve destructive manual edit'ler olmadan normale döndüğünü doğrulayın. Yalnızca gerekli, redacted log excerpt'ini saklayın. Bu dört parçalı gate; startup, persistence, recovery ve failure handling'i kapsar.

İncelenmeye değer container ayarları

PicoShare'ı, bootstrap tamamlanana kadar route'u private bırakacak şekilde başlatın.

docker run -d \
  --name picoshare \
  --restart unless-stopped \
  -p 127.0.0.1:4001:4001 \
  -v picoshare-data:/data \
  -e PS_SHARED_SECRET=replace-with-a-long-random-value \
  mtlynch/picoshare:latest

Process loop'a girerse image'ın beklediği user ile mount edilen her path'in owner'ını karşılaştırın. Process çalışır durumda kalırsa 4001 portunu local olarak test edin ve ardından doğrudan workflow'a geçin: bir dosya upload edin, fresh bir browser'dan indirin, expiration veya deletion'ı test edin ve seçilen size limitine yakın bir dosyayla yeniden deneyin. Image'ı version-pin işlemini ancak bu end-to-end check başarılı olduktan sonra yapın ve tam configuration'ı service'in yanında kaydedin.

PicoShare'ın sahip olduğu authority'yi azaltın

Bootstrap credential'ları geçicidir; trust model ise kalıcıdır. PicoShare kullanırken guessable bir shared secret kullanmamaya ve unlimited anonymous storage sunmamaya dikkat edin; uzun bir shared secret kullanın, upload'lara rate limit uygulayın ve service'i anonymous unlimited storage'a dönüştürmeyin.

Örnek PS_SHARED_SECRET değerini hemen değiştirin, image'ın dışında saklayın ve açığa çıkarsa administrator credential'ı gibi rotate edin. Image'ı gereksiz Linux capability'leri olmadan çalıştırın ve yalnızca public application route'unu expose edin. Secret değerlerini kaydetmeden administrator activity'sini görünür tutun.

PicoShare route'unu HTTPS konusunda yanıltıcı olmayacak şekilde yapılandırın

PicoShare için temporary ve permanent public origin'lerden kaçının. Bunun yerine tek bir HTTPS origin publish edin ve proxy'yi beklenen upload'lar için uygun boyutlandırın; seçtiğiniz DNS name'i platform route'una yönlendirin ve yalnızca 4001 portuna proxy yapın.

Bu action'ı host'un dışından çalıştırın: bir dosya upload edin, fresh bir browser'dan indirin, expiration veya deletion'ı test edin ve seçilen size limitine yakın bir dosyayla yeniden deneyin. Ingress başarısız olursa 502 troubleshooting rehberi, port ve listener hatalarını ele alır. PicoShare request'i alıyor ancak upload'lar proxy limitlerine takılıyor veya dosyalar ephemeral /data path'i nedeniyle kayboluyorsa kanıt artık proxy'nin ötesini gösterir.

Capacity ve upgrade kontrolleri

Idle bir health check, PicoShare hakkında çok az bilgi verir. Disk capacity'yi, upload bandwidth'ini, proxy body limit'lerini ve concurrent download'ları izleyin; ardından kullanıcıların deneyimlediği belirti için alert oluşturun: “bir dosya upload et, fresh bir browser'dan indir, expiration veya deletion'ı test et ve seçilen size limitine yakın bir dosyayla yeniden dene” action'ının başarısız olması. Liveness'ı local ve ucuz tutun; readiness, restart storm'a neden olmadan migration veya initialization durumunu bildirsin.

Riskli upgrade alanı şudur: link yalnızca her ikisi de uyumlu olduğu sürece işe yaradığından, upgrade öncesinde PicoShare metadata'sı ve file layout'u kontrol edilmelidir. Release notes'u okuyun, state'in snapshot'ını alın, target version'ı restore edilmiş bir copy üzerinde deploy edin ve acceptance action'ı tekrarlayın. Upload'lar proxy limitlerine takılıyor veya dosyalar ephemeral /data path'i nedeniyle kayboluyorsa client request'ini ilk ilgili application log'u ile ilişkilendirin; state'i silmeyin veya gelişigüzel redirect eklemeyin.

Sınırlarını kaybetmeden PicoShare'ı Dockup üzerinde deploy edin

Dockup, PicoShare çevresindeki manual reverse-proxy ve lifecycle işlerini ortadan kaldırır. Service, replacement işlemleri sırasında 4001'e yönlenen stable bir HTTPS route, injected configuration ve persistent storage alır. Attached customer server, Dockup-hosted compute ile aynı modeli izler.

Launch sonrasında application contract'ı karşılayın: tek bir HTTPS origin publish edin ve proxy'yi beklenen upload'lar için uygun boyutlandırın; local requirement'ı — durable bir data volume ve retained file'lar için yeterli disk alanını — doğrulayın ve şu proof'u çalıştırın: bir dosya upload edin, fresh bir browser'dan indirin, expiration veya deletion'ı test edin ve seçilen size limitine yakın bir dosyayla yeniden deneyin. Böylece tek tıklamalı deneyim, PicoShare'ı recoverable ve secure yapan ayrıntılar göz ardı edilmeden kullanışlı kalır.

Sık sorulan sorular

Production deployment için PicoShare'ın neye ihtiyacı var?

PicoShare container'ını 4001 portu üzerinden tek bir HTTPS origin'e route edin. Local runtime requirement, durable bir data volume ve retained file'lar için yeterli disk alanıdır. Bir dosya upload edemiyor, fresh bir browser'dan indiremiyor, expiration veya deletion'ı test edemiyor ya da seçilen size limitine yakın bir dosyayla yeniden deneyemiyorsanız PicoShare'ı hazır kabul etmeyin.

PicoShare'ın hangi verileri backup'a dahil edilmeli?

/data'yı persist edin ve upload edilmiş dosyalarla /data içindeki PicoShare metadata'sını aynı recovery manifest'ine dahil edin. Temiz bir PicoShare restore işlemi, yalnızca upload edilmiş byte'lar ve metadata geri geldiğinde ve mevcut link'lerden bir örnek eşleşen hash'lere sahip dosyaları indirdiğinde başarılıdır.

PicoShare reverse proxy arkasında HTTPS gerektirir mi?

Public PicoShare origin'i için HTTPS kullanın ve 4001 portunu internal route'ta tutun. PicoShare ayarını doğru uygulayın: tek bir HTTPS origin publish edin ve proxy'yi beklenen upload'lar için uygun boyutlandırın. PicoShare için HTTPS, credential'ları veya user content'i transit sırasında korur ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

PicoShare upgrade'i nasıl test edilmeli?

Mevcut PicoShare state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. PicoShare metadata'sı ve file layout'u upgrade öncesinde kontrol edilmelidir; çünkü link yalnızca her ikisi de uyumlu olduğu sürece işe yarar. Data-migration ve rollback sınırları anlaşılana kadar önceki PicoShare image'ını saklayın.