Comment auto-héberger Memos en 2026 : notes, accès à l’API et sauvegardes

Considérez Memos comme un petit système, pas comme une image Docker. L’objectif côté utilisateur est clair : créer rapidement des notes Markdown avec une API ; le déploiement n’est acceptable que lorsque vous pouvez créer un mémo privé et une pièce jointe, les récupérer via l’API, les modifier et confirmer qu’ils restent disponibles après le remplacement du conteneur.

Cette distinction permet d’identifier le problème que les opérateurs rencontrent après les tests locaux : le fichier de base de données se trouve sur la couche du conteneur et disparaît après son remplacement. Elle permet également de définir un plan de sauvegarde et de mise à niveau suffisamment précis pour être testé.

Transformer la commande locale en service inspectable

Le premier conteneur doit pouvoir être supprimé et recréé facilement. Conservez les données en dehors de la couche inscriptible, liez le port 5230 uniquement là où le proxy peut l’atteindre et transmettez la configuration au runtime.

docker run -d \
  --name memos \
  --restart unless-stopped \
  -p 127.0.0.1:5230:5230 \
  -v memos-data:/var/opt/memos \
  neosmemo/memos:stable --mode prod --port 5230

Épinglez l’image après le test initial. Lisez la première erreur de démarrage plutôt que le dernier message de redémarrage, vérifiez chaque montage avec docker inspect et suivez les logs pendant que vous créez un mémo privé et une pièce jointe, les récupérez via l’API, les modifiez et confirmez qu’ils restent disponibles après le remplacement du conteneur. Cette séquence permet de distinguer une mauvaise commande d’image d’un problème de dépendance ou d’autorisations.

Définir d’abord les critères de réussite de Memos

Séparez quatre éléments pour Memos : l’ingress, le listener sur le port 5230, l’état durable et les services de support ou la capacité locale. L’exigence du runtime local est un volume durable pour sa base de données embarquée et ses ressources. Testez cette limite avant la publication, puis à nouveau après le remplacement d’un conteneur.

Exécutez la transaction de référence — créer un mémo privé et une pièce jointe, les récupérer via l’API, les modifier et confirmer qu’ils restent disponibles après le remplacement du conteneur — avant de considérer cette séparation comme terminée. Mesurez les écritures SQLite, la croissance des pièces jointes, le trafic de l’API et les recherches sur les notes accumulées, puis conservez le résultat avec l’enregistrement du déploiement. Vous disposez ainsi à la fois d’un critère d’acceptation et d’une première référence de capacité.

Ne donnez pas à Memos l’accès à tout l’hôte

Pour Memos, la surface utile n’est pas nécessairement la landing page. L’erreur principale consiste à laisser les inscriptions ouvertes plus longtemps que prévu. Corrigez-la délibérément : fermez les inscriptions lorsque c’est nécessaire et protégez les mémos privés derrière un compte robuste et HTTPS.

Memos n’a pas de secret d’amorçage obligatoire dans cette configuration de référence ; protégez plutôt son véritable compte administrateur ou l’authentification en amont. Utilisez un utilisateur de conteneur non privilégié lorsque l’image le permet et ne montez aucun identifiant sans rapport avec le service. Appliquez des limites de débit ou de taille au niveau de l’ingress lorsque des opérations non fiables peuvent consommer des écritures SQLite, accroître le volume des pièces jointes, générer du trafic API et multiplier les recherches sur les notes accumulées.

Le TLS est simple ; les URL générées, non

Évitez les origines publiques temporaires et permanentes pour Memos. Utilisez plutôt une origine HTTPS stable pour les clients navigateur et API, dirigez le nom DNS choisi vers la route de la plateforme et faites proxy uniquement vers le port 5230.

Exécutez cette opération depuis l’extérieur de l’hôte : créez un mémo privé et une pièce jointe, récupérez-les via l’API, modifiez-les et confirmez qu’ils restent disponibles après le remplacement du conteneur. Si l’ingress échoue, le guide de dépannage des erreurs 502 couvre les erreurs de port et de listener. Si Memos reçoit la requête, mais que le fichier de base de données se trouve sur la couche du conteneur et disparaît après son remplacement, les éléments disponibles indiquent désormais un problème situé au-delà du proxy.

Prouver que Memos survit au remplacement

Une image de conteneur peut être téléchargée à nouveau ; la base de données Memos et les ressources importées, non. Montez /var/opt/memos avant l’amorçage, écrivez des données d’exemple inoffensives et remplacez le conteneur pour prouver que ce chemin est réellement persistant. Inspectez le montage effectif au lieu de faire confiance à un nom de fichier Compose et vérifiez que l’utilisateur du runtime peut écrire là où Memos l’attend.

Choisissez une politique de rétention et une destination hors hôte, puis répétez la récupération sans toucher à la production. Le test n’est réussi que lorsque les utilisateurs, les mémos, les tags et les ressources sont restaurés et que l’API récupère le mémo privé de référence. Pour les états stockés dans une base de données, associez des snapshots du stockage à des exports cohérents au niveau applicatif, comme indiqué dans récupération à un instant donné ou snapshots.

Cinq vérifications plus fiables que la santé du conteneur

Ne faites pas du trafic du premier utilisateur le test d’acceptation de Memos. Préparez un état d’exemple inoffensif et exécutez l’opération complète « créer un mémo privé et une pièce jointe, les récupérer via l’API, les modifier et confirmer qu’ils restent disponibles après le remplacement du conteneur ». Notez l’URL publique exacte, le résultat, la référence de l’image et l’intervalle de logs associés à l’exécution.

Remplacez le conteneur et répétez l’opération sans reconstruire les données. Ensuite, effectuez une récupération sur un hôte vide ; la condition de récupération est que les utilisateurs, les mémos, les tags et les ressources soient restaurés et que l’API récupère le mémo privé de référence. Observez les écritures SQLite, la croissance des pièces jointes, le trafic de l’API et les recherches sur les notes accumulées à chaque passage, puis définissez une alerte autour de la dégradation de la transaction plutôt qu’autour des métriques d’inactivité du conteneur.

Une dernière vérification doit échouer volontairement : envoyez une entrée inoffensive proche de la limite de ressource ou de format associée à cette limite : le fichier de base de données se trouve sur la couche du conteneur et disparaît après son remplacement. Vérifiez que le message Memos qui en résulte identifie la limite concernée au lieu de déclencher une suppression de données ou une boucle de redémarrage infinie. Rétablissez la condition valide et confirmez que la même transaction d’exemple réussit. Conservez ce court test dans la checklist de release.

Des logs qui répondent à la question suivante

Utilisez « créer un mémo privé et une pièce jointe, les récupérer via l’API, les modifier et confirmer qu’ils restent disponibles après le remplacement du conteneur » comme smoke test Memos après chaque déploiement. Ses métriques de support sont les écritures SQLite, la croissance des pièces jointes, le trafic de l’API et les recherches sur les notes accumulées ; déclenchez une alerte lorsque ces ressources approchent un niveau qui dégrade l’action utilisateur.

Le principal risque lors d’une modification vient du fait que les migrations de la base de données Memos doivent être répétées sur une copie, car l’état complet du service réside dans un seul chemin compact. Une release sûre commence par un snapshot récupérable et valide toute modification d’état irréversible avant de basculer le trafic. Lorsque le fichier de base de données se trouve sur la couche du conteneur et disparaît après son remplacement, conservez le conteneur défaillant assez longtemps pour lire sa configuration et sa première erreur.

Utiliser Dockup pour la couche plateforme

Dockup élimine le travail manuel lié au reverse proxy et au cycle de vie de Memos. Le service reçoit une route HTTPS stable vers le port 5230, 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 : utilisez une origine HTTPS stable pour les clients navigateur et API, confirmez l’exigence locale — un volume durable pour sa base de données embarquée et ses ressources — et exécutez cette vérification : créez un mémo privé et une pièce jointe, récupérez-les via l’API, modifiez-les et confirmez qu’ils restent disponibles après le remplacement du conteneur. Cela permet de conserver l’intérêt de l’expérience en un clic sans masquer les détails qui rendent Memos récupérable et sécurisé.

Foire aux questions

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

Acheminez le conteneur Memos sur le port 5230 via une seule origine HTTPS. L’exigence du runtime local est un volume durable pour sa base de données embarquée et ses ressources. Ne déclarez pas Memos prêt tant que vous ne pouvez pas créer un mémo privé et une pièce jointe, les récupérer via l’API, les modifier et confirmer qu’ils restent disponibles après le remplacement du conteneur.

Quelles données Memos doivent être incluses dans une sauvegarde ?

Rendez /var/opt/memos persistant et incluez la base de données Memos ainsi que les ressources importées dans le même manifeste de récupération. Une restauration propre de Memos n’est réussie que lorsque les utilisateurs, les mémos, les tags et les ressources sont restaurés et que l’API récupère le mémo privé de référence.

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

Utilisez HTTPS pour l’origine publique de Memos et conservez le port 5230 sur la route interne. Appliquez correctement le paramètre Memos : utilisez une origine HTTPS stable pour les clients navigateur et API. Pour Memos, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transmission et garantit la cohérence du comportement des clients sensible à l’origine.

Comment tester une mise à niveau de Memos ?

Restaurez l’état actuel de Memos dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les migrations de la base de données Memos doivent être répétées sur une copie, l’état complet du service résidant dans un seul chemin compact. Conservez l’image Memos précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.