Häufig gestellte Fragen

Jamdesk ist eine Dokumentationsplattform, die aus deinen Markdown-Dateien Dokumentationsseiten erstellt. Schreibe in MDX und pushe zu GitHub. Deine Seite wird mit Suche, Analysen und einer llms.txt-Datei für KI-Tools bereitgestellt.

Nein. MDX ist einfacher Text mit schlichter Formatierung. Komponenten sind optional.

Ja. Wir bieten eine kostenlose 14-tägige Testphase mit allen Funktionen an.

Deine Dokumentation sind einfache MDX-Dateien in einem GitHub-Repository und nicht in einem proprietären Editor eingesperrt. Push zu GitHub und deine Seite wird in unter 60 Sekunden bereitgestellt. Es ist keine Build-Konfiguration oder CI/CD-Pipeline einzurichten. Jede Seite erhält llms.txt und einen MCP-Server. KI-Tools wie Claude und ChatGPT können deine aktuelle Dokumentation direkt lesen. Besucher erhalten einen integrierten KI-Chat-Assistenten, der Fragen anhand deiner Dokumentation beantwortet.

Die meisten Dokumentationsseiten werden in 30–60 Sekunden gebaut. Größere Seiten mit vielen Seiten können länger brauchen.

Ja. Du kannst lokal mit Hot Reload über die Jamdesk CLI (jamdesk dev) eine Vorschau anzeigen. Änderungen gehen erst live, wenn du zu GitHub pushst oder jamdesk deploy ausführst.

Ja. Führe jamdesk deploy in deinem Projektverzeichnis aus. Die CLI packt deine Dateien, lädt sie hoch und startet dann einen Build. Ein Git-Repository ist nicht erforderlich. Details findest du im CLI-Deploy-Leitfaden.

Ein Push auf deinen verbundenen GitHub-Branch. Du kannst einen Build auch über das Dashboard oder mit jamdesk deploy aus der CLI auslösen.

Ja. Gehe in deinem Projekt zu Deployments. Suche den vorherigen Build und klicke auf Rollback.

Der Pro-Tarif kostet 29 $/Monat und umfasst ein Dokumentationsprojekt. Jedes weitere Projekt kostet 15 $/Monat. Details findest du unter Tarife & Preise.

Nein. Wir bieten eine kostenlose 14-tägige Testphase an. Danach benötigst du ein Pro-Abonnement.

Wir akzeptieren Kreditkarten von Visa, Mastercard, American Express und Discover.

Wir erstatten Zahlungen innerhalb von 30 Tagen nach deiner ersten Zahlung. Kontaktiere den Support, um eine Erstattung anzufordern.

Ja. Füge unter Settings → Domains eine eigene Domain hinzu. Jamdesk stellt das SSL-Zertifikat bereit.

Meist einige Stunden. Es kann bis zu 48 Stunden dauern.

Ja. Verwende einen Reverse-Proxy (Cloudflare, AWS, nginx), um Jamdesk unter einem Unterpfad auszuliefern. Siehe Hosting unter einem Unterpfad.

Öffne dein Projekt und gehe zu Settings → Members. Gib die E-Mail-Adresse der Person im Feld Invite Member ein und klicke auf Invite. Sie erhält eine E-Mail mit einem Link zum Beitritt zum Projekt.

Eingeladene Personen benötigen ein Jamdesk-Konto. Die Einladung fordert sie auf, eines zu erstellen, falls sie noch keines haben. Bist du bereits Mitglied, zeigt der Einladungslink aber an, dass sie „bereits angenommen wurde“? Melde dich an. Du landest dann wieder im Projekt. Details zu Rollen und Mitgliederlimits findest du unter Teammitglieder.

Unbegrenzt, in jedem Tarif, ohne Aufpreis.

Teammitglieder können Builds ansehen und Neuerstellungen auslösen. Bearbeitet wird in deinem GitHub-Repository. Jeder mit Repository-Zugriff kann die Dokumentation bearbeiten.

Gehe zu Settings → Members. Klicke neben dem Mitglied, das du befördern möchtest, auf Transfer Ownership. Der neue Inhaber muss bereits ein Teammitglied sein.

In ~/.jamdeskrc, einer JSON-Datei mit den Berechtigungen 0600 (nur dein Benutzer kann sie lesen). Dort werden dein Refresh-Token, deine E-Mail-Adresse und deine Benutzer-ID gespeichert. Mit jamdesk logout wird sie gelöscht.

Dein Refresh-Token ist nicht mehr gültig. Das passiert nach Passwortänderungen, Kontolöschungen oder längerer Inaktivität. Führe jamdesk login aus, um eine neue Sitzung zu erhalten.

Ja. Die browserbasierte Anmeldung funktioniert in Headless-Umgebungen nicht. Melde dich auf deinem lokalen Rechner an. Kopiere ~/.jamdeskrc auf deinen CI-Runner. Das Refresh-Token authentifiziert von dort aus.

Führe jamdesk fix aus. Der Befehl repariert defekte interne Links, die genau ein eindeutiges korrektes Ziel haben (Tippfehler in Ankern und Ankerabweichungen zwischen Sprachen). Er bearbeitet deine lokalen .mdx-Dateien nach einer Vorschau. Die geplanten Änderungen siehst du vorab mit jamdesk fix --dry-run. Es werden nur Links geändert, deren korrigierter Anker eine echte Überschrift ist. Mehrdeutige Fälle bleiben zur manuellen Prüfung. Siehe Defekte Links automatisch beheben.

MDX (Markdown + JSX) und Standard-Markdown-Dateien.

Ja. Definiere Inline-Komponenten in MDX mit export const oder erstelle wiederverwendbare Komponenten im Verzeichnis /snippets. Für interaktive Komponenten mit Hooks verwende .tsx-Dateien mit 'use client'. Siehe Eigene React-Komponenten und Snippets.

Kein hartes Limit. Seiten mit Hunderten von Seiten werden problemlos gebaut und laufen.

Ja. Füge mit der Eigenschaft languages in deiner Navigationskonfiguration einen Sprachumschalter hinzu. Jede Sprache erhält ihre eigene Navigationsstruktur und ihren eigenen Inhalt. Siehe Mehrsprachige Unterstützung.

Nein. Du stellst die übersetzten MDX-Dateien bereit. Jamdesk erstellt das Routing, die Navigation, den Sprachumschalter und das RTL-Styling. Bringe Übersetzungen aus deinem eigenen Workflow mit (menschliche Übersetzer, maschinelle Übersetzung oder ein LLM). Lege sie in sprachpräfixierten Verzeichnissen ab (es/, fr/ usw.). Siehe Mehrsprachige Unterstützung für das Verzeichnislayout und die Konfiguration.

Ja. Jede Jamdesk-Seite enthält einen integrierten Chat-Assistenten, der Fragen von Besuchern anhand deiner Dokumentation beantwortet. Er ist standardmäßig aktiviert. Siehe KI-Chat für Details.

Nein. Der KI-Chat ist in jedem Tarif enthalten.

Ja. Setze chat.enabled in deiner docs.json auf false:

{ "chat": { "enabled": false } }

Dein nächster Build entfernt das Chat-Panel und das Tastenkürzel.

Nur deine veröffentlichten Dokumentationsseiten. Bei jedem Build werden deine Inhalte in einer Vektordatenbank indexiert. Jamdesk ruft die für die Frage eines Besuchers relevanten Abschnitte ab und sendet sie als Kontext an Claude. Die KI kann nicht auf Daten außerhalb deiner Dokumentation zugreifen.

Ja. Markiere interne Seiten mit private: true im Frontmatter oder trage ihre Pfade unter auth.password.private[] in docs.json ein. Private Seiten zeigen einen Entsperrbildschirm. Alle Seiten bleiben in einem Projekt, mit einem Repository und einem Build. Siehe Zugriffskontrolle und Passwortschutz.

Setze auth.password.enabled: true in docs.json und pushe die Änderung. Lege im Dashboard unter Project Settings → Password Protection ein Passwort fest. Besucher sehen einen Entsperrbildschirm, bis sie es eingeben. Siehe Passwortschutz.

Ja, in Enterprise-Tarifen. Single Sign-On ermöglicht Lesern die Authentifizierung über deinen Identity Provider (Okta, Google Workspace, Azure AD usw.) ohne gemeinsame Passwörter, mit vollständigem Audit-Trail und sofortiger Deprovisionierung. Siehe SSO oder Enterprise-Vertrieb kontaktieren.

Meist nicht. Verwende ein Projekt mit private: true auf den internen Seiten. So behältst du ein Repository und ein Dashboard. Verwende zwei Projekte nur, wenn die Zielgruppen eigenes Branding, eigene Domains oder eigene Analysen benötigen. Siehe Zugriffskontrolle für die Muster.

Editoren schreiben die Dokumentation, indem sie MDX in dein verbundenes GitHub-Repository committen. Ein Push löst nur dann einen Build aus, wenn die Person, die gepusht hat, Mitglied des Jamdesk-Projekts oder eines von dir autorisierten Automatisierungskontos ist. Leser sehen die veröffentlichte Seite: alle (öffentlich), alle mit dem Passwort (Passwortmodus) oder alle, die sich über deinen IdP anmelden (SSO). Dashboard-Teammitglieder steuern Builds, Analysen und Einstellungen. Die Mitgliedschaft lässt ihre Pushes ebenfalls bauen. Siehe Zugriffskontrolle.