Comment auto-héberger Stirling PDF en 2026 : uploads, OCR et sécurité de la connexion
Auto-hébergez Stirling PDF avec les bons ports, un stockage persistant, HTTPS, des secrets, des sauvegardes et des vérifications de mise à niveau. Découvrez comment résoudre les problèmes d’uploads qui dépassent la limite du proxy.
Il existe deux façons de « faire fonctionner Stirling PDF » : un container existe, ou le service accomplit réellement sa tâche. Seule la seconde compte. Ici, la vérification consiste à fusionner deux PDF, à appliquer l’OCR sur une page numérisée, à compresser le résultat et à vérifier le comportement des uploads et des téléchargements via le proxy public.
Stirling PDF sert précisément à cela : une interface web et une API pour les opérations courantes sur les PDF. Le déploiement doit préserver les éléments qui permettent ce fonctionnement ; un port, un volume et un certificat sont des entrées, pas le résultat.
Paramètres du container à vérifier
Le premier container doit pouvoir être supprimé et recréé facilement. Conservez les données en dehors de la couche inscriptible, ne liez le port 8080 que là où le proxy peut l’atteindre et transmettez la configuration au 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
Figez la version de l’image après le test initial. Lisez l’erreur de démarrage la plus ancienne plutôt que le dernier message de redémarrage, vérifiez chaque montage avec docker inspect et suivez les logs pendant que vous fusionnez deux PDF, appliquez l’OCR sur une page numérisée, compressez le résultat et vérifiez le comportement des uploads et des téléchargements via le proxy public. Cette séquence permet de distinguer une mauvaise commande d’image d’un problème de dépendance ou de permissions.
Définissez d’abord les critères de réussite de Stirling PDF
Séparez quatre aspects pour Stirling PDF : l’ingress, le listener sur le port 8080, l’état persistant et les services de support ou la capacité locale. Le besoin du runtime local comprend éventuellement les données de langues OCR et suffisamment d’espace disque temporaire pour les tâches volumineuses. Consignez-le à côté de l’image et du port afin qu’un serveur de remplacement dispose des mêmes capacités locales.
Exécutez la transaction de référence — fusionner deux PDF, appliquer l’OCR sur une page numérisée, compresser le résultat et vérifier le comportement des uploads et des téléchargements via le proxy public — avant de considérer cette séparation comme terminée. Mesurez l’espace disque temporaire, les packs de langues OCR, la mémoire JVM et le nombre de tâches de conversion simultanées, puis conservez le résultat avec la fiche de déploiement. Vous disposerez ainsi à la fois d’un critère d’acceptation et d’une première référence de capacité.
Sécurisez Stirling PDF après le bootstrap
Le risque de sécurité propre à l’application est de laisser la sécurité désactivée sur un service public de traitement de documents. La réponse opérationnelle consiste à activer la connexion pour une instance exposée à Internet et à éviter de conserver les documents envoyés plus longtemps que nécessaire pour la tâche. Terminez le bootstrap via une route restreinte et supprimez immédiatement l’accès temporaire de configuration.
SECURITY_ENABLELOGIN contrôle le comportement, pas la confidentialité ; validez son type et sa valeur, et stockez séparément les véritables identifiants Stirling PDF. N’accordez au processus Stirling PDF que les montages et les routes de dépendance documentés ; évitez l’accès à la racine de l’hôte et au Docker socket. Journalisez les échecs d’authentification et les erreurs de configuration, mais masquez les tokens, les chaînes de connexion et le contenu utilisateur.
Donnez à Stirling PDF une adresse canonique unique
Le navigateur, le client API et Stirling PDF doivent utiliser une même origin. Pour y parvenir, définissez l’origin HTTPS publique et les limites d’upload du proxy. Préservez l’hôte et le protocole d’origine, tout en empêchant le port 8080 de devenir une seconde adresse publique concurrente.
Le guide de dépannage d’un site inaccessible aide à distinguer une route inaccessible d’une application qui répond. Cette distinction est importante ici : les uploads dépassent la limite du proxy ou le container ne peut pas écrire les fichiers temporaires. Seul le premier problème se résout avec des changements au niveau de l’ingress ; le second nécessite d’inspecter les logs, l’état ou la charge de travail de Stirling PDF.
Séparez les containers remplaçables des données durables
L’ensemble nécessaire à la récupération comprend la configuration, les fichiers personnalisés et toutes les données OCR que vous avez installées volontairement. Montez /configs avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le container pour vérifier que ce chemin est réellement persistant. Un volume protège les données contre le remplacement du container, mais pas contre la perte de l’hôte, la suppression accidentelle ou la corruption au niveau de l’application.
Effectuez des sauvegardes adaptées à la source de données : utilisez des dumps logiques pour les bases de données actives lorsque cela est nécessaire et copiez les fichiers uniquement depuis un état cohérent. Conservez une copie chiffrée en dehors de l’hôte Stirling PDF. Le critère d’acceptation d’une restauration doit être précis : la configuration et les ressources OCR sont restaurées, et un document de test fixe produit un résultat acceptable et lisible. Le guide des sauvegardes restaurées avec succès explique pourquoi la réussite d’une tâche ne suffit pas à elle seule.
Éléments de preuve à réunir avant la mise en production de Stirling PDF
Pour Stirling PDF, définissez une transaction de référence avant le lancement : fusionner deux PDF, appliquer l’OCR sur une page numérisée, compresser le résultat et vérifier le comportement des uploads et des téléchargements via le proxy public. Placez ses prérequis, la réponse attendue et les étapes de nettoyage dans le contrôle de version, sans valeurs secrètes. Figez l’image utilisée pour établir cette référence.
Utilisez cette transaction pour valider un remplacement et une restauration indépendante. Le service restauré n’est acceptable que lorsque la configuration et les ressources OCR sont restaurées et qu’un document de test fixe produit un résultat acceptable et lisible. En parallèle, surveillez l’espace disque temporaire, les packs de langues OCR, la mémoire JVM et le nombre de tâches de conversion simultanées, puis transformez l’élément le plus lent ou le plus contraignant en alerte de niveau de service.
La procédure doit également inclure un cas négatif : envoyez une entrée inoffensive proche de la limite de ressource ou de format associée à cette frontière : les uploads dépassent la limite du proxy ou le container ne peut pas écrire les fichiers temporaires. Vérifiez que Stirling PDF renvoie une erreur exploitable tout en préservant les données, rétablissez la condition valide et répétez la transaction de référence. Conserver les deux résultats évite qu’un endpoint de health check superficiel devienne le seul élément de preuve en production.
Exploitez Stirling PDF en fonction de son véritable goulot d’étranglement
Surveillez le travail effectué par Stirling PDF : l’espace disque temporaire, les packs de langues OCR, la mémoire JVM et le nombre de tâches de conversion simultanées. Définissez les limites en prévoyant une marge pour cette charge et évitez qu’une liveness probe ne lui fasse concurrence. Le contrôle opérateur doit tout de même tenter, selon une fréquence définie, de fusionner deux PDF, d’appliquer l’OCR sur une page numérisée, de compresser le résultat et de vérifier le comportement des uploads et des téléchargements via le proxy public.
Pour les mises à jour, n’oubliez pas de comparer les données OCR installées, la configuration personnalisée et les paramètres de sécurité avant la mise à niveau de l’image. Déployez la version candidate sur une copie restaurée et répétez le test de référence. Si les uploads dépassent la limite du proxy ou si le container ne peut pas écrire les fichiers temporaires, utilisez les logs du runtime et la requête réseau réelle pour déterminer quelle hypothèse a changé.
Déployez Stirling PDF sur Dockup sans perdre ses frontières
Dockup élimine le travail manuel lié au reverse proxy et au cycle de vie de Stirling PDF. Le service reçoit une route HTTPS stable vers le port 8080, une configuration injectée et un stockage persistant lors des remplacements. Un serveur client rattaché suit le même modèle que le compute hébergé sur Dockup.
Après le lancement, respectez le contrat applicatif : définissez l’origin HTTPS publique et les limites d’upload du proxy, confirmez le besoin local — des données de langues OCR facultatives et suffisamment d’espace disque temporaire pour les tâches volumineuses — et exécutez cette vérification : fusionner deux PDF, appliquer l’OCR sur une page numérisée, compresser le résultat et vérifier le comportement des uploads et des téléchargements via le proxy public. L’expérience en un clic reste ainsi utile sans gommer les détails qui rendent Stirling PDF récupérable et sécurisé.
Foire aux questions
De quoi Stirling PDF a-t-il besoin pour un déploiement en production ?
Faites passer le container Stirling PDF sur le port 8080 via une origin HTTPS unique. Le besoin du runtime local comprend des données de langues OCR facultatives et suffisamment d’espace disque temporaire pour les tâches volumineuses. Ne considérez pas Stirling PDF comme prêt tant que vous ne pouvez pas fusionner deux PDF, appliquer l’OCR sur une page numérisée, compresser le résultat et vérifier le comportement des uploads et des téléchargements via le proxy public.
Quelles données de Stirling PDF doivent figurer dans une sauvegarde ?
Rendez /configs persistant et incluez la configuration, les fichiers personnalisés et toutes les données OCR que vous avez installées volontairement dans le même manifeste de récupération. Une restauration propre de Stirling PDF n’est réussie que lorsque la configuration et les ressources OCR sont restaurées et qu’un document de test fixe produit un résultat acceptable et lisible.
Stirling PDF nécessite-t-il HTTPS derrière un reverse proxy ?
Utilisez HTTPS pour l’origin publique de Stirling PDF et conservez le port 8080 sur la route interne. Appliquez correctement le paramètre de Stirling PDF : définissez l’origin HTTPS publique et les limites d’upload du proxy. Pour Stirling PDF, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transmission et garantit un comportement cohérent des clients dépendant de l’origin.
Comment tester une mise à niveau de Stirling PDF ?
Restaurez l’état actuel de Stirling PDF dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif au fait que les données OCR installées, la configuration personnalisée et les paramètres de sécurité doivent être comparés avant la mise à niveau de l’image. Conservez l’image précédente de Stirling PDF jusqu’à ce que les limites de migration des données et de rollback soient comprises.