Journal-IndexDockup / Feldnotiz
Note / self-host-memos

Memos 2026 selbst hosten: Notizen, API-Zugriff und Backups

Eine praxisnahe Anleitung zum Self-Hosting von Memos mit Docker, Ports, persistenten Daten, TLS, Sicherheit, Backups und den Fehlern, die den produktiven Einsatz verhindern. Schritt für Schritt.

Behandle Memos als kleines System und nicht als Docker-Image. Das Ziel auf Benutzerseite ist klar: schnell erstellte Markdown-Notizen mit API; die Bereitstellung ist jedoch erst dann akzeptabel, wenn du eine private Notiz und einen Anhang erstellen, beides über die API abrufen und bearbeiten kannst und anschließend bestätigst, dass die Daten nach dem Ersetzen des Containers erhalten bleiben.

Diese Unterscheidung macht den Fehler sichtbar, auf den Betreiber nach lokalen Tests stoßen: Die Datenbankdatei liegt auf der Container-Schicht und verschwindet, sobald der Container ersetzt wird. Außerdem wird dadurch der Backup- und Upgrade-Plan konkret genug, um ihn zu testen.

Den lokalen Befehl in einen überprüfbaren Service verwandeln

Der erste Container sollte sich problemlos löschen und neu erstellen lassen. Halte die Daten von der beschreibbaren Schicht fern, binde Port 5230 nur dort, wo der Proxy ihn erreichen kann, und übergib die Konfiguration zur Laufzeit.

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

Fixiere das Image nach dem ersten Test. Lies den frühesten Startfehler statt der abschließenden Restart-Meldung, überprüfe jeden Mount mit docker inspect und verfolge die Logs, während du eine private Notiz und einen Anhang erstellst, beides über die API abrufst und bearbeitest und bestätigst, dass die Daten nach dem Ersetzen des Containers erhalten bleiben. So lässt sich ein fehlerhafter Image-Befehl von einem Problem mit Abhängigkeiten oder Berechtigungen unterscheiden.

Erfolg für Memos zuerst definieren

Trenne bei Memos vier Bereiche: Ingress, den Listener auf Port 5230, dauerhaften Zustand sowie unterstützende Services oder lokale Kapazität. Die lokale Laufzeitanforderung ist ein dauerhaftes Volume für die eingebettete Datenbank und die Assets. Teste diese Grenze vor der Veröffentlichung und erneut nach dem Ersetzen eines Containers.

Führe die bekannte Transaktion aus — eine private Notiz und einen Anhang erstellen, beides über die API abrufen und bearbeiten und bestätigen, dass die Daten nach dem Ersetzen des Containers erhalten bleiben —, bevor du diese Trennung als abgeschlossen betrachtest. Miss SQLite-Schreibvorgänge, das Wachstum der Anhänge, den API-Traffic und die Suche über angesammelte Notizen und halte das Ergebnis zusammen mit dem Deployment-Datensatz fest. Damit erhältst du sowohl ein Abnahmekriterium als auch die erste Kapazitätsbaseline.

Gib Memos nicht den gesamten Host

Bei Memos ist die wertvolle Angriffsfläche nicht unbedingt die Landingpage. Der häufigste Fehler besteht darin, die Registrierung länger als beabsichtigt offen zu lassen. Wirke dem gezielt entgegen: Schließe die Registrierung, sobald es angemessen ist, und schütze private Notizen durch ein starkes Konto und HTTPS.

Memos benötigt in dieser Ausgangskonfiguration kein obligatorisches Bootstrap-Secret. Schütze stattdessen das tatsächliche Administratorkonto oder die vorgeschaltete Authentifizierung. Verwende einen unprivilegierten Container-Benutzer, sofern das Image dies unterstützt, und mounte keine fremden Zugangsdaten. Setze am Ingress Rate- oder Größenlimits, wenn nicht vertrauenswürdige Vorgänge SQLite-Schreibvorgänge, das Wachstum der Anhänge, API-Traffic und die Suche über angesammelte Notizen beanspruchen können.

TLS ist einfach, generierte URLs sind es nicht

Vermeide temporäre und dauerhafte öffentliche Origins für Memos. Verwende stattdessen ein stabiles HTTPS-Origin für Browser- und API-Clients, richte den ausgewählten DNS-Namen auf die Plattform-Route und proxye ausschließlich auf Port 5230.

Führe diesen Vorgang von außerhalb des Hosts aus: Erstelle eine private Notiz und einen Anhang, rufe beides über die API ab, bearbeite es und bestätige, dass die Daten nach dem Ersetzen des Containers erhalten bleiben. Wenn der Ingress fehlschlägt, behandelt die Anleitung zur 502-Fehlerbehebung Fehler bei Port und Listener. Wenn Memos die Anfrage erhält, aber die Datenbankdatei auf der Container-Schicht liegt und nach dem Ersetzen verschwindet, deutet die Evidenz nun auf ein Problem jenseits des Proxys hin.

Nachweisen, dass Memos das Ersetzen übersteht

Ein Container-Image kann erneut heruntergeladen werden; die Memos-Datenbank und hochgeladene Ressourcen dagegen nicht. Mounte /var/opt/memos vor dem Bootstrap, schreibe harmlose Beispieldaten und ersetze den Container, um nachzuweisen, dass dieser Pfad tatsächlich persistent ist. Überprüfe den tatsächlich wirksamen Mount, statt einem Compose-Dateinamen zu vertrauen, und stelle sicher, dass der Laufzeitbenutzer an der von Memos erwarteten Stelle schreiben kann.

Lege Aufbewahrungsfristen und ein Ziel außerhalb des Hosts fest und übe die Wiederherstellung, ohne die Produktion anzufassen. Die Übung ist nur dann erfolgreich, wenn Benutzer, Notizen, Tags und Ressourcen zurückkehren und die API die bekannte private Notiz abrufen kann. Kombiniere bei datenbankgestützten Zuständen Storage-Snapshots mit anwendungskonsistenten Exporten, wie in Point-in-Time-Recovery im Vergleich zu Snapshots beschrieben.

Fünf Prüfungen, die aussagekräftiger sind als der Container-Health-Status

Mache den Traffic des ersten Benutzers nicht zum Abnahmetest für Memos. Bereite harmlose Beispieldaten vor und führe den vollständigen Vorgang „eine private Notiz und einen Anhang erstellen, beides über die API abrufen und bearbeiten und bestätigen, dass die Daten nach dem Ersetzen des Containers erhalten bleiben“ aus. Notiere die exakte öffentliche URL, das Ergebnis, die Image-Referenz und das mit dem Durchlauf verknüpfte Log-Intervall.

Ersetze den Container und wiederhole den Vorgang, ohne die Daten neu aufzubauen. Stelle anschließend auf einem leeren Host wieder her. Die Wiederherstellungsbedingung ist, dass Benutzer, Notizen, Tags und Ressourcen zurückkehren und die API die bekannte private Notiz abrufen kann. Beobachte bei jedem Durchlauf SQLite-Schreibvorgänge, das Wachstum der Anhänge, den API-Traffic und die Suche über angesammelte Notizen und definiere einen Alert für die Verschlechterung der Transaktion statt für inaktive Container-Metriken.

Eine abschließende Prüfung sollte absichtlich fehlschlagen: Sende harmlose Eingaben nahe am Ressourcen- oder Formatlimit, das mit dieser Grenze verbunden ist: Die Datenbankdatei liegt auf der Container-Schicht und verschwindet nach dem Ersetzen. Überprüfe, dass die resultierende Memos-Meldung die relevante Grenze benennt, statt eine Datenlöschung oder einen endlosen Restart auszulösen. Stelle den gültigen Zustand wieder her und bestätige, dass dieselbe Beispieltransaktion erfolgreich ist. Nimm diese kurze Übung in die Release-Checkliste auf.

Logs, die die nächste Frage beantworten

Verwende „eine private Notiz und einen Anhang erstellen, beides über die API abrufen und bearbeiten und bestätigen, dass die Daten nach dem Ersetzen des Containers erhalten bleiben“ als Memos-Smoke-Test nach jedem Deployment. Die zugehörigen Metriken sind SQLite-Schreibvorgänge, das Wachstum der Anhänge, der API-Traffic und die Suche über angesammelte Notizen. Setze den Alert dort, wo diese Ressourcen einen Bereich erreichen, in dem die Benutzeraktion beeinträchtigt wird.

Das größte Änderungsrisiko besteht darin, dass Memos-Datenbankmigrationen anhand einer Kopie geprobt werden sollten, da der gesamte Servicezustand in einem einzigen kompakten Pfad liegt. Ein sicheres Release beginnt mit einem wiederherstellbaren Snapshot und validiert jede einseitige Zustandsänderung, bevor Traffic umgeleitet wird. Wenn die Datenbankdatei auf der Container-Schicht liegt und nach dem Ersetzen verschwindet, bewahre den fehlgeschlagenen Container lange genug auf, um seine Konfiguration und den ersten Fehler zu lesen.

Dockup für die Plattformebene verwenden

Dockup nimmt dir die manuelle Arbeit rund um Reverse Proxy und Lifecycle von Memos ab. Der Service erhält während des Ersetzens eine stabile HTTPS-Route zu Port 5230, injizierte Konfiguration und persistenten Storage. Ein angebundener Kundenserver folgt demselben Modell wie von Dockup gehostete Compute-Ressourcen.

Erfülle nach dem Start den Anwendungskontrakt: Verwende ein stabiles HTTPS-Origin für Browser- und API-Clients, bestätige die lokale Anforderung — ein dauerhaftes Volume für die eingebettete Datenbank und die Assets — und führe diesen Nachweis aus: Erstelle eine private Notiz und einen Anhang, rufe beides über die API ab, bearbeite es und bestätige, dass die Daten nach dem Ersetzen des Containers erhalten bleiben. So bleibt die One-Click-Erfahrung nützlich, ohne die Details zu verschleiern, die Memos wiederherstellbar und sicher machen.

Häufig gestellte Fragen

Was benötigt Memos für ein produktives Deployment?

Leite den Memos-Container auf Port 5230 über ein einziges HTTPS-Origin. Die lokale Laufzeitanforderung ist ein dauerhaftes Volume für die eingebettete Datenbank und die Assets. Betrachte Memos erst dann als bereit, wenn du eine private Notiz und einen Anhang erstellen, beides über die API abrufen und bearbeiten kannst und anschließend bestätigst, dass die Daten nach dem Ersetzen des Containers erhalten bleiben.

Welche Memos-Daten gehören in ein Backup?

Mache /var/opt/memos persistent und nimm die Memos-Datenbank sowie hochgeladene Ressourcen in dasselbe Wiederherstellungsmanifest auf. Eine saubere Memos-Wiederherstellung ist erst dann erfolgreich, wenn Benutzer, Notizen, Tags und Ressourcen zurückkehren und die API die bekannte private Notiz abrufen kann.

Benötigt Memos hinter einem Reverse Proxy HTTPS?

Verwende HTTPS für das öffentliche Memos-Origin und halte Port 5230 auf der internen Route. Wende die Memos-Einstellung korrekt an: Verwende ein stabiles HTTPS-Origin für Browser- und API-Clients. Bei Memos schützt HTTPS Zugangsdaten oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes, vom Origin abhängiges Client-Verhalten.

Wie sollte ein Memos-Upgrade getestet werden?

Stelle den aktuellen Memos-Zustand in einem isolierten Deployment wieder her, spiele die Kandidatenversion ein und wiederhole die Abnahmetransaktion. Achte besonders darauf, dass Memos-Datenbankmigrationen anhand einer Kopie geprobt werden sollten, da der gesamte Servicezustand in einem einzigen kompakten Pfad liegt. Bewahre das vorherige Memos-Image auf, bis die Grenzen für Datenmigration und Rollback geklärt sind.