Comment auto-héberger PicoShare en 2026 : uploads, secrets partagés et stockage

L’auto-hébergement de PicoShare devient intéressant dès le premier redeploy, et non dès le premier docker run. Si les uploads atteignent les limites du proxy ou si les fichiers disparaissent à cause d’un chemin /data éphémère, Docker peut tout de même signaler un processus parfaitement sain. Le déploiement ci-dessous s’organise autour de comportements observables : uploader un fichier, le télécharger depuis un navigateur vierge, tester son expiration ou sa suppression, puis réessayer avec un fichier proche de la limite de taille choisie.

Le rôle de PicoShare est explicite : proposer un partage de fichiers minimaliste qui transforme les uploads en liens. Cette description indique ce qui doit rester public, ce qui doit rester privé et ce qu’une sauvegarde doit pouvoir reconstruire.

Rendez la récupération de PicoShare mesurable

Créez un recovery manifest pour PicoShare : les fichiers uploadés et les métadonnées PicoShare dans /data. Montez /data avant le bootstrap, écrivez des données d’exemple inoffensives, puis remplacez le conteneur pour prouver que ce chemin est réellement persistant. Vérifiez dès maintenant les permissions et l’espace libre, car un chemin monté mais inaccessible en écriture ne vaut pas mieux qu’une absence totale de persistance.

Sauvegardez vers un failure domain distinct du serveur en cours d’exécution. Recréez PicoShare à partir de son image versionnée et vérifiez que les octets uploadés et les métadonnées sont restaurés, puis qu’un échantillon des liens existants permet de télécharger des fichiers dont les hashes correspondent. Le guide des volumes persistants explique comment transformer cet exercice en politique de snapshots et de rétention.

La configuration de production de PicoShare

Le processus HTTP de PicoShare écoute sur le port 4001 ; conservez ce port sur le réseau applicatif et ne publiez que la route de la plateforme. L’exigence du runtime local est un volume de données durable et suffisamment d’espace disque pour les fichiers conservés. Documentez la capacité attendue, les permissions et le mode de défaillance au lieu de les laisser dépendre des valeurs par défaut de l’image.

Formalisez la boundary sous la forme d’un court contrat : qui est responsable de l’exigence, quel credential est utilisé, quel timeout est acceptable et comment la défaillance se manifeste. Exécutez ensuite cette transaction : uploader un fichier, le télécharger depuis un navigateur vierge, tester son expiration ou sa suppression, puis réessayer avec un fichier proche de la limite de taille choisie. Observez la capacité disque, la bande passante des uploads, les limites de taille du body du proxy et les téléchargements concurrents pendant l’exécution, car cette charge fournit une meilleure base pour choisir la taille initiale qu’un conteneur inactif.

La release gate de PicoShare

Transformez le smoke test de PicoShare en commande de release reproductible ou en court runbook. Sa sortie doit démontrer le résultat suivant : uploader un fichier, le télécharger depuis un navigateur vierge, tester son expiration ou sa suppression, puis réessayer avec un fichier proche de la limite de taille choisie. Enregistrez avec le résultat la version de l’application, le digest du conteneur, le hostname de la route et l’identifiant des données de test.

Exécutez le même contrôle après un remplacement courant du conteneur et après la restauration des fichiers uploadés et des métadonnées PicoShare dans /data ailleurs. La restauration a réussi lorsque les octets uploadés et les métadonnées sont revenus et qu’un échantillon des liens existants permet de télécharger des fichiers dont les hashes correspondent. Comparez les délais et la consommation liés à la capacité disque, à la bande passante des uploads, aux limites de taille du body du proxy et aux téléchargements concurrents ; une variation importante mérite une investigation, même si l’action finale réussit toujours.

Exercez ensuite une défaillance sans danger : envoyez une entrée inoffensive proche de la limite de ressource ou de format associée à cette boundary : les uploads atteignent les limites du proxy ou les fichiers disparaissent à cause d’un chemin /data éphémère. Vérifiez que PicoShare expose l’erreur et revient à la normale sans modifications manuelles destructrices. Conservez uniquement l’extrait de log nécessaire, après l’avoir expurgé. Cette gate en quatre parties couvre le démarrage, la persistance, la récupération et la gestion des défaillances.

Paramètres du conteneur à vérifier

Démarrez PicoShare de manière à ce que la route reste privée jusqu’à la fin du bootstrap.

docker run -d \
  --name picoshare \
  --restart unless-stopped \
  -p 127.0.0.1:4001:4001 \
  -v picoshare-data:/data \
  -e PS_SHARED_SECRET=replace-with-a-long-random-value \
  mtlynch/picoshare:latest

Si le processus redémarre en boucle, comparez l’utilisateur attendu par l’image avec le propriétaire de chaque chemin monté. S’il reste actif, testez localement le port 4001, puis passez directement au workflow : uploader un fichier, le télécharger depuis un navigateur vierge, tester son expiration ou sa suppression, puis réessayer avec un fichier proche de la limite de taille choisie. Ne versionnez précisément l’image qu’après la réussite de ce contrôle end-to-end, puis consignez la configuration exacte à côté du service.

Réduisez les privilèges de PicoShare

Les credentials de bootstrap sont temporaires ; le modèle de confiance est permanent. Avec PicoShare, veillez notamment à ne pas utiliser de shared secret devinable ni à proposer un stockage anonyme illimité ; utilisez plutôt un shared secret long, limitez le débit des uploads et évitez de transformer le service en stockage anonyme sans limite.

Remplacez immédiatement l’exemple de PS_SHARED_SECRET, stockez-le en dehors de l’image et faites-le tourner comme un credential d’administrateur s’il est exposé. Exécutez l’image sans capabilities Linux inutiles et n’exposez que la route applicative publique. Rendez l’activité des administrateurs visible sans enregistrer les valeurs secrètes.

Exposez PicoShare sans prétendre fournir HTTPS

Évitez les origins publiques temporaires et permanentes pour PicoShare. Publiez plutôt une seule origin HTTPS, dimensionnez le proxy pour les uploads attendus, faites pointer le nom DNS choisi vers la route de la plateforme et ne proxifiez que vers le port 4001.

Exécutez cette action depuis l’extérieur de l’hôte : uploader un fichier, le télécharger depuis un navigateur vierge, tester son expiration ou sa suppression, puis réessayer avec un fichier proche de la limite de taille choisie. Si l’ingress échoue, le guide de dépannage des erreurs 502 couvre les erreurs de port et de listener. Si PicoShare reçoit la requête, mais que les uploads atteignent les limites du proxy ou que les fichiers disparaissent à cause d’un chemin /data éphémère, les éléments disponibles pointent désormais au-delà du proxy.

Vérifications de capacité et de mise à niveau

Un health check exécuté sur un service inactif ne dit pas grand-chose sur PicoShare. Surveillez la capacité disque, la bande passante des uploads, les limites de taille du body du proxy et les téléchargements concurrents, puis déclenchez des alertes sur le symptôme observé par les utilisateurs : l’échec de l’action « uploader un fichier, le télécharger depuis un navigateur vierge, tester son expiration ou sa suppression, puis réessayer avec un fichier proche de la limite de taille choisie ». Gardez le liveness local et peu coûteux ; laissez le readiness signaler les migrations ou l’initialisation sans provoquer de restart storm.

La zone de risque lors d’une mise à niveau concerne les métadonnées PicoShare et la disposition des fichiers : elles doivent être vérifiées avant l’upgrade, car le lien n’est utile que si les deux correspondent. Lisez les release notes, créez un snapshot de l’état, déployez la version cible sur une copie restaurée et répétez l’action d’acceptance. Si les uploads atteignent les limites du proxy ou que les fichiers disparaissent à cause d’un chemin /data éphémère, corrélez la requête du client avec le premier log applicatif pertinent au lieu de supprimer l’état ou d’ajouter des redirections à l’aveugle.

Déployez PicoShare sur Dockup sans perdre ses boundaries

Dockup supprime le travail manuel lié au reverse proxy et au lifecycle de PicoShare. Le service reçoit une route HTTPS stable vers le port 4001, une configuration injectée et un stockage persistant lors des remplacements. Un serveur client attaché suit le même modèle que le compute hébergé par Dockup.

Après le lancement, respectez le contrat applicatif : publiez une seule origin HTTPS, dimensionnez le proxy pour les uploads attendus, confirmez l’exigence locale — un volume de données durable et suffisamment d’espace disque pour les fichiers conservés — et exécutez cette preuve : uploader un fichier, le télécharger depuis un navigateur vierge, tester son expiration ou sa suppression, puis réessayer avec un fichier proche de la limite de taille choisie. L’expérience one-click reste ainsi utile sans gommer les détails qui rendent PicoShare récupérable et sécurisé.

Foire aux questions

De quoi PicoShare a-t-il besoin pour un déploiement en production ?

Routez le conteneur PicoShare sur le port 4001 via une seule origin HTTPS. L’exigence du runtime local est un volume de données durable et suffisamment d’espace disque pour les fichiers conservés. Ne considérez pas PicoShare comme prêt tant que vous ne pouvez pas uploader un fichier, le télécharger depuis un navigateur vierge, tester son expiration ou sa suppression, puis réessayer avec un fichier proche de la limite de taille choisie.

Quelles données de PicoShare doivent figurer dans une sauvegarde ?

Rendez /data persistant et incluez les fichiers uploadés ainsi que les métadonnées PicoShare dans /data au sein du même recovery manifest. Une restauration propre de PicoShare n’est réussie que lorsque les octets uploadés et les métadonnées sont revenus et qu’un échantillon des liens existants permet de télécharger des fichiers dont les hashes correspondent.

PicoShare a-t-il besoin de HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origin publique de PicoShare et conservez le port 4001 sur la route interne. Appliquez correctement le paramètre PicoShare : publiez une seule origin HTTPS et dimensionnez le proxy pour les uploads attendus. Pour PicoShare, HTTPS protège les credentials ou le contenu utilisateur en transit et garantit un comportement cohérent des clients sensibles à l’origin.

Comment tester une mise à niveau de PicoShare ?

Restaurez l’état actuel de PicoShare dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptance. Soyez particulièrement attentif, car les métadonnées PicoShare et la disposition des fichiers doivent être vérifiées avant une mise à niveau : le lien n’est utile que si les deux correspondent. Conservez l’image PicoShare précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.