Slik selvhoster du Stirling PDF i 2026: opplastinger, OCR og sikker innlogging

Det finnes to versjoner av «å kjøre Stirling PDF»: Enten finnes det en container, eller så utfører tjenesten den faktiske jobben sin. Det er bare den siste som betyr noe. Her er beviset å slå sammen to PDF-filer, kjøre OCR på en skannet side, komprimere resultatet og kontrollere hvordan opplasting og nedlasting fungerer gjennom den offentlige proxyen.

Stirling PDF er laget for dette: et webgrensesnitt og et API for vanlige PDF-operasjoner. Distribusjonen må ta vare på delene som ligger bak denne funksjonaliteten; en port, et volum og et sertifikat er forutsetninger, ikke resultatet.

Containerinnstillinger det er verdt å gjennomgå

Den første containeren bør være enkel å slette og opprette på nytt. Hold data utenfor det skrivbare laget, bind port 8080 bare der proxyen kan nå den, og send inn konfigurasjon ved 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-versjonen etter den første testen. Les den tidligste oppstartsfeilen i stedet for den siste omstarts­meldingen, kontroller hvert mount med docker inspect, og følg loggene mens du slår sammen to PDF-filer, kjører OCR på en skannet side, komprimerer resultatet og kontrollerer hvordan opplasting og nedlasting fungerer gjennom den offentlige proxyen. Denne sekvensen skiller en feil i image-kommandoen fra et problem med avhengigheter eller tillatelser.

Definer først hva som betyr at Stirling PDF fungerer

Skill mellom fire områder for Stirling PDF: ingress, lytteren på 8080, persistent state og støttetjenester eller lokal kapasitet. Det lokale runtime-kravet er valgfrie OCR-språkdata og nok midlertidig diskplass til store jobber. Dokumenter dette sammen med image og port, slik at en ny vert får samme lokale funksjonalitet.

Kjør den kjente gode transaksjonen — slå sammen to PDF-filer, kjør OCR på en skannet side, komprimer resultatet og kontroller hvordan opplasting og nedlasting fungerer gjennom den offentlige proxyen — før du anser denne separasjonen som fullført. Mål midlertidig diskplass, OCR-språkpakker, JVM-minne og antallet samtidige konverteringsjobber, og lagre resultatet sammen med distribusjonsdokumentasjonen. Det gir både et godkjenningskriterium og det første kapasitetsgrunnlaget.

Sikre Stirling PDF etter oppstart

Den applikasjonsspesifikke sikkerhetsrisikoen er å la sikkerhet være deaktivert på en offentlig dokumentbehandlingstjeneste. Det operative svaret er å aktivere innlogging for en internettrettet instans og unngå å beholde opplastede dokumenter lenger enn jobben krever. Fullfør førstegangsoppsettet gjennom en begrenset rute, og fjern midlertidig tilgang til oppsettet umiddelbart etterpå.

SECURITY_ENABLELOGIN styrer atferd, ikke konfidensialitet. Valider typen og verdien, og lagre faktiske Stirling PDF-legitimasjoner separat. Gi Stirling PDF-prosessen bare de dokumenterte mountene og avhengighetsrutene; unngå tilgang til hostens root og Docker-socketen. Loggfør mislykkede autentiseringsforsøk og konfigurasjonsfeil, men fjern tokens, connection strings og brukerinnhold fra loggene.

Gi Stirling PDF én kanonisk adresse

Nettleseren, API-klienten og Stirling PDF må være enige om én origin. For å oppnå dette må du angi den offentlige HTTPS-origin-en og grensene for proxy-opplastinger. Bevar den opprinnelige hosten og protokollen, samtidig som port 8080 ikke er tilgjengelig som en konkurrerende offentlig adresse.

Feilsøkingsveiledningen for når nettstedet er nede hjelper deg med å skille mellom en utilgjengelig rute og en applikasjon som svarer. Dette skillet er viktig her: Opplastinger overskrider proxygrensen, eller containeren kan ikke skrive midlertidige filer. Bare det første løses med endringer i ingressen; det andre krever gjennomgang av Stirling PDF-logger, state eller arbeidsbelastning.

Skill mellom utskiftbare containere og varige data

Det varige gjenopprettingssettet består av konfigurasjon, egendefinerte filer og eventuelle OCR-data du har installert med hensikt. Mount /configs før førstegangsoppsettet, skriv ufarlige eksempeldata, og bytt ut containeren for å bevise at banen faktisk er persistent. Et volum beskytter data mot at containeren byttes ut, men ikke mot tap av hosten, utilsiktet sletting eller korrupsjon på applikasjonsnivå.

Ta sikkerhetskopier som forstår datakilden: Bruk logiske dumper for aktive databaser ved behov, og kopier filer bare fra en konsistent state. Oppbevar én kryptert kopi utenfor Stirling PDF-hosten. Godkjenningskriteriet for en gjenoppretting må være konkret — konfigurasjon og OCR-ressurser skal komme tilbake, og et fast testdokument skal gi et akseptabelt og lesbart resultat. Veiledningen for sikkerhetskopier som er testet med gjenoppretting forklarer hvorfor vellykkede jobber alene ikke er tilstrekkelig.

Dokumentasjon du bør samle inn før Stirling PDF settes i produksjon

For Stirling PDF bør du definere en kjent god transaksjon før lansering: slå sammen to PDF-filer, kjør OCR på en skannet side, komprimer resultatet og kontroller hvordan opplasting og nedlasting fungerer gjennom den offentlige proxyen. Legg forutsetninger, forventet respons og oppryddingstrinn i versjonskontroll uten hemmelige verdier. Lås image-versjonen som ble brukt til å etablere referansen.

Bruk transaksjonen til å validere en erstatning og en uavhengig gjenoppretting. Den gjenopprettede tjenesten er bare godkjent når konfigurasjon og OCR-ressurser er tilbake, og et fast testdokument gir et akseptabelt og lesbart resultat. Følg samtidig med på midlertidig diskplass, OCR-språkpakker, JVM-minne og antallet samtidige konverteringsjobber, og gjør den tregeste eller mest begrensende delen om til et service level-varsel.

Kontrollen må også inneholde et negativt scenario: Send inn ufarlige data nær ressurs- eller formatgrensen som gjelder for denne grensen: Opplastinger overskrider proxygrensen, eller containeren kan ikke skrive midlertidige filer. Bekreft at Stirling PDF gir en handlingsrettet feilmelding samtidig som dataene bevares, gjenopprett den gyldige tilstanden, og kjør den kjente gode transaksjonen på nytt. Når begge resultatene beholdes, hindrer det at et overfladisk health-endepunkt blir det eneste produksjonsbeviset.

Driftssett Stirling PDF rundt den faktiske flaskehalsen

Følg med på arbeidet Stirling PDF utfører: midlertidig diskplass, OCR-språkpakker, JVM-minne og antallet samtidige konverteringsjobber. Sett grenser med nok margin til dette arbeidet, og unngå en liveness probe som konkurrerer med det. Operatørkontrollen bør fortsatt forsøke å slå sammen to PDF-filer, kjøre OCR på en skannet side, komprimere resultatet og kontrollere hvordan opplasting og nedlasting fungerer gjennom den offentlige proxyen etter en fast plan.

Ved oppdateringer må du huske at installerte OCR-data, egendefinert konfigurasjon og sikkerhetsinnstillinger bør sammenlignes før en image-oppgradering. Distribuer kandidaten mot en gjenopprettet kopi, og kjør den kjente testen på nytt. Hvis opplastinger overskrider proxygrensen, eller containeren ikke kan skrive midlertidige filer, kan du bruke runtime-logger og den faktiske nettverksforespørselen til å finne ut hvilken antakelse som er endret.

Distribuer Stirling PDF på Dockup uten å miste avgrensningene

Dockup fjerner manuelt arbeid med reverse proxy og livssyklus rundt Stirling PDF. Tjenesten får en stabil HTTPS-rute til 8080, injisert konfigurasjon og persistent lagring når containere byttes ut. En tilkoblet kundeserver følger samme modell som compute som hostes av Dockup.

Etter lansering må du oppfylle applikasjonskontrakten: angi den offentlige HTTPS-origin-en og grensene for proxy-opplastinger, bekreft det lokale kravet — valgfrie OCR-språkdata og nok midlertidig diskplass til store jobber — og kjør denne testen: slå sammen to PDF-filer, kjør OCR på en skannet side, komprimer resultatet og kontroller hvordan opplasting og nedlasting fungerer gjennom den offentlige proxyen. Slik forblir one-click-opplevelsen nyttig uten å skjule detaljene som gjør Stirling PDF mulig å gjenopprette og sikre.

Vanlige spørsmål

Hva trenger Stirling PDF for en produksjonsdistribusjon?

Rout Stirling PDF-containeren via port 8080 gjennom én HTTPS-origin. Det lokale runtime-kravet er valgfrie OCR-språkdata og nok midlertidig diskplass til store jobber. Ikke erklær Stirling PDF klar før du kan slå sammen to PDF-filer, kjøre OCR på en skannet side, komprimere resultatet og kontrollere hvordan opplasting og nedlasting fungerer gjennom den offentlige proxyen.

Hvilke Stirling PDF-data hører hjemme i en sikkerhetskopi?

Gjør /configs persistent, og ta med konfigurasjon, egendefinerte filer og eventuelle OCR-data du har installert med hensikt, i det samme gjenopprettingsmanifestet. En ren Stirling PDF-gjenoppretting er bare godkjent når konfigurasjon og OCR-ressurser er tilbake, og et fast testdokument gir et akseptabelt og lesbart resultat.

Krever Stirling PDF HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Stirling PDF-origin-en, og behold port 8080 på den interne ruten. Bruk Stirling PDF-innstillingen riktig: angi den offentlige HTTPS-origin-en og grensene for proxy-opplastinger. For Stirling PDF beskytter HTTPS legitimasjoner eller brukerinnhold under overføring og sørger for konsistent klientatferd som avhenger av origin.

Hvordan bør en Stirling PDF-oppgradering testes?

Gjenopprett den nåværende Stirling PDF-state-en i en isolert distribusjon, ta i bruk kandidatversjonen og kjør godkjenningstransaksjonen på nytt. Vær spesielt oppmerksom på at installerte OCR-data, egendefinert konfigurasjon og sikkerhetsinnstillinger bør sammenlignes før en image-oppgradering. Behold det forrige Stirling PDF-imaget til grensene for datamigrering og rollback er forstått.