Så självhostar du PicoShare 2026: uppladdningar, delade hemligheter och lagring

Det är vid den första omdistributionen, inte vid den första docker run, som det blir intressant att självhosta PicoShare. Om uppladdningar stöter på proxybegränsningar eller filer försvinner när /data-sökvägen är ephemeral kan Docker fortfarande rapportera en helt frisk process. Distributionen nedan är organiserad kring observerbart beteende: ladda upp en fil, ladda ner den från en ny webbläsare, testa att den löper ut eller raderas och försök igen med en fil nära den valda storleksgränsen.

PicoShares avsedda uppgift är tydlig: minimal fildelning som omvandlar uppladdningar till länkar. Den beskrivningen visar vad som måste vara publikt, vad som bör förbli privat och vad en säkerhetskopia måste kunna återskapa.

Gör återställning av PicoShare mätbar

Skapa ett återställningsmanifest för PicoShare: uppladdade filer och PicoShare-metadata i /data. Montera /data före bootstrap, skriv ofarliga testdata och ersätt containern för att bevisa att sökvägen faktiskt är persistent. Kontrollera ägarskap och ledigt utrymme nu, eftersom en monterad men skrivskyddad sökväg i praktiken inte ger någon persistence alls.

Säkerhetskopiera till en felzon som är separat från den server som kör tjänsten. Återskapa PicoShare från den pinnade imagen och verifiera att uppladdade bytes och metadata återkommer samt att ett urval av befintliga länkar laddar ner filer med matchande hashvärden. Guiden om persistent volym hjälper dig att omsätta övningen i en policy för snapshots och retention.

PicoShares produktionsform

PicoShares HTTP-process lyssnar på 4001. Behåll den porten i applikationsnätverket och publicera endast plattformsrutten. Det lokala runtime-kravet är en persistent datavolym och tillräckligt med diskutrymme för filer som ska behållas. Dokumentera förväntad kapacitet, ägarskap och felbeteende i stället för att lämna detta till imagens standardinställningar.

Skriv ner gränsen som ett kort kontrakt: vem som äger kravet, vilken credential som används, vilken timeout som är acceptabel och hur ett fel visar sig. Kör sedan denna transaktion: ladda upp en fil, ladda ner den från en ny webbläsare, testa att den löper ut eller raderas och försök igen med en fil nära den valda storleksgränsen. Observera diskutrymme, uppladdningsbandbredd, proxyns body limits och samtidiga nedladdningar under körningen, eftersom den belastningen ger en bättre utgångspunkt för dimensionering än en inaktiv container.

PicoShares release gate

Gör om PicoShares smoke test till ett repeterbart release-kommando eller en kort runbook. Resultatet måste visa följande: ladda upp en fil, ladda ner den från en ny webbläsare, testa att den löper ut eller raderas och försök igen med en fil nära den valda storleksgränsen. Registrera applikationsversion, container-digest, routens hostname och testdataidentifierare tillsammans med resultatet.

Kör samma kontroll efter ett vanligt containerbyte och efter att uppladdade filer och PicoShare-metadata i /data har återställts någon annanstans. Återställningen har lyckats när uppladdade bytes och metadata återkommer samt ett urval av befintliga länkar laddar ner filer med matchande hashvärden. Jämför tidsåtgång och förbrukning kopplad till diskutrymme, uppladdningsbandbredd, proxyns body limits och samtidiga nedladdningar. En stor förändring är värd att undersöka även när det avslutande steget fortfarande lyckas.

Testa sedan ett säkert fel: skicka ofarlig input nära den resurs- eller formatgräns som hör till den här gränsen: uppladdningar stöter på proxybegränsningar eller filer försvinner när /data-sökvägen är ephemeral. Bekräfta att PicoShare visar felet och återgår till normalt läge utan destruktiva manuella ändringar. Spara endast det nödvändiga, redigerade loggutdraget. Den här fyrdelade gaten täcker uppstart, persistence, återställning och felhantering.

Containerinställningar som är värda att granska

Starta PicoShare på ett sätt som håller rutten privat tills bootstrap är klart.

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

Om processen startar om i en loop, jämför imagens förväntade användare med ägaren för varje monterad sökväg. Om den fortsätter köra, testa port 4001 lokalt och gå sedan direkt vidare till arbetsflödet: ladda upp en fil, ladda ner den från en ny webbläsare, testa att den löper ut eller raderas och försök igen med en fil nära den valda storleksgränsen. Pinnas versionen av imagen först efter att den här end-to-end-kontrollen har lyckats, och dokumentera den exakta konfigurationen bredvid tjänsten.

Begränsa de behörigheter PicoShare har

Bootstrap-credentials är tillfälliga, men trust-modellen är permanent. Med PicoShare bör du se upp med att använda en gissningsbar delad hemlighet eller erbjuda obegränsad anonym lagring. Använd i stället en lång delad hemlighet, rate-limita uppladdningar och undvik att göra tjänsten till anonym lagring utan begränsningar.

Ersätt exempelvärdet för PS_SHARED_SECRET omedelbart, lagra det utanför imagen och rotera det som en administratörscredential om det exponeras. Kör imagen utan onödiga Linux-capabilities och exponera endast den publika applikationsrutten. Se till att administratörsaktivitet är synlig utan att hemliga värden loggas.

Dirigera PicoShare utan att ge en falsk bild av HTTPS

Undvik tillfälliga och permanenta publika origins för PicoShare. Publicera i stället en HTTPS-origin, dimensionera proxyn för förväntade uppladdningar, peka det valda DNS-namnet mot plattformsrutten och proxya endast till port 4001.

Testa detta utifrån, från en plats utanför värden: ladda upp en fil, ladda ner den från en ny webbläsare, testa att den löper ut eller raderas och försök igen med en fil nära den valda storleksgränsen. Om ingress misslyckas beskriver guiden för felsökning av 502 vanliga port- och listenerfel. Om PicoShare tar emot begäran men uppladdningar stöter på proxybegränsningar eller filer försvinner när /data-sökvägen är ephemeral, pekar bevisen nu bortom proxyn.

Kapacitet och uppgraderingskontroller

En inaktiv health check säger inte mycket om PicoShare. Övervaka diskutrymme, uppladdningsbandbredd, proxyns body limits och samtidiga nedladdningar. Larma sedan på det symptom som användarna upplever: att åtgärden ”ladda upp en fil, ladda ner den från en ny webbläsare, testa att den löper ut eller raderas och försök igen med en fil nära den valda storleksgränsen” misslyckas. Håll liveness lokal och billig; låt readiness rapportera migreringar eller initialisering utan att orsaka en restart storm.

Det riskfyllda vid en uppgradering är att PicoShares metadata och fillayout måste kontrolleras före uppgraderingen, eftersom länken bara är användbar så länge de båda överensstämmer. Läs release notes, ta en snapshot av tillståndet, distribuera målversionen mot en återställd kopia och upprepa acceptanstestet. Om uppladdningar stöter på proxybegränsningar eller filer försvinner när /data-sökvägen är ephemeral, korrelera klientbegäran med den första relevanta applikationsloggen i stället för att radera tillstånd eller lägga till redirects på måfå.

Distribuera PicoShare på Dockup utan att förlora gränserna

Dockup tar bort manuellt arbete med reverse proxy och livscykelhantering runt PicoShare. Tjänsten får en stabil HTTPS-rutt till 4001, injicerad konfiguration och persistent lagring vid byten. En ansluten kundserver följer samma modell som Dockup-hostad compute.

Efter lanseringen ska du uppfylla applikationskontraktet: publicera en HTTPS-origin, dimensionera proxyn för förväntade uppladdningar, bekräfta det lokala kravet — en persistent datavolym och tillräckligt med diskutrymme för filer som ska behållas — och kör detta test: ladda upp en fil, ladda ner den från en ny webbläsare, testa att den löper ut eller raderas och försök igen med en fil nära den valda storleksgränsen. Då förblir one-click-upplevelsen användbar utan att detaljerna som gör PicoShare återställningsbart och säkert suddas ut.

Vanliga frågor

Vad behöver PicoShare för en produktionsdistribution?

Dirigera PicoShare-containern på port 4001 via en HTTPS-origin. Det lokala runtime-kravet är en persistent datavolym och tillräckligt med diskutrymme för filer som ska behållas. Förklara inte PicoShare som redo förrän du kan ladda upp en fil, ladda ner den från en ny webbläsare, testa att den löper ut eller raderas och försöka igen med en fil nära den valda storleksgränsen.

Vilka PicoShare-data ska ingå i en säkerhetskopia?

Spara /data persistent och inkludera uppladdade filer och PicoShare-metadata i /data i samma återställningsmanifest. En ren PicoShare-återställning är godkänd först när uppladdade bytes och metadata återkommer samt ett urval av befintliga länkar laddar ner filer med matchande hashvärden.

Kräver PicoShare HTTPS bakom en reverse proxy?

Använd HTTPS för den publika PicoShare-originen och behåll port 4001 på den interna rutten. Tillämpa PicoShare-inställningen korrekt: publicera en HTTPS-origin och dimensionera proxyn för förväntade uppladdningar. För PicoShare skyddar HTTPS credentials eller användarinnehåll under överföring och gör klientbeteende som är känsligt för origin konsekvent.

Hur bör en PicoShare-uppgradering testas?

Återställ aktuellt PicoShare-tillstånd i en isolerad distribution, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom PicoShares metadata och fillayout måste kontrolleras före en uppgradering, eftersom länken bara är användbar så länge de båda överensstämmer. Behåll den tidigare PicoShare-imagen tills gränserna för datamigrering och rollback är kända.