Stirling PDF zelf hosten in 2026: uploads, OCR en loginbeveiliging

Er zijn twee versies van “Stirling PDF draaien”: er bestaat een container, of de service voert zijn echte taak uit. Alleen de tweede is relevant. Het bewijs bestaat hier uit het samenvoegen van twee PDF's, het uitvoeren van OCR op een gescande pagina, het comprimeren van het resultaat en het controleren van upload- en downloadgedrag via de publieke proxy.

Stirling PDF dient hiervoor als webinterface en API voor veelgebruikte PDF-bewerkingen. De deployment moet de onderdelen achter dat gedrag behouden; een poort, volume en certificaat zijn invoer, niet het resultaat.

Containerinstellingen die je moet controleren

De eerste container moet eenvoudig te verwijderen en opnieuw aan te maken zijn. Houd data buiten de writable layer, bind poort 8080 alleen waar de proxy erbij kan en geef configuratie tijdens runtime door.

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

Pin de image na de eerste test. Lees de eerste startup-fout in plaats van het laatste restartbericht, controleer elke mount met docker inspect en volg de logs terwijl je twee PDF's samenvoegt, OCR uitvoert op een gescande pagina, het resultaat comprimeert en het upload- en downloadgedrag via de publieke proxy controleert. Met die volgorde kun je een foutieve imageopdracht onderscheiden van een dependency- of permissieprobleem.

Definieer eerst wanneer Stirling PDF geslaagd is

Scheid voor Stirling PDF vier zaken: ingress, de listener op 8080, persistente state en ondersteunende services of lokale capaciteit. De lokale runtimevereiste bestaat uit optionele OCR-taaldata en voldoende tijdelijke schijfruimte voor grote jobs. Leg dit vast naast de image en poort, zodat een vervangende host dezelfde lokale capaciteit krijgt.

Voer de bekende, succesvolle transactie uit — twee PDF's samenvoegen, OCR uitvoeren op een gescande pagina, het resultaat comprimeren en het upload- en downloadgedrag via de publieke proxy controleren — voordat je die scheiding als voltooid beschouwt. Meet tijdelijke schijfruimte, OCR-taalpakketten, JVM-geheugen en gelijktijdige conversiejobs en bewaar het resultaat bij het deploymentrecord. Dit levert zowel een acceptatiecriterium als de eerste capaciteitsbaseline op.

Beveilig Stirling PDF na de bootstrap

Het specifieke beveiligingsrisico van de applicatie is dat beveiliging uitgeschakeld blijft op een publieke service voor documentverwerking. Het operationele antwoord is om login in te schakelen voor een instance die vanaf het internet bereikbaar is en geüploade documenten niet langer te bewaren dan nodig is voor de job. Rond de bootstrap af via een beperkte route en verwijder tijdelijke toegang voor de setup direct daarna.

SECURITY_ENABLELOGIN bepaalt gedrag en geen vertrouwelijkheid; valideer het type en de waarde ervan en bewaar echte Stirling PDF-credentials afzonderlijk. Geef het Stirling PDF-proces alleen de gedocumenteerde mounts en dependency-routes; vermijd toegang tot de host-root en de Docker-socket. Log mislukte authenticatie en configuratiefouten, maar maskeer tokens, connection strings en gebruikersinhoud.

Geef Stirling PDF één canoniek adres

De browser, API-client en Stirling PDF moeten het eens zijn over één origin. Om dat te bereiken, stel je de publieke HTTPS-origin en proxy-uploadlimieten in. Behoud de oorspronkelijke host en het oorspronkelijke protocol en zorg er tegelijk voor dat poort 8080 niet beschikbaar is als concurrerend publiek adres.

De handleiding voor het oplossen van een onbereikbare site helpt onderscheid maken tussen een onbereikbare route en een applicatie die wel reageert. Dat onderscheid is hier belangrijk: uploads overschrijden de proxylimiet of de container kan geen tijdelijke bestanden schrijven. Alleen het eerste probleem los je op met ingresswijzigingen; het tweede vereist inspectie van Stirling PDF-logs, state of workload.

Scheid vervangbare containers van blijvende data

De persistente recoveryset bestaat uit configuratie, custom bestanden en eventuele OCR-data die je bewust hebt geïnstalleerd. Mount /configs vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Een volume beschermt data tegen het vervangen van een container, maar niet tegen verlies van de host, onbedoelde verwijdering of corruptie op applicatieniveau.

Maak back-ups die de databron begrijpen: gebruik waar nodig logical dumps voor live databases en kopieer bestanden alleen vanuit een consistente state. Bewaar één versleutelde kopie buiten de Stirling PDF-host. Het acceptatiecriterium voor een restore is specifiek: configuratie en OCR-assets komen terug en een vast testdocument levert een acceptabel, leesbaar resultaat op. De handleiding voor back-ups die je hebt teruggezet legt uit waarom alleen een succesvolle job niet voldoende is.

Bewijs dat je moet verzamelen voordat Stirling PDF live gaat

Definieer voor Stirling PDF vóór de launch een bekende, succesvolle transactie: twee PDF's samenvoegen, OCR uitvoeren op een gescande pagina, het resultaat comprimeren en het upload- en downloadgedrag via de publieke proxy controleren. Leg de vereisten, verwachte response en cleanupstappen zonder secretwaarden vast in version control. Pin de image die je hebt gebruikt om die referentie vast te leggen.

Gebruik de transactie om een vervanging en een onafhankelijke restore te valideren. De herstelde service is alleen acceptabel wanneer configuratie en OCR-assets terugkomen en een vast testdocument een acceptabel, leesbaar resultaat oplevert. Observeer tegelijkertijd tijdelijke schijfruimte, OCR-taalpakketten, JVM-geheugen en gelijktijdige conversiejobs en maak van het traagste of meest beperkte onderdeel een service-level alert.

De gate heeft ook een negatieve case nodig: dien onschadelijke input in die dicht bij de resource- of formatlimiet rond deze grens ligt: uploads overschrijden de proxylimiet of de container kan geen tijdelijke bestanden schrijven. Bevestig dat Stirling PDF een bruikbare foutmelding produceert terwijl de data behouden blijft, herstel de geldige situatie en herhaal de bekende, succesvolle transactie. Door beide resultaten te bewaren voorkom je dat een oppervlakkig health endpoint het enige bewijs voor productie wordt.

Beheer Stirling PDF rond de echte bottleneck

Observeer het werk dat Stirling PDF uitvoert: tijdelijke schijfruimte, OCR-taalpakketten, JVM-geheugen en gelijktijdige conversiejobs. Stel limieten in met voldoende headroom voor dat werk en voorkom een liveness probe die ermee concurreert. De operatorcontrole moet nog steeds volgens een schema proberen twee PDF's samen te voegen, OCR uit te voeren op een gescande pagina, het resultaat te comprimeren en het upload- en downloadgedrag via de publieke proxy te controleren.

Houd voor updates rekening met het feit dat geïnstalleerde OCR-data, custom configuratie en beveiligingsinstellingen vóór een image-upgrade moeten worden vergeleken. Deploy de kandidaatversie tegen een herstelde kopie en herhaal de bekende test. Als uploads de proxylimiet overschrijden of de container geen tijdelijke bestanden kan schrijven, gebruik dan runtime-logs en het daadwerkelijke netwerkrequest om vast te stellen welke aanname is veranderd.

Deploy Stirling PDF op Dockup zonder de grenzen ervan te verliezen

Dockup neemt het handmatige reverse-proxy- en lifecyclewerk rond Stirling PDF weg. De service krijgt tijdens vervangingen een stabiele HTTPS-route naar 8080, geïnjecteerde configuratie en persistente opslag. Een gekoppelde klantserver volgt hetzelfde model als compute die door Dockup wordt gehost.

Voldoe na de launch aan het applicatiecontract: stel de publieke HTTPS-origin en proxy-uploadlimieten in, bevestig de lokale vereiste — optionele OCR-taaldata en voldoende tijdelijke schijfruimte voor grote jobs — en voer dit bewijs uit: voeg twee PDF's samen, voer OCR uit op een gescande pagina, comprimeer het resultaat en controleer het upload- en downloadgedrag via de publieke proxy. Zo blijft de one-clickervaring nuttig zonder de details af te vlakken die Stirling PDF herstelbaar en veilig maken.

Veelgestelde vragen

Wat heeft Stirling PDF nodig voor een production deployment?

Routeer de Stirling PDF-container op poort 8080 via één HTTPS-origin. De lokale runtimevereiste bestaat uit optionele OCR-taaldata en voldoende tijdelijke schijfruimte voor grote jobs. Noem Stirling PDF pas klaar wanneer je twee PDF's kunt samenvoegen, OCR kunt uitvoeren op een gescande pagina, het resultaat kunt comprimeren en het upload- en downloadgedrag via de publieke proxy kunt controleren.

Welke Stirling PDF-data hoort in een back-up?

Maak /configs persistent en neem configuratie, custom bestanden en eventuele OCR-data die je bewust hebt geïnstalleerd op in hetzelfde recoverymanifest. Een schone Stirling PDF-restore is alleen geslaagd wanneer configuratie en OCR-assets terugkomen en een vast testdocument een acceptabel, leesbaar resultaat oplevert.

Heeft Stirling PDF HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Stirling PDF-origin en houd poort 8080 op de interne route. Pas de Stirling PDF-instelling correct toe: stel de publieke HTTPS-origin en proxy-uploadlimieten in. Voor Stirling PDF beschermt HTTPS credentials en gebruikersinhoud tijdens transport en zorgt het voor consistent gedrag van clients die afhankelijk zijn van de origin.

Hoe test je een Stirling PDF-upgrade?

Zet de huidige Stirling PDF-state terug in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier vooral op, omdat geïnstalleerde OCR-data, custom configuratie en beveiligingsinstellingen vóór een image-upgrade moeten worden vergeleken. Houd de vorige Stirling PDF-image beschikbaar totdat de grenzen van datamigratie en rollback duidelijk zijn.