Så driftar du Stirling PDF själv 2026: uppladdningar, OCR och inloggningssäkerhet

Det finns två versioner av att ”köra Stirling PDF”: antingen finns en container, eller så utför tjänsten faktiskt sitt jobb. Det är bara det senare som spelar roll. Här är beviset att slå ihop två PDF-filer, köra OCR på en skannad sida, komprimera resultatet och verifiera uppladdnings- och nedladdningsbeteendet via den publika proxyn.

Stirling PDF fyller detta syfte: ett web interface och API för vanliga PDF-operationer. Driftsättningen måste bevara delarna bakom det beteendet; en port, en volym och ett certifikat är indata, inte resultatet.

Containerinställningar som är värda att granska

Den första containern ska vara enkel att ta bort och skapa på nytt. Håll data borta från det skrivbara lagret, bind port 8080 endast där proxyn kan nå den och skicka in konfigurationen vid runtime.

docker run -d \
  --name stirling-pdf \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v stirling-pdf-data:/configs \
  -e SECURITY_ENABLELOGIN=true \
  stirlingtools/stirling-pdf:latest

Lås image-versionen efter det första testet. Läs det tidigaste startup-felet i stället för det sista omstartsmeddelandet, verifiera varje mount med docker inspect och följ loggarna medan du slår ihop två PDF-filer, kör OCR på en skannad sida, komprimerar resultatet och verifierar uppladdnings- och nedladdningsbeteendet via den publika proxyn. Den sekvensen skiljer ett felaktigt image-kommando från ett beroende- eller behörighetsproblem.

Definiera först vad som räknas som lyckat för Stirling PDF

Dela upp fyra områden för Stirling PDF: ingress, lyssnaren på 8080, persistent state samt supporting services eller lokal kapacitet. Det lokala runtime-kravet är valfria OCR language data och tillräckligt med temporärt diskutrymme för stora jobb. Dokumentera det bredvid image och port så att en ersättningshost får samma lokala kapacitet.

Kör den kända fungerande transaktionen — slå ihop två PDF-filer, kör OCR på en skannad sida, komprimera resultatet och verifiera uppladdnings- och nedladdningsbeteendet via den publika proxyn — innan du betraktar separationen som klar. Mät temporärt diskutrymme, OCR language packs, JVM-minne och samtidiga konverteringsjobb och spara resultatet tillsammans med deployment-dokumentationen. Det ger både ett acceptanskriterium och den första kapacitetsbaslinjen.

Lås ner Stirling PDF efter bootstrap

Den applikationsspecifika säkerhetsrisken är att lämna säkerheten avstängd på en publik dokumentbearbetningstjänst. Det operativa svaret är att aktivera login för en internetvänd instans och undvika att behålla uppladdade dokument längre än jobbet kräver. Slutför bootstrap via en begränsad route och ta omedelbart bort tillfällig setup-åtkomst efteråt.

SECURITY_ENABLELOGIN styr beteendet, inte konfidentialiteten; validera dess typ och värde och lagra riktiga Stirling PDF-credentials separat. Ge Stirling PDF-processen endast dess dokumenterade mounts och dependency routes; undvik åtkomst till hostens root och Docker socket. Logga misslyckade autentiseringar och konfigurationsfel, men redigera bort tokens, connection strings och användarinnehåll.

Ge Stirling PDF en enda kanonisk adress

Webbläsaren, API-klienten och Stirling PDF måste vara överens om en enda origin. För att uppnå det ställer du in den publika HTTPS-origin och proxyns uppladdningsgränser. Bevara den ursprungliga hosten och protokollet samtidigt som port 8080 hålls otillgänglig som en konkurrerande publik adress.

Guiden för felsökning när webbplatsen är nere hjälper dig skilja en oåtkomlig route från en applikation som svarar. Den skillnaden är viktig här: uppladdningar överskrider proxyns gräns eller så kan containern inte skriva temporära filer. Endast det första åtgärdas genom ändringar i ingressen; det senare kräver granskning av Stirling PDF-loggar, state eller workload.

Separera utbytbara containers från bestående data

Den beständiga återställningsmängden består av konfiguration, custom files och eventuell OCR-data som du medvetet har installerat. Moun­ta /configs före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är persistent. En volym skyddar data mot att containern ersätts, men inte mot att hosten går förlorad, oavsiktlig radering eller korruption på applikationsnivå.

Ta backuper som förstår datakällan: använd logical dumps för aktiva databaser när det behövs och kopiera filer endast från ett konsistent state. Förvara en krypterad kopia utanför Stirling PDF-hosten. Acceptanskriteriet för en restore är specifikt — konfiguration och OCR-assets ska återställas och ett fast testdokument ska ge ett godtagbart, läsbart resultat. Guiden för restore-testade backuper förklarar varför enbart ett lyckat jobb inte räcker.

Bevis att samla in innan Stirling PDF går live

För Stirling PDF ska du definiera en känd fungerande transaktion före lanseringen: slå ihop två PDF-filer, kör OCR på en skannad sida, komprimera resultatet och verifiera uppladdnings- och nedladdningsbeteendet via den publika proxyn. Lägg dess förutsättningar, förväntade svar och cleanup-steg i version control utan secret-värden. Lås den image som användes för att skapa denna referens.

Använd transaktionen för att validera en ersättning och en oberoende restore. Den återställda tjänsten är godkänd först när konfiguration och OCR-assets återställs och ett fast testdokument ger ett godtagbart, läsbart resultat. Observera samtidigt temporärt diskutrymme, OCR language packs, JVM-minne och samtidiga konverteringsjobb och gör den långsammaste eller mest begränsande delen till en service-level alert.

Gaten behöver också ett negativt testfall: skicka ofarlig input nära den resurs- eller formatgräns som hör till denna gräns: uppladdningar överskrider proxyns gräns eller så kan containern inte skriva temporära filer. Bekräfta att Stirling PDF genererar ett användbart fel samtidigt som data bevaras, återställ det giltiga tillståndet och kör den kända fungerande transaktionen igen. Genom att behålla båda resultaten förhindrar du att en ytlig health endpoint blir det enda produktionsbeviset.

Drifta Stirling PDF utifrån den verkliga flaskhalsen

Observera det arbete som Stirling PDF utför: temporärt diskutrymme, OCR language packs, JVM-minne och samtidiga konverteringsjobb. Sätt limits med marginal för detta arbete och undvik en liveness probe som konkurrerar om resurserna. Operator-kontrollen ska fortfarande försöka slå ihop två PDF-filer, köra OCR på en skannad sida, komprimera resultatet och verifiera uppladdnings- och nedladdningsbeteendet via den publika proxyn enligt ett schema.

Inför uppdateringar ska du komma ihåg att installerad OCR-data, custom configuration och security settings bör jämföras före en image-uppgradering. Driftsätt kandidaten mot en återställd kopia och kör det kända testet igen. Om uppladdningar överskrider proxyns gräns eller containern inte kan skriva temporära filer använder du runtime-loggar och den faktiska nätverksbegäran för att hitta vilket antagande som har ändrats.

Driftsätt Stirling PDF på Dockup utan att förlora gränserna

Dockup tar bort manuellt arbete med reverse proxy och lifecycle runt Stirling PDF. Tjänsten får en stabil HTTPS-route till 8080, injicerad konfiguration och persistent storage när containers ersätts. En ansluten kundserver följer samma modell som Dockup-hostad compute.

Efter lanseringen ska du uppfylla applikationskontraktet: ställ in den publika HTTPS-origin och proxyns uppladdningsgränser, bekräfta det lokala kravet — valfria OCR language data och tillräckligt med temporärt diskutrymme för stora jobb — och kör detta bevis: slå ihop två PDF-filer, kör OCR på en skannad sida, komprimera resultatet och verifiera uppladdnings- och nedladdningsbeteendet via den publika proxyn. Det gör one-click-upplevelsen användbar utan att förenkla bort detaljerna som gör Stirling PDF återställningsbart och säkert.

Vanliga frågor

Vad behöver Stirling PDF för en produktionsdriftsättning?

Routa Stirling PDF-containern på port 8080 via en enda HTTPS-origin. Det lokala runtime-kravet är valfria OCR language data och tillräckligt med temporärt diskutrymme för stora jobb. Säg inte att Stirling PDF är redo förrän du kan slå ihop två PDF-filer, köra OCR på en skannad sida, komprimera resultatet och verifiera uppladdnings- och nedladdningsbeteendet via den publika proxyn.

Vilka Stirling PDF-data ska ingå i en backup?

Gör /configs persistent och inkludera konfiguration, custom files och eventuell OCR-data som du medvetet har installerat i samma recovery manifest. En ren Stirling PDF-restore är godkänd först när konfiguration och OCR-assets återställs och ett fast testdokument ger ett godtagbart, läsbart resultat.

Kräver Stirling PDF HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Stirling PDF-origin och behåll port 8080 på den interna routen. Tillämpa Stirling PDF-inställningen korrekt: ställ in den publika HTTPS-origin och proxyns uppladdningsgränser. För Stirling PDF skyddar HTTPS credentials och användarinnehåll under överföring och ser till att origin-känsligt klientbeteende förblir konsekvent.

Hur ska en uppgradering av Stirling PDF testas?

Återställ aktuell Stirling PDF-state i en isolerad deployment, tillämpa kandidatversionen och kör dess acceptanstransaktion igen. Var särskilt uppmärksam eftersom installerad OCR-data, custom configuration och security settings bör jämföras före en image-uppgradering. Behåll den tidigare Stirling PDF-imagen tills gränserna för datamigrering och rollback är klarlagda.