Sådan selvhoster du Stirling PDF i 2026: uploads, OCR og login-sikkerhed

Der findes to versioner af at “køre Stirling PDF”: Der findes en container, eller også udfører servicen rent faktisk sin opgave. Kun den anden del er vigtig. Her er beviset at flette to PDF'er, køre OCR på en scannet side, komprimere resultatet og kontrollere upload- og downloadadfærden gennem den offentlige proxy.

Stirling PDF tjener dette formål: en webgrænseflade og API til almindelige PDF-operationer. Deploymentet skal bevare de dele, der ligger bag denne funktionalitet; en port, en volume og et certifikat er input, ikke resultatet.

Containerindstillinger, der er værd at gennemgå

Den første container skal være nem at slette og oprette igen. Hold data væk fra det skrivbare lag, bind kun port 8080 dér, hvor proxyen kan nå den, og send konfiguration ind 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

Fastlås image-versionen efter den indledende test. Læs den tidligste startup-fejl i stedet for den sidste genstartsmeddelelse, kontrollér hvert mount med docker inspect, og følg logs, mens du fletter to PDF'er, kører OCR på en scannet side, komprimerer resultatet og kontrollerer upload- og downloadadfærden gennem den offentlige proxy. Denne rækkefølge skelner mellem en forkert image-kommando og et problem med en afhængighed eller tilladelser.

Definér først, hvornår Stirling PDF fungerer

Adskil fire områder for Stirling PDF: ingress, lytteren på port 8080, persistent state og understøttende services eller lokal kapacitet. Det lokale runtime-krav er valgfri OCR-sprogdata og tilstrækkelig midlertidig diskplads til store jobs. Registrér det sammen med image og port, så en erstatningshost får de samme lokale funktioner.

Kør den kendte, velfungerende transaktion — flet to PDF'er, kør OCR på en scannet side, komprimér resultatet og kontrollér upload- og downloadadfærden gennem den offentlige proxy — før du betragter adskillelsen som afsluttet. Mål midlertidig diskplads, OCR-sprogpakker, JVM-hukommelse og samtidige konverteringsjobs, og gem resultatet sammen med deploymentregistreringen. Det giver både et acceptkriterium og det første kapacitetsbaseline.

Lås Stirling PDF efter bootstrap

Den applikationsspecifikke sikkerhedsrisiko er at lade sikkerheden være deaktiveret på en offentlig dokumentbehandlingsservice. Den operationelle løsning er at aktivere login for en internetvendt instans og undgå at opbevare uploadede dokumenter længere end nødvendigt for jobbet. Gennemfør bootstrap via en begrænset route, og fjern midlertidig setup-adgang umiddelbart derefter.

SECURITY_ENABLELOGIN styrer adfærden, ikke fortroligheden; validér dens type og værdi, og opbevar ægte Stirling PDF-legitimationsoplysninger separat. Giv Stirling PDF-processen kun de dokumenterede mounts og dependency-routes; undgå adgang til hostens root og Docker-socket. Log mislykkede autentificeringer og konfigurationsfejl, men redigér tokens, connection strings og brugerindhold.

Giv Stirling PDF én kanonisk adresse

Browseren, API-klienten og Stirling PDF skal være enige om én origin. For at opnå det skal du angive den offentlige HTTPS-origin og proxyens uploadgrænser. Bevar den oprindelige host og protokol, og sørg samtidig for, at port 8080 ikke er tilgængelig som en konkurrerende offentlig adresse.

Fejlfindingsguiden til et site, der er nede hjælper med at skelne mellem en utilgængelig route og en applikation, der svarer. Den skelnen er vigtig her: Uploads overskrider proxyens grænse, eller containeren kan ikke skrive midlertidige filer. Kun det første problem løses med ændringer i ingressen; det andet kræver inspektion af Stirling PDF-logs, state eller workload.

Adskil udskiftelige containere fra varige data

Det varige recovery-sæt består af konfiguration, custom-filer og eventuelle OCR-data, du bevidst har installeret. Mount /configs før bootstrap, skriv ufarlige eksempeldata, og erstat containeren for at bevise, at stien faktisk er persistent. En volume beskytter data mod udskiftning af containeren, men ikke mod tab af hosten, utilsigtet sletning eller korruption på applikationsniveau.

Tag backups, der forstår datakilden: Brug logiske dumps til live-databaser, når det er nødvendigt, og kopiér kun filer fra en konsistent state. Opbevar én krypteret kopi væk fra Stirling PDF-hosten. Acceptkriteriet for en restore er specifikt — konfiguration og OCR-aktiver skal gendannes, og et fast testdokument skal give et acceptabelt resultat, der er læsbart. Guiden til restore-testede backups forklarer, hvorfor et vellykket job alene ikke er tilstrækkeligt.

Dokumentation, der skal indsamles, før Stirling PDF går live

For Stirling PDF skal du definere en kendt, velfungerende transaktion før lancering: Flet to PDF'er, kør OCR på en scannet side, komprimér resultatet, og kontrollér upload- og downloadadfærden gennem den offentlige proxy. Læg forudsætninger, forventet svar og oprydningstrin i versionsstyring uden secret-værdier. Fastlås det image, der blev brugt til at etablere denne reference.

Brug transaktionen til at validere en erstatning og en uafhængig restore. Den gendannede service er kun acceptabel, når konfiguration og OCR-aktiver er gendannet, og et fast testdokument giver et acceptabelt resultat, der er læsbart. Observer samtidig midlertidig diskplads, OCR-sprogpakker, JVM-hukommelse og samtidige konverteringsjobs, og omdan den langsomste eller mest begrænsede del til en service-level alert.

Gaten skal også have et negativt testtilfælde: Indsend ufarligt input tæt på den ressource- eller formatgrænse, der er knyttet til denne grænse: uploads overskrider proxyens grænse, eller containeren kan ikke skrive midlertidige filer. Bekræft, at Stirling PDF returnerer en handlingsrettet fejl, samtidig med at data bevares, gendan den gyldige tilstand, og gentag den kendte, velfungerende transaktion. Ved at gemme begge resultater undgår du, at et overfladisk health-endpoint bliver det eneste produktionsbevis.

Drift af Stirling PDF omkring den reelle flaskehals

Hold øje med det arbejde, Stirling PDF udfører: midlertidig diskplads, OCR-sprogpakker, JVM-hukommelse og samtidige konverteringsjobs. Sæt limits med headroom til dette arbejde, og undgå en liveness-probe, der konkurrerer med det. Operatørkontrollen skal stadig forsøge at flette to PDF'er, køre OCR på en scannet side, komprimere resultatet og kontrollere upload- og downloadadfærden gennem den offentlige proxy efter en plan.

Ved opdateringer skal du huske, at installerede OCR-data, custom-konfiguration og sikkerhedsindstillinger skal sammenlignes før en image-opgradering. Deploy kandidatversionen mod en gendannet kopi, og gentag den kendte test. Hvis uploads overskrider proxyens grænse, eller containeren ikke kan skrive midlertidige filer, skal du bruge runtime-logs og den faktiske netværksrequest til at finde den ændrede antagelse.

Deploy Stirling PDF på Dockup uden at miste grænserne

Dockup fjerner manuelt reverse-proxy- og lifecycle-arbejde omkring Stirling PDF. Servicen får en stabil HTTPS-route til port 8080, injiceret konfiguration og persistent storage under udskiftninger. En tilknyttet kundeserver følger samme model som Dockup-hostet compute.

Efter lanceringen skal du opfylde applikationskontrakten: Angiv den offentlige HTTPS-origin og proxyens uploadgrænser, bekræft det lokale krav — valgfri OCR-sprogdata og tilstrækkelig midlertidig diskplads til store jobs — og kør dette bevis: Flet to PDF'er, kør OCR på en scannet side, komprimér resultatet, og kontrollér upload- og downloadadfærden gennem den offentlige proxy. Det holder one-click-oplevelsen nyttig uden at udviske de detaljer, der gør Stirling PDF gendanneligt og sikkert.

Ofte stillede spørgsmål

Hvad kræver Stirling PDF til et produktionsdeployment?

Route Stirling PDF-containeren på port 8080 gennem én HTTPS-origin. Det lokale runtime-krav er valgfri OCR-sprogdata og tilstrækkelig midlertidig diskplads til store jobs. Kald ikke Stirling PDF klar, før du kan flette to PDF'er, køre OCR på en scannet side, komprimere resultatet og kontrollere upload- og downloadadfærden gennem den offentlige proxy.

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

Gør /configs persistent, og medtag konfiguration, custom-filer og eventuelle OCR-data, du bevidst har installeret, i det samme recovery-manifest. En ren Stirling PDF-restore er kun godkendt, når konfiguration og OCR-aktiver er gendannet, og et fast testdokument giver et acceptabelt resultat, der er læsbart.

Kræver Stirling PDF HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Stirling PDF-origin, og behold port 8080 på den interne route. Anvend Stirling PDF-indstillingen korrekt: Angiv den offentlige HTTPS-origin og proxyens uploadgrænser. For Stirling PDF beskytter HTTPS legitimationsoplysninger eller brugerindhold under transport og sikrer ensartet client-adfærd, der afhænger af origin.

Hvordan skal en Stirling PDF-opgradering testes?

Gendan den aktuelle Stirling PDF-state i et isoleret deployment, anvend kandidatversionen, og gentag dens accepttransaktion. Vær særligt opmærksom, fordi installerede OCR-data, custom-konfiguration og sikkerhedsindstillinger skal sammenlignes før en image-opgradering. Behold det tidligere Stirling PDF-image, indtil dets datamigrerings- og rollback-grænse er forstået.