https://valoryx.org/de/blog/ Recent content in Blog on Valoryx Hugo de Mon, 13 Apr 2026 00:00:00 +0000 https://valoryx.org/de/blog/ai-native-documentation/ Mon, 13 Apr 2026 00:00:00 +0000 https://valoryx.org/de/blog/ai-native-documentation/ Dokumentation hat ein Pflegeproblem. Sie schreiben eine Anleitung, veröffentlichen sie, und innerhalb von drei Monaten ist sie veraltet. Die API hat sich geändert. Das Konfigurationsformat wurde refaktoriert. Eine Abhängigkeit wurde ersetzt. Die Screenshots zeigen eine Oberfläche, die nicht mehr existiert. Die Lösung ist nicht „bessere Dokumentation schreiben" oder „eine Dokumentationskultur aufbauen." Teams versuchen das seit Jahrzehnten. Die Lösung ist, Dokumentation bewusst mit dem Code zu verknüpfen, den sie beschreibt — sodass die Dokumentation es mitbekommt, wenn sich der Code ändert. https://valoryx.org/de/blog/documentation-platform-cost/ Thu, 09 Apr 2026 00:00:00 +0000 https://valoryx.org/de/blog/documentation-platform-cost/ Pro-Benutzer-Preise klingen auf den ersten Blick vernünftig. Fünf Benutzer für 8 $/Monat? Das sind 40 $. Ihr Team kann sich 40 $ leisten. Aber Dokumentation ist eines dieser Tools, bei dem die Anzahl der Personen, die Zugang haben sollten, ständig wächst. Ingenieure müssen schreiben. Produktmanager müssen reviewen. Support-Mitarbeiter müssen nachschlagen. Neue Mitarbeiter müssen lesen und kommentieren. Plötzlich sind Sie nicht bei 5 Plätzen — Sie sind bei 50, und diese „erschwinglichen" 8 $/Platz sind 400 $/Monat für ein Tool, das Textdateien speichert. https://valoryx.org/de/blog/docs-for-open-source/ Mon, 06 Apr 2026 00:00:00 +0000 https://valoryx.org/de/blog/docs-for-open-source/ Open-Source-Projekte leben oder sterben mit ihrer Dokumentation. Eine Bibliothek mit guter Dokumentation wird adoptiert. Eine Bibliothek mit einem dürren README und einer „Lies den Code"-Einstellung wird von jemandem geforkt, der bessere Dokumentation schreibt — oder einfach ignoriert. Aber die meisten Dokumentationstools sind für Unternehmen gebaut, nicht für OSS-Maintainer. Sie berechnen pro Benutzer, pro Seite oder pro Workspace. Für ein Projekt, das von Freiwilligen ohne Budget gepflegt wird, ist das ein Ausschlusskriterium. https://valoryx.org/de/blog/documentation-search-works/ Thu, 02 Apr 2026 00:00:00 +0000 https://valoryx.org/de/blog/documentation-search-works/ Sie tippen eine Abfrage in die Suchleiste Ihrer Dokumentation. Ergebnisse erscheinen. Aber was passiert zwischen dem Tastendruck und den Ergebnissen? Bei den meisten Dokumentationsplattformen lautet die Antwort entweder „nicht viel" (einfacher Keyword-Abgleich, der offensichtliche Ergebnisse übersieht) oder „eine Menge Infrastruktur" (ein Elasticsearch-Cluster, den Ihr Ops-Team warten muss). Es gibt einen Mittelweg, den die meisten Teams nicht kennen: eingebettete Volltextsuche. DocPlatform verwendet Bleve, eine in Go geschriebene Suchbibliothek, die direkt in das Binary kompiliert wird. https://valoryx.org/de/blog/single-binary-architecture/ Mon, 30 Mar 2026 00:00:00 +0000 https://valoryx.org/de/blog/single-binary-architecture/ Die meisten Dokumentationsplattformen werden als Stack ausgeliefert. Sie bekommen eine Node.js-Anwendung, eine PostgreSQL-Datenbank, einen Redis-Cache, einen Elasticsearch-Cluster für die Suche und einen Nginx-Reverse-Proxy, der alles zusammenhält. Fünf Dienste, fünf Dinge, die kaputtgehen können, fünf Dinge, die überwacht, gepatcht und aktualisiert werden müssen. DocPlatform wird als eine Datei ausgeliefert. Herunterladen, ausführen, fertig. Das ist kein Marketing-Trick. Es ist eine Architekturentscheidung, die wir am ersten Tag getroffen haben, und jede Designentscheidung seitdem folgt daraus. https://valoryx.org/de/blog/keep-docs-up-to-date/ Thu, 26 Mar 2026 00:00:00 +0000 https://valoryx.org/de/blog/keep-docs-up-to-date/ Jedes Engineering-Team hat dasselbe Dokumentationsproblem. Jemand schreibt gründliche Dokumentation während eines Launches. Sechs Monate später hat sich die API geändert, das Konfigurationsformat ist anders, und drei Seiten verweisen auf ein Feature, das umbenannt wurde. Niemand hat die Dokumentation aktualisiert, weil das Aktualisieren von Dokumentation eine separate Aufgabe vom Code-Schreiben ist, und separate Aufgaben werden vergessen. Der übliche Ratschlag — „Machen Sie Dokumentation zum Teil Ihrer Kultur" — funktioniert nicht. Kultur überlebt keinen Termindruck. https://valoryx.org/de/blog/docs-regulated-industries/ Mon, 23 Mar 2026 00:00:00 +0000 https://valoryx.org/de/blog/docs-regulated-industries/ Wenn Sie im Gesundheitswesen, in der Verteidigung, im Finanzwesen oder in einer anderen Branche arbeiten, in der Datenresidenz wichtig ist, haben Sie das Gespräch bereits geführt: „Können wir dieses SaaS-Tool verwenden, oder muss es durch eine sechsmonatige Sicherheitsüberprüfung?" Bei den meisten Cloud-Dokumentationsplattformen ist die Antwort die Überprüfung — und sie endet oft mit „Nein." Das Problem ist nicht, dass Cloud-Tools unsicher sind. Die meisten von ihnen sind in Sachen Sicherheit kompetent. https://valoryx.org/de/blog/bidirectional-git-sync/ Thu, 19 Mar 2026 00:00:00 +0000 https://valoryx.org/de/blog/bidirectional-git-sync/ Jede Dokumentationsplattform mit einer Git-Integrationsseite macht dasselbe Versprechen: Ihre Dokumentation lebt in Git, Ihr Team bearbeitet im Browser, und alles bleibt synchron. In der Praxis sind die meisten dieser Integrationen Einweg-Spiegel, die auseinanderfallen, sobald zwei Personen aus verschiedenen Richtungen bearbeiten. Wir haben in einem früheren Beitrag geschrieben, warum das passiert. Dieser geht tiefer in die Lösung: wie Valoryx bidirektionalen Sync mit dem Content-Ledger-Muster implementiert und warum dieser Ansatz die Szenarien bewältigt, an denen andere Tools scheitern. https://valoryx.org/de/blog/mcp-documentation-guide/ Mon, 16 Mar 2026 00:00:00 +0000 https://valoryx.org/de/blog/mcp-documentation-guide/ Model Context Protocol (MCP) ist ein offener Standard, der KI-Assistenten die Interaktion mit externen Tools und Datenquellen über eine strukturierte Schnittstelle ermöglicht. Anstatt Text in ein Chat-Fenster zu kopieren und darauf zu hoffen, dass das Modell den Kontext versteht, gibt MCP dem Assistenten direkten, typisierten Zugriff auf Ihre Systeme — Dateien lesen, Suchen ausführen, Inhalte erstellen, alles über wohldefinierte Tool-Aufrufe. Für Dokumentationsteams verändert dies den Workflow grundlegend. Ihr KI-Assistent ist nicht mehr ein Textgenerator, der mit veraltetem Kontext arbeitet, sondern wird zu einem Teilnehmer, der Ihre tatsächliche Dokumentation liest, Ihre Wissensbasis durchsucht und Änderungen vornimmt, die Sie prüfen können, bevor sie live gehen. https://valoryx.org/de/blog/internal-docs-developers-use/ Thu, 12 Mar 2026 00:00:00 +0000 https://valoryx.org/de/blog/internal-docs-developers-use/ Jede Engineering-Organisation hat interne Dokumentation. Und in den meisten davon ist diese Dokumentation unvollständig, veraltet oder wird ignoriert. Laut der 2024 Stack Overflow Developer Survey betrachtet eine Mehrheit der Entwickler fehlende oder schlechte Dokumentation als erhebliche Produktivitätshürde. Das ist kein Disziplinproblem. Es ist ein Werkzeugproblem. Interne Dokumentation scheitert aus spezifischen, behebbaren Gründen. Die Werkzeuge machen das Schreiben schmerzhaft. Der Inhalt veraltet, weil niemand einen Workflow hat, um ihn aktuell zu halten. https://valoryx.org/de/blog/docs-should-be-in-git/ Mon, 09 Mar 2026 00:00:00 +0000 https://valoryx.org/de/blog/docs-should-be-in-git/ Hier ist eine Bestandsaufnahme dessen, was ein typisches Engineering-Team in Git aufbewahrt: Anwendungsquellcode Infrastrukturdefinitionen (Terraform, Pulumi, CloudFormation) CI/CD-Pipeline-Konfigurationen Datenbankmigrationen API-Spezifikationen (OpenAPI, Protobuf) Deployment-Manifeste (Kubernetes, Docker Compose) Umgebungskonfigurations-Templates Und hier ist, was normalerweise außerhalb von Git lebt: Dokumentation Das ist merkwürdig. Dokumentation beschreibt das System. Sie ändert sich, wenn sich das System ändert. Sie braucht Review, Versionierung, Zuordnung und die Möglichkeit zum Rollback. Jedes andere Artefakt, das diese Eigenschaften teilt, lebt in Git. https://valoryx.org/de/blog/documentation-as-code/ Thu, 05 Mar 2026 00:00:00 +0000 https://valoryx.org/de/blog/documentation-as-code/ „Documentation as Code" wird häufig verwendet. Im einfachsten Sinne bedeutet es, Dokumentation genauso zu behandeln wie Quellcode: in der Versionskontrolle gespeichert, in Klartext geschrieben, über Pull Requests überprüft und durch CI/CD gebaut. Aber zwischen der Idee und der guten Umsetzung klafft eine Lücke. Dieser Leitfaden erklärt, was Docs-as-Code ist, welche Ansätze existieren und wo jeder an seine Grenzen stößt. Warum Docs-as-Code wichtig ist Softwareteams haben bereits Workflows für das Änderungsmanagement. Code durchläuft Versionskontrolle, Review, Tests und Deployment. https://valoryx.org/de/blog/self-host-docs-5-minutes/ Mon, 02 Mar 2026 00:00:00 +0000 https://valoryx.org/de/blog/self-host-docs-5-minutes/ Die meisten selbstgehosteten Dokumentationstools erfordern eine Datenbank, einen Reverse-Proxy und einen halben Nachmittag YAML-Bearbeitung, bevor Sie einen Willkommensbildschirm sehen. DocPlatform ist ein einzelnes Go-Binary ohne externe Abhängigkeiten. Diese Anleitung bringt Sie in etwa fünf Minuten von Null zur veröffentlichten Dokumentation. Voraussetzungen Sie benötigen einen Linux-, macOS- oder Windows-Rechner. Das war’s. Kein Docker, kein PostgreSQL, keine Node.js-Laufzeitumgebung. DocPlatform kompiliert zu einem einzelnen statischen Binary — die Go-Laufzeitumgebung ist eingebettet. Falls Sie sich für die Implementierungssprache interessieren: Go erzeugt eigenständige ausführbare Dateien, die ohne Installation auf dem Host laufen. https://valoryx.org/de/blog/notion-alternative-self-hosted/ Sun, 01 Mar 2026 00:00:00 +0000 https://valoryx.org/de/blog/notion-alternative-self-hosted/ Notion ist überall. Design-Teams, Produkt-Teams, Marketing-Teams — und zunehmend auch Entwicklerteams nutzen es für Dokumentation. Es funktioniert, bis zu einem gewissen Punkt. Dann stößt man an die Grenzen, und die Grenzen sind scharf. Was Notion richtig macht Der Editor ist schnell und flexibel. Datenbankansichten sind nützlich für Roadmaps. Für nicht-technische Dokumentation ist Notion schwer zu übertreffen. Wo Notion für technische Teams scheitert Keine git-Integration. Die Codebasis lebt in git. Aber die Dokumentation lebt in Notions proprietärer Datenbank, von allem anderen abgekoppelt. https://valoryx.org/de/blog/self-hosted-docs-guide/ Fri, 27 Feb 2026 00:00:00 +0000 https://valoryx.org/de/blog/self-hosted-docs-guide/ Self-hosted Dokumentation erlebt gerade einen Aufschwung. Nachdem SaaS-Plattformen jahrelang die Preise erhöht, die Nutzungsbedingungen geändert und ohne Vorwarnung abgeschaltet haben, entscheiden sich immer mehr Teams dafür, ihre eigene Dokumentationsinfrastruktur zu betreiben. Die Gründe liegen auf der Hand: Dateneigentum, Kostenkontrolle, Compliance und die Gewissheit, dass die eigene Wissensdatenbank nicht verschwindet, wenn ein Startup das Geld ausgeht. Die Landschaft der self-hosted Dokumentationstools ist jedoch überfüllt und unübersichtlich. Es gibt Wiki-Plattformen, Static-Site-Generatoren, Wissensdatenbanken und Hybridlösungen — jede mit unterschiedlichen Kompromissen. https://valoryx.org/de/blog/gitbook-vs-valoryx/ Wed, 25 Feb 2026 00:00:00 +0000 https://valoryx.org/de/blog/gitbook-vs-valoryx/ GitBook ist eine der beliebtesten Dokumentationsplattformen für Entwicklerteams. Es bietet einen ausgefeilten Editor, solide Kollaborationsfunktionen und ansprechend aussehende veröffentlichte Docs. Wir haben Valoryx entwickelt, um Probleme zu lösen, die GitBook nicht adressiert — in erster Linie in Bezug auf git-Eigentümerschaft, Self-Hosting und Preistransparenz. Hier ist, wo jedes Tool glänzt und wo jedes an seine Grenzen stößt. Editor-Erfahrung GitBook hat einen hervorragenden Web-Editor. Block-basiert, sauber, responsiv. Unterstützt Markdown-Shortcuts, Code-Blöcke, Tabellen, Einbettungen. Kollaborationsfunktionen sind gut durchdacht. https://valoryx.org/de/blog/why-git-sync-breaks/ Sun, 22 Feb 2026 00:00:00 +0000 https://valoryx.org/de/blog/why-git-sync-breaks/ Wenn man technische Dokumentation pflegt, wurde man wahrscheinlich schon einmal von “Vollständiger git-Integration” enttäuscht. Man verbindet das Repository, pusht einen Commit aus der IDE — und alles bricht zusammen. Merge-Konflikte. Verlorene Bearbeitungen. Seiten, die stillschweigend zurückgesetzt werden. Das ist kein Bug. Es ist ein grundlegender Designfehler. Die drei Arten, wie git-Sync scheitert 1. Einseitiger Spiegel, kein echter Sync Die meisten Plattformen behandeln git als Backup-Ziel. Bearbeitungen fließen von der Web-UI in git, aber Änderungen, die aus einer IDE gepusht werden, werden ignoriert oder verursachen Konflikte.