Wer an einem Roman oder einer Kurzgeschichte schreibt und dabei mehrere Geräte nutzt, kommt an Synchronisation kaum vorbei. Die meisten Schreibprogramme lösen das über eine Cloud des Herstellers – bequem, aber mit einem Haken: Die eigenen, unveröffentlichten Texte liegen auf einem Server, über den man selbst keine Kontrolle hat. Das Open-Source-Projekt Hammer geht einen anderen Weg. Die App ist grundsätzlich offline-first gebaut und funktioniert vollständig ohne Internetverbindung. Wer trotzdem zwischen mehreren Geräten synchronisieren möchte, kann dafür einen eigenen Sync-Server betreiben – unter MIT-Lizenz, per Docker Compose in wenigen Schritten aufgesetzt. Dieser Artikel zeigt, was Hammer kann, wie der Sync-Server technisch funktioniert, wie die Einrichtung abläuft und für wen sich der Aufwand lohnt.

Was ist Hammer eigentlich?

Hammer ist eine kostenlose, quelloffene Schreib-App für Romane, Kurzgeschichten und andere längere Texte, entwickelt von Dark Rock Studios rund um den Hauptmaintainer, der auf GitHub unter dem Namen Wavesonics auftritt. Das Projekt ist in Kotlin Multiplatform geschrieben, wodurch dieselbe Codebasis auf Desktop- und mobilen Plattformen läuft. Die erste öffentliche Version, ein Alpha-Release mit der Versionsnummer 1.0.0, erschien am 23. April 2023 – seither ist das Projekt kontinuierlich gewachsen. Die aktuelle Version zum Zeitpunkt dieses Artikels ist 3.8.2, veröffentlicht am 11. August 2026. Der Quellcode liegt vollständig auf GitHub im Repository „Darkrock-Studios/hammer-editor" und steht unter der MIT-Lizenz – man darf ihn also frei nutzen, verändern und auch kommerziell einsetzen.

Offline-first: Warum das für Autor:innen wichtig ist

Der zentrale Designgedanke von Hammer ist offline-first: Die App funktioniert komplett ohne Internetverbindung. Texte, Kapitel, Notizen und die gesamte Projektstruktur liegen zunächst lokal auf dem jeweiligen Gerät. Das unterscheidet Hammer von vielen kommerziellen Schreibwerkzeugen, die von Haus aus auf eine Cloud-Verbindung angewiesen sind, um überhaupt zu funktionieren oder Daten zu sichern. Wer nur auf einem Gerät schreibt, braucht bei Hammer also gar keinen Server – die App ist von Anfang an voll funktionsfähig. Erst wer denselben Text auf mehreren Geräten – etwa Laptop, Tablet und Smartphone – bearbeiten möchte, benötigt einen Abgleichmechanismus. Genau hier kommt der optionale Sync-Server ins Spiel, um den es in diesem Artikel vor allem geht.

Der Sync-Server: Architektur und Funktionsweise

Der Sync-Server ist ein eigenständiger Dienst, den Hammer als separaten Docker-Container anbietet. Er läuft unabhängig von den Client-Apps und übernimmt ausschließlich den Abgleich von Änderungen zwischen den Geräten. Als Datenbank nutzt der Server standardmäßig eine eingebettete PostgreSQL-Instanz, die beim Start automatisch mitgeliefert wird – wer lieber eine bereits vorhandene Postgres-Datenbank im eigenen Netzwerk verwendet, kann das über die mitgelieferte, auskommentierte Postgres-Konfiguration in der Compose-Datei ebenfalls einrichten. Sämtliche Zustandsdaten – die eingebettete Datenbank, ein Cache-Verzeichnis, die Konfigurationsdatei config.toml und eine server.keyring.json für die Authentifizierung – landen persistiert unter dem Pfad /data/hammer_data/. Die Kommunikation zwischen Client-Apps und Server läuft über HTTP beziehungsweise, wie im übernächsten Abschnitt beschrieben, verpflichtend über HTTPS.

Installation mit Docker Compose Schritt für Schritt

Die Projektdokumentation nennt Docker als den einfachsten Weg, den Sync-Server zu betreiben. Grob läuft die Einrichtung so ab:

  1. Repository klonen und in das Verzeichnis docker wechseln.
  2. Mit docker compose up -d den Server starten. Docker lädt dabei automatisch das offizielle Image ghcr.io/darkrock-studios/hammer-editor/server:latest von der GitHub Container Registry.
  3. In der Konfigurationsdatei config.toml lassen sich unter anderem host und port anpassen; alternativ stehen die Umgebungsvariablen HAMMER_HTTP_BIND und HAMMER_HTTP_PORT zur Verfügung.
  4. Standardmäßig lauscht der Server auf 127.0.0.1:8080 – also nur lokal erreichbar, nicht automatisch aus dem Internet.

Wer den Non-Docker-Weg bevorzugt, braucht zusätzlich eine Java-Laufzeitumgebung sowie die Bibliotheken fontconfig und libfreetype6 für die Erstellung von Link-Vorschaubildern – für die meisten Selfhoster dürfte der Docker-Weg aber deutlich unkomplizierter sein. Zur benötigten Hardware macht die Dokumentation keine Angabe; weder RAM- noch CPU- noch Speicherbedarf werden konkret beziffert. Für eine kleine Zahl von Nutzer:innen dürfte ein schlanker Docker-Host reichen, das ist an dieser Stelle aber eine Einschätzung und keine belegte Angabe der Entwickler.

HTTPS ist Pflicht, nicht Kür

Ein Punkt, den die Dokumentation ausdrücklich hervorhebt: Der Sync-Server sollte niemals unverschlüsselt über das offene Internet erreichbar sein. Die Anleitung warnt sinngemäß davor, den Standardport ohne vorgeschalteten Reverse Proxy mit TLS-Terminierung auf 0.0.0.0 zu öffnen. Wer den Server also außerhalb des eigenen lokalen Netzwerks erreichbar machen will, braucht zwingend einen Reverse Proxy – etwa Caddy, Traefik oder nginx – der eine gültige HTTPS-Verbindung bereitstellt, bevor Anfragen an den eigentlichen Hammer-Server weitergereicht werden. Ohne diesen Schritt würden Zugangsdaten und Manuskriptinhalte im Klartext über das Netz laufen. Diese Anforderung ist keine Besonderheit von Hammer, sondern gute Praxis für praktisch jeden selbst gehosteten Dienst mit Zugangsdaten – bei einem Werkzeug für unveröffentlichte Texte ist sie aber besonders naheliegend.

Updates, Backups und Wartung im Alltag

Da der Server als Docker-Container läuft, ist ein Update in der Regel unkompliziert: Ein neues Image von der GitHub Container Registry ziehen und den Container mit docker compose pull und anschließend docker compose up -d neu starten, übernimmt die neue Version. Weil sämtliche Nutzdaten unterhalb von /data/hammer_data/ liegen – inklusive der eingebetteten PostgreSQL-Datenbank, des Caches und der Schlüsseldatei – reicht es für ein Backup, dieses eine Verzeichnis regelmäßig zu sichern, etwa mit einem klassischen Cronjob und rsync oder einem Werkzeug wie restic. Eine fertige Backup-Anleitung liefert die Projektdokumentation dazu nicht; wer den Server produktiv nutzt, sollte dieses Verzeichnis also selbst in die eigene Backup-Strategie aufnehmen, bevor Manuskripte darauf abgelegt werden. Ein Restore läuft im Prinzip umgekehrt: Verzeichnis an gleicher Stelle wiederherstellen, Container neu starten, fertig. Wer eine externe PostgreSQL-Instanz statt der eingebetteten Datenbank nutzt, sichert diese zusätzlich über die dort üblichen Mittel, etwa pg_dump.

Reifegrad, Wartungsstand und Community

Hammer wird seit April 2023 aktiv entwickelt und hat mittlerweile mehr als drei Jahre kontinuierliche Historie vorzuweisen – kein über Nacht hochgeladenes Projekt. Die jüngere Release-Historie zeigt das Tempo: 30. Juni 2026 Version 3.5.2, 8. Juli 3.6.0, 13. Juli 3.6.1, 21. Juli 3.7.0, 27. Juli 3.7.2, 5. August 3.8.0, 8. August 3.8.1, 11. August 3.8.2. Zwischen den Releases liefen durchgehend Commits auf dem develop-Branch, zuletzt noch am 16. August 2026. Zum Zeitpunkt dieses Artikels zählt das Repository 660 Sterne, 36 Forks und 40 offene Issues bei 6 offenen Pull Requests. Die Commit-Historie zeigt, dass der Großteil der aktuellen Entwicklung von einer einzelnen Person – dem Hauptmaintainer Wavesonics – stammt, ergänzt durch Übersetzungsbeiträge etwa ins Italienische sowie automatisierte Übersetzungs-Synchronisation über Crowdin. Es handelt sich also um ein aktives, aber im Kern von einer einzelnen Person getragenes Projekt – ein Punkt, den man bei der Entscheidung für den produktiven Einsatz mit einkalkulieren sollte. Neben dem Selbst-Hosting bietet das Projekt mit hammer.ink auch einen offiziellen, über Patreon finanzierten gehosteten Sync-Server als bequeme Alternative an, falls der eigene Server-Betrieb nicht infrage kommt.

Für wen lohnt sich der eigene Server – und für wen nicht

Der Sync-Server lohnt sich vor allem für alle, die auf mehreren Geräten schreiben, ohnehin schon einen Docker-Host oder ein kleines Homelab betreiben und ihre unveröffentlichten Texte grundsätzlich nicht bei einem fremden Anbieter liegen haben wollen. Für Autor:innen, die ausschließlich an einem einzigen Gerät schreiben, bringt der Server dagegen keinen Mehrwert – Hammer funktioniert dort bereits ohne jede Serverkomponente vollständig offline. Wer keine eigene Infrastruktur betreiben möchte, aber trotzdem synchronisieren will, kann stattdessen auf den offiziellen gehosteten Dienst unter hammer.ink zurückgreifen.

Alternativen im Self-Hosting-Umfeld

Eine direkte, ebenso spezialisierte selbst hostbare Alternative für Romane und lange Texte ist derzeit kaum verbreitet – die meisten Konkurrenzprodukte setzen entweder auf rein lokale Dateien ohne Sync-Funktion oder auf proprietäre Clouds ohne Selbst-Hosting-Option. Wer generell Notizen oder Textdateien zwischen Geräten synchronisieren möchte, findet in Werkzeugen wie einem selbst gehosteten Joplin-Server oder einem Standard-Notes-Server verwandte, aber breiter angelegte Lösungen, die nicht speziell auf die Struktur eines Schreibprojekts mit Kapiteln, Figuren und Zeitleisten zugeschnitten sind. Genau diese Fokussierung auf das Schreiben selbst macht Hammer für die Zielgruppe interessant.

FAQ:

  • Brauche ich den Sync-Server, um Hammer überhaupt nutzen zu können?
    Nein. Hammer funktioniert als Offline-First-App vollständig ohne Server. Der Sync-Server wird ausschließlich benötigt, wenn dieselben Projekte auf mehreren Geräten abgeglichen werden sollen.
  • Wie viel Hardware brauche ich für den Sync-Server?
    Die Projektdokumentation macht dazu keine Angabe. Für eine kleine Nutzergruppe dürfte ein schlanker Docker-Host ausreichen, belegte Zahlen dazu gibt es aber nicht.
  • Ist der eigene Betrieb sicher, wenn ich einfach die Docker-Compose-Datei starte?
    Nicht ohne weitere Schritte. Die Dokumentation verlangt ausdrücklich einen Reverse Proxy mit HTTPS, bevor der Server außerhalb des lokalen Netzwerks erreichbar gemacht wird.
  • Was passiert, wenn ich keinen eigenen Server betreiben will, aber trotzdem synchronisieren möchte?
    Dafür bietet das Projekt mit hammer.ink einen offiziellen, über Patreon finanzierten gehosteten Sync-Server als Alternative an.
  • Wie aktiv wird Hammer weiterentwickelt?
    Sehr aktiv – seit Ende Juni 2026 erschienen acht Patch- und Minor-Releases, zuletzt Version 3.8.2 am 11. August 2026, mit Commits bis mindestens zum 16. August 2026.
  • Kann ich eine bereits vorhandene PostgreSQL-Datenbank statt der eingebetteten nutzen?
    Ja, die Docker-Compose-Datei enthält eine auskommentierte Konfiguration für eine externe Postgres-Instanz als Alternative zur mitgelieferten eingebetteten Datenbank.

Fazit:

  • Hammer zeigt, wie sich eine moderne, komfortable Schreib-App und Self-Hosting-Prinzipien verbinden lassen, ohne dass eine der beiden Seiten zu kurz kommt: Die App funktioniert für sich genommen bereits vollständig offline, und wer synchronisieren möchte, muss dafür nicht zwangsläufig Daten bei einem fremden Anbieter abliefern. Die Einrichtung des Sync-Servers ist mit einem einzigen Docker-Compose-Befehl schnell erledigt – der eigentliche Aufwand liegt darin, den Server sauber mit HTTPS abzusichern, bevor er das lokale Netzwerk verlässt. Wer bereits einen Docker-Host betreibt und Wert auf die Kontrolle über die eigenen, oft unveröffentlichten Texte legt, bekommt mit Hammer ein schlankes, aktiv gepflegtes Werkzeug, das genau diese Kontrolle ermöglicht.

Quellen:

Anzeige
#Self Hosting