FAQ

Häufig gestellte Fragen

Praktische Kurzanleitungen zur Serviceeinrichtung, zum Zugriff und zu allgemeinen Kundenaktionen.

> Einen oeffentlichen SSH-Schluessel im Terminal erstellen

Erstelle einen SSH Public Key fuer den Zugriff und teile nur den Public Key.
faq/oeffentlichen-ssh-schluessel-erstellen

Nur den oeffentlichen Schluessel verwenden

SSH nutzt ein Schluesselpaar. Fuege in den Service-Einstellungen nur den oeffentlichen Schluessel ein, meist die .pub-Datei. Der private Schluessel bleibt auf deinem Geraet.

Schritte im Terminal

  1. Oeffne Terminal, Windows Terminal oder PowerShell.
  2. Fuehre aus: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Akzeptiere den Standardpfad oder waehle einen sicheren Pfad.
  4. Zeige den oeffentlichen Schluessel mit: cat ~/.ssh/id_ed25519.pub.
  5. In Windows PowerShell verwende: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Kopiere die ganze ssh-ed25519-Zeile in das Feld SSH public key.

Vor dem Einfuegen pruefen

Kopiere nicht den privaten Schluessel. Wenn du eine Passphrase setzt, bewahre sie sicher auf.

> Einen SSH-Schluessel grafisch in Windows erstellen

Windows-Anleitung mit PuTTYgen zum Erstellen eines SSH-Schluessels.
faq/ssh-schluessel-grafisch-in-windows-erstellen

Nur der oeffentliche Teil

PuTTYgen erstellt einen oeffentlichen und einen privaten Schluessel. Fuege in Cli>_ nur den oeffentlichen Schluessel hinzu und behalte den privaten lokal.

Schritte in Windows

  1. Oeffne PuTTYgen.
  2. Waehle EdDSA / Ed25519, wenn verfuegbar.
  3. Nutze RSA 4096 nur als Ausweichoption.
  4. Klicke Generate und bewege die Maus, bis der Schluessel erstellt ist.
  5. Speichere den privaten Schluessel auf deinem Computer.
  6. Kopiere den Text des oeffentlichen Schluessels in das Feld SSH public key.

Keine geheimen Daten teilen

Sende keine .ppk-Dateien, privaten Schluessel, Passphrases, Passwoerter oder Tokens an Support oder Formulare.

> Eigene Domain verbinden

Prüfe vor der Umstellung autoritatives DNS, exakten Hostname, Record-Typ, Apex oder Subdomain und alte Konflikte.
faq/eigene-domain-verbinden

Der exakte Hostname entscheidet

Kläre zuerst, ob du eine Apex-Domain wie example.com oder eine Subdomain wie app.example.com verbindest. Jede Variante kann andere DNS-Record-Typen und Anbietergrenzen haben.

Vor DNS-Änderungen

  1. Prüfe, wo die autoritativen DNS-Records der Domain geändert werden.
  2. Entferne oder ändere konkurrierende A/AAAA-, CNAME-, ALIAS-, ANAME- oder Redirect-Records.
  3. Nutze den für Service und Hostname empfohlenen Record-Typ.
  4. Warte nach der Änderung auf DNS-Propagation und teste dann finales HTTPS.

Sicher zurückrollen

Schalte das alte Hosting erst ab, wenn der neue Hostname korrekt antwortet. Sende bei Problemen Domain, erwartetes Ziel und öffentlich sichtbares DNS-Ergebnis, nicht Registrar-Zugänge.

> DNS-Zone uebergeben

A/AAAA zeigen auf Adressen, CNAME auf Aliase, MX auf Mail und TXT auf Verifikation, SPF, DKIM oder DMARC.
faq/dns-zone-uebergeben

Records nicht blind mischen

Jeder DNS-Typ löst eine andere Aufgabe. A und AAAA zeigen auf IP-Adressen, CNAME ist ein Alias für Subdomains, MX routet Mail, TXT trägt Verifikation und Mail-Policies, CAA begrenzt Zertifizierungsstellen.

Beim Kopieren von Records

  1. Kopiere Name, Typ und Wert exakt nach Serviceanweisung.
  2. Setze CNAME nicht auf einen Hostname, der nach DNS-Regeln bereits andere Records hat.
  3. Lege DKIM unter dem Selector des Anbieters und DMARC meist unter _dmarc an.
  4. Ändere CAA vorsichtig, weil falsche Werte Zertifikate blockieren können.

Wenn DNS nicht funktioniert

Sende Hostname, Record-Typ, erwarteten Wert und öffentlich sichtbares Ergebnis. Sende keinen Login zur DNS-Verwaltung und keine Screenshots mit sensiblen Zugangsdaten.

> Kontoregistrierung und erste Anmeldung

Lege ein Arbeitskonto an, ergänze Rechnungsdaten und nutze eine Team-E-Mail, die langfristig erreichbar bleibt.
faq/account-registration-and-login

Ein Konto für Bestellungen und Betrieb

Das Konto ist der zentrale Ort für Bestellungen, Rechnungsdaten, Services, Domains und Supportkommunikation. Verwende am besten eine Arbeitsadresse, auf die dein Team auch bei Rollenwechseln Zugriff behält.

Vor der ersten Bestellung

  1. Registriere dich mit einer Arbeits-E-Mail-Adresse.
  2. Bestätige die E-Mail, wenn die Seite es verlangt.
  3. Ergänze Rechnungsdaten vor einer kostenpflichtigen Bestellung.
  4. Aktiviere Zwei-Faktor-Anmeldung, sobald sie für dein Konto verfügbar ist.

Teamzugriff sauber lösen

Sende Passwörter nicht per Chat oder E-Mail an Kolleginnen und Kollegen. Nutzt einen internen Passwortmanager oder fragt nach einem passenden Teamprozess; der Support braucht dein Passwort nicht.

> Wie Prepaid-Guthaben funktioniert

Das Guthaben zeigt Saldo, geschätzte Laufzeit, täglichen Verbrauch aktiver Services und eine sichtbare Löschfrist bei Sperrung.
faq/prepaid-credit-how-it-works

Guthaben sinkt während der Service läuft

Bei Prepaid-Services wird der Saldo nach aktiver Laufzeit und gewählten Parametern verbraucht. Der Tagespreis hilft einzuschätzen, wie lange ein Service mit aktuellem Guthaben läuft und wann eine Löschfrist sichtbar werden kann.

Sperrung vermeiden

  1. Prüfe nach dem Login Saldo und Laufzeitschätzung.
  2. Kontrolliere den neuen Tagespreis vor Bestellung oder Änderung.
  3. Lade Guthaben mit Reserve auf, nicht erst am letzten Tag.
  4. Lies bei gesperrten Services sofort die mögliche Datenlöschfrist.

Wenn der Saldo unerwartet wirkt

Sende Bestellnummer, Servicename und den Zeitraum, den du prüfen möchtest. Sende keine Kartendaten, Passwörter, privaten Schlüssel oder vollständige Auszüge mit sensiblen Angaben.

> Monatsschätzung, Jahresschätzung und echter Tagesverbrauch

Monats- und Jahrespreise dienen dem Vergleich; bei Prepaid-Services zählt der tägliche Verbrauch nach bestätigter Änderung.
faq/billing-periods-and-credit-burn

Vergleich ist kein Rechnungskalender

Nutze die Monatsschätzung als Vergleich über 31 Tage und die Jahresschätzung über 372 Tage. Der tatsächliche Guthabenverbrauch entsteht durch aktive Laufzeit und bestätigte Konfiguration.

Preisänderungen prüfen

  1. Vergleiche den Tagesverbrauch vor und nach der Änderung.
  2. Mehr CPU, RAM, Speicher oder kostenpflichtige Optionen erhöhen den Verbrauch.
  3. Eine Änderung gilt erst nach Bestätigung, gegebenenfalls Zahlung und Anwendung.
  4. Speichere Bestellbestätigung und Guthabenhistorie für die Buchhaltung.

Konkrete Zeiträume klären

Für eine Prüfung helfen Bestellnummer, Servicename und genaue Daten. Sende keine Bankdaten, vollständigen Zahlungsbelege oder Screenshots mit unnötigen personenbezogenen Daten.

> Bestellstatus nach der Zahlung

Nach der Zahlung kann eine Bestellung noch auf Bestätigung warten; erstelle Duplikate erst nach klarer Stornierung oder Ablauf.
faq/order-status-and-payment-confirmation

Pending ist nicht automatisch fehlgeschlagen

Nach der Zahlungsseite kann die Bestellung noch auf Bestätigung des Zahlungsanbieters warten. Solange der Status nicht eindeutig fehlgeschlagen oder abgelaufen ist, kann eine doppelte Bestellung die Zuordnung erschweren.

Nach der Zahlung

  1. Kehre nach Abschluss der Zahlung zu Cli>_ zurück.
  2. Prüfe im Konto den Bestellstatus und Hinweise zur Zahlung.
  3. Warte bei ausstehendem Status auf die Bestätigung des Anbieters.
  4. Sende bei Problemen Bestellnummer und sichtbare Zahlungsreferenz an den Support.

Nicht benötigte Zahlungsdaten

Der Support braucht keine Kartendaten, kein Login-Passwort und keinen vollständigen Bankbeleg. Bestellnummer, Zahlungszeit, sichtbarer Status und ein geschwärzter Screenshot reichen aus.

> Angaben, die die Serviceeinrichtung beschleunigen

Bereite Servicename, Domain, Speichergröße, Kontakt-E-Mail und öffentlichen SSH-Schlüssel vor; sensible Werte gehören nicht in Formulare.
faq/service-setup-information-needed

Präzise Eingaben sparen Zeit

Bestellformulare sind für öffentliche oder unkritische Werte gedacht: Servicename, Domain, DNS-Plan, Speichergröße, CPU, RAM, Admin-E-Mail oder öffentlicher SSH-Schlüssel. Passwörter und private Schlüssel gehören nicht hinein.

Vor dem Klick auf Bestellen

  1. Wähle einen Servicenamen, den dein Team wiedererkennt.
  2. Entscheide zwischen eigener Domain und temporärem System-Hostname.
  3. Bereite den öffentlichen SSH-Schlüssel vor, wenn der Service ihn benötigt.
  4. Prüfe Speicher und Ressourcen passend zur Anwendung.

Sensible Werte zurückhalten

Wenn du unsicher bist, ob eine Angabe sensibel ist, frage ohne sie mitzuschicken. Private Schlüssel, Passwörter, Datenbankexporte und komplette Konfigurationsdateien gehören nicht in Chat oder Bestellung.

> CPU, RAM, Speicher oder Aufbewahrung nach der Bestellung ändern

Ändere einen bestehenden Service über sein Detail, nicht per neuer Bestellung; Preis, Tagesverbrauch, Neustart und Ausfallrisiko können sich ändern.
faq/change-service-resources-after-order

Du änderst einen bestehenden Service

Wenn ein Service bereits läuft, ändere Ressourcen aus seinem Detail heraus. Eine neue Bestellung würde einen weiteren Service erzeugen und nicht den bestehenden anpassen; Preis, Tagesverbrauch und Betriebsverhalten können sich ändern.

Vor der Bestätigung

  1. Prüfe aktuelle CPU, RAM, Speicher, Backups und Offsite Archive-Aufbewahrung.
  2. Kontrolliere neuen Tagespreis und Guthabenauswirkung.
  3. Lies Hinweise zu Neustart, Wartung oder Ausfall.
  4. Exportiere wichtige Daten vor riskanten Änderungen selbst.

Wenn die Änderung anders ausfällt

Sende Servicename, Änderungszeit, sichtbaren Status und Fehlermeldung. Sende keine privaten Schlüssel oder Passwörter; öffentlicher Kontext und geschwärzter Screenshot reichen.

> Service kündigen und Datenlöschfrist

Ein bereits bereitgestellter Service wird zuerst gesperrt, zeigt eine konfigurierbare Löschfrist und kann danach dauerhaft bereinigt werden.
faq/cancel-service-and-data-retention

Kündigung ist nicht immer sofortige Löschung

Bei einem bereits bereitgestellten Service wird der Service zuerst gesperrt und zeigt eine konfigurierbare Löschfrist, bis zu der Wiederherstellung oder Export geklärt werden kann. Unbezahlte ausstehende Bestellungen ohne laufende Daten können anders behandelt werden.

Vor der Kündigung prüfen

  1. Erstelle einen eigenen Export der langfristig benötigten Daten.
  2. Lies Datum und Uhrzeit der geplanten Löschung beim gesperrten Service.
  3. Verwechsle Backups und Offsite Archive nicht mit der Löschung im Service-Lebenszyklus.
  4. Kontaktiere den Support vor der Löschfrist, wenn du unsicher bist.

Nach der Frist kann es zu spät sein

Nach Ablauf der sichtbaren Frist solltest du nicht mehr von verfügbaren Daten ausgehen. Sende bei Fragen Bestellnummer und Servicename, keine Datenbankexporte oder Zugangsdaten.

> Backups und Wiederherstellungsanfragen

Backups dienen der operativen Wiederherstellung und ersetzen keinen Export; eine Wiederherstellung kann neuere Daten überschreiben.
faq/backups-and-restore-requests

Backup ist kein Archiv und kein Export

Die Backup-Aufbewahrung hängt vom Produkt und den gewählten Optionen ab. Backups helfen bei operativer Wiederherstellung nach Fehlern, ersetzen aber keinen eigenen Export, kein Auditarchiv und kein Offsite Archive. Eine Wiederherstellung kann neuere Änderungen überschreiben.

Wiederherstellungsanfrage vorbereiten

  1. Nenne Servicename und Bestellnummer.
  2. Beschreibe den ungefähren Zeitpunkt, zu dem du zurück möchtest.
  3. Sage, ob der ganze Service oder ein bestimmter Teil wiederhergestellt werden soll, falls unterstützt.
  4. Füge sichtbare Fehler oder Kontext ohne Passwörter und private Schlüssel hinzu.

Auswirkung vorab einplanen

Wenn der Service inzwischen neue Daten angenommen hat, kann die Wiederherstellung sie durch einen älteren Stand ersetzen. Informiere dein Team und exportiere alles, was du nicht verlieren möchtest.

> Wofür Offsite Archive gedacht ist

Offsite Archive hält entfernte Archivkopien getrennt von kurzen Betriebsbackups und vom Service-Lebenszyklus.
faq/offsite-archive-purpose

Archiv außerhalb des Normalbetriebs

Offsite Archive ist für entfernte Archivkopien und längere Datenaufbewahrung gedacht. Es ist kein Live-Datenträger für die Anwendung, kein Ersatz für lokalen Export und nicht dasselbe wie kurze operative Backups.

Wann aktivieren

  1. Nutze es für Daten, die außerhalb des normalen Servicebetriebs aufbewahrt werden sollen.
  2. Wähle Aufbewahrungstage nach Compliance, Geschäftsbedarf oder Recovery-Ziel.
  3. Beachte, dass die Kosten mit Datenmenge und Aufbewahrungsdauer steigen.
  4. Plane bei großen Datenmengen Archiv und eigenen Exportprozess gemeinsam.

Preislogik verstehen

Grundlage sind MB-days: gespeicherte Datenmenge multipliziert mit gespeicherten Tagen. Die Rate wird als EUR/GB/Monat angezeigt und auf ganze Cent gerundet.

> CPU, RAM und Speicher für VPS wählen

Wähle die VPS-Größe nach Anwendung, Datenbank, Cache, Logs und Wachstum; OOM oder Swap sind Signale für mehr RAM.
faq/vps-cpu-ram-and-disk-sizing

Von echter Last ausgehen

Eine kleine statische Website braucht anderes als Datenbank, Java-Anwendung, Suche oder Build-Container. Plane Anwendungsspeicher, Cache, Datenbank, Logs, Uploads und Wachstumspuffer ein.

Anzeichen für einen zu kleinen Plan

  1. Erhöhe RAM bei OOM, out of memory, process killed oder dauerhaftem Swapping.
  2. Erhöhe CPU bei anhaltender Rechenlast, Kompression, Builds oder stark beschäftigten Workern.
  3. Erhöhe Speicher, bevor Dateisystem, Logs oder Datenbank voll laufen.
  4. Prüfe nach jeder Änderung, ob die Anwendung nicht mehr an das alte Limit stößt.

Dimensionierungsfragen gut stellen

Hilfreich sind Servicename, Anwendungstyp, sichtbarer Fehler, ungefährer Zeitpunkt und aktuelle CPU-, RAM- und Speicherwahl. Sende keine Passwörter, privaten Schlüssel oder internen Konfigurationsdateien.

> Wann eine öffentliche IP für VPS sinnvoll ist

Eine dedizierte öffentliche IP hilft bei Allowlists, Inbound-Zugriff, stabiler Outbound-Quelle oder adressgebundenen Diensten.
faq/vps-public-ip-options

Zuerst Kommunikationsrichtung klären

Eine öffentliche IP ist nicht für jeden Service automatisch nötig. Häufig geht es um Anforderungen externer Partner, Anbieter oder Firewalls an Allowlist, stabile Outbound-Quelle oder Inbound-Zugriff auf bestimmte Ports.

Fragen vor der IP-Bestellung

  1. Frage den Partner, ob Inbound, Outbound oder beide Richtungen allowlisted werden.
  2. Nutze DNS-Namen statt numerischer IPs, wo das externe System es erlaubt.
  3. Öffne nur Ports, die die Anwendung wirklich braucht.
  4. Sende die Allowlist-Anforderung an den Support, bevor du Produktionszugriff änderst.

Nicht alles öffnen

Eine öffentliche IP bedeutet nicht, alle Ports zu öffnen. Plane Zugriff nach den minimal nötigen Diensten und sende keine Passwörter, privaten Schlüssel oder sensible Firewall-Notizen.

> Geteilter SSH-Zugang zu VPS

Ohne gekaufte öffentliche IP nutzt VPS einen geteilten SSH-Endpunkt mit hohem Port; mit öffentlicher IP kommt ein zweiter direkter SSH-Weg hinzu.
faq/shared-ssh-access-for-vps

Warum der geteilte SSH-Zugang hohe Ports nutzt

Mehrere VPS-Services können denselben öffentlichen SSH-Endpunkt teilen, deshalb erhält jeder Service einen eigenen hohen Port. Der Port gehört zum Routing zu deinem Service; ohne ihn ließe sich die Verbindung nicht eindeutig an den richtigen VPS zustellen.

Verbindung nach Zugangstyp

  1. Kopiere bei geteiltem SSH den SSH-Benutzernamen, öffentlichen Host und hohen Port aus dem Service.
  2. Nutze das Format ssh -p <port> <username>@<public-host>.
  3. Wenn der Service eine gekaufte öffentliche IP hat, kann zusätzlich ein zweiter SSH-Endpunkt direkt auf dieser IP oder ihrem DNS-Namen verfügbar sein.
  4. Nutze den privaten Schlüssel nur lokal über SSH-Client oder Agent; für Support reichen öffentlicher Host, Port, Benutzername und sichtbarer Fehler.

Zweiter Weg mit öffentlicher IP

Die öffentliche IP ersetzt den geteilten SSH-Endpunkt nicht rückwirkend; sie ergänzt einen separaten Zugriff für Allowlists, Monitoring oder direkte Anbindung. Du kannst daher geteilten Host mit hohem Port und direkten Host oder IP gleichzeitig sehen.

> Checkliste vor dem Verbinden einer eigenen Domain

Prüfe vor der Umstellung autoritatives DNS, exakten Hostname, Record-Typ, Apex oder Subdomain und alte Konflikte.
faq/custom-domain-readiness-checklist

Der exakte Hostname entscheidet

Kläre zuerst, ob du eine Apex-Domain wie example.com oder eine Subdomain wie app.example.com verbindest. Jede Variante kann andere DNS-Record-Typen und Anbietergrenzen haben.

Vor DNS-Änderungen

  1. Prüfe, wo die autoritativen DNS-Records der Domain geändert werden.
  2. Entferne oder ändere konkurrierende A/AAAA-, CNAME-, ALIAS-, ANAME- oder Redirect-Records.
  3. Nutze den für Service und Hostname empfohlenen Record-Typ.
  4. Warte nach der Änderung auf DNS-Propagation und teste dann finales HTTPS.

Sicher zurückrollen

Schalte das alte Hosting erst ab, wenn der neue Hostname korrekt antwortet. Sende bei Problemen Domain, erwartetes Ziel und öffentlich sichtbares DNS-Ergebnis, nicht Registrar-Zugänge.

> DNS-Record-Typen für Services

A/AAAA zeigen auf Adressen, CNAME auf Aliase, MX auf Mail und TXT auf Verifikation, SPF, DKIM oder DMARC.
faq/dns-record-types-for-services

Records nicht blind mischen

Jeder DNS-Typ löst eine andere Aufgabe. A und AAAA zeigen auf IP-Adressen, CNAME ist ein Alias für Subdomains, MX routet Mail, TXT trägt Verifikation und Mail-Policies, CAA begrenzt Zertifizierungsstellen.

Beim Kopieren von Records

  1. Kopiere Name, Typ und Wert exakt nach Serviceanweisung.
  2. Setze CNAME nicht auf einen Hostname, der nach DNS-Regeln bereits andere Records hat.
  3. Lege DKIM unter dem Selector des Anbieters und DMARC meist unter _dmarc an.
  4. Ändere CAA vorsichtig, weil falsche Werte Zertifikate blockieren können.

Wenn DNS nicht funktioniert

Sende Hostname, Record-Typ, erwarteten Wert und öffentlich sichtbares Ergebnis. Sende keinen Login zur DNS-Verwaltung und keine Screenshots mit sensiblen Zugangsdaten.

> DNS-Propagation und TTL ohne Minutengarantie

TTL bestimmt, wie lange Resolver alte Antworten behalten; während der Umstellung können alte und neue Ergebnisse nebeneinander existieren.
faq/dns-propagation-and-ttl

Propagation ist Cache, keine Magie

Bei DNS gibt es keine feste Zusage auf die Minute. Nach Änderung des autoritativen DNS können verschiedene Resolver alte und neue Antworten liefern, bis ihr Cache gemäß TTL abläuft.

Bei geplanter Umstellung

  1. Senke TTL vorab, wenn dein Anbieter es erlaubt.
  2. Ändere DNS einmal und vermeide zufällige Wiederholungsänderungen während Caches ablaufen.
  3. Teste über mehrere Resolver, wenn Ergebnisse abweichen.
  4. Notiere Änderungszeit, alten Wert, neuen Wert und TTL.

Diagnosedaten sinnvoll senden

Nenne Hostname, erwartetes Ziel, sichtbare alte Antwort, sichtbare neue Antwort, TTL und Änderungszeit. Zugänge zum DNS-Konto werden nicht benötigt.

> Speicherplanung für Nextcloud

Plane Nutzerdateien, geteilte Ordner, Versionen, Papierkorb, Vorschaubilder, Sync-Overhead und Teamwachstum ein.
faq/nextcloud-storage-planning

Nextcloud wächst auch außerhalb sichtbarer Dateien

Kapazität verbrauchen Nutzerdateien, geteilte Ordner, gelöschte Dateien, Versionierung, Previews, Thumbnails, Sync-Clients und Importe. Nah am Limit können Uploads oder Synchronisierung fehlschlagen.

Vor der Kapazitätsbestellung

  1. Zähle aktuelle Nutzerdaten und gemeinsame Ordner.
  2. Plane Reserve für Versionen, Papierkorb, Previews und Sync-Overhead ein.
  3. Berücksichtige große Importe, neue Teams und erwartetes Wachstum.
  4. Erhöhe Kapazität, bevor Nutzer an Grenzen stoßen.

Bei Sync-Problemen

Sende Servicegröße, ungefähre Nutzung, Zeitpunkt und sichtbaren Clientfehler. Sende keine persönlichen Dateien, Passwörter oder Nutzerdatenexporte, außer der Support fordert sie über einen sicheren Weg an.

> Repository-Migration zu Gitea

Plane den Umzug von Git-Repositories mit LFS, Submodules, Rechten, Deploy Keys, Webhooks und CI/CD.
faq/gitea-repository-migration

Migration ist mehr als git clone

Neben der Repository-Historie müssen Eigentümer, Teams, protected branches, protected tags, Git LFS, submodules, deploy keys, webhooks und CI/CD-Anbindungen übertragen oder neu eingerichtet werden.

Prüfung vor dem Cutover

  1. Liste Repositories, Eigentümer, Zugriffsgruppen und Automation-Konten.
  2. Prüfe Git LFS-Objekte, submodules, branch protections und tag protections.
  3. Teste nach dem Umzug clone, push, Git LFS, submodules und CI-Lauf.
  4. Entferne oder rotiere alte Zugangsdaten nach der Migration sicher.

Sensible Migrationsdaten

Sende keine privaten Schlüssel, keine private deploy-key-Seite und keine CI-Werte mit vertraulichem Inhalt. Reponamen, Integrationstyp, sichtbarer Fehler und vorher funktionierendes Verhalten reichen.

> Absenderdomain für Listmonk

Bereite für Kampagnen Sender-Domain oder Subdomain, From-Identität, SPF, DKIM, DMARC, Bounce und Abmeldung vor.
faq/listmonk-sender-domain-basics

Zustellbarkeit beginnt bei der Domain

Listmonk braucht eine klare From-Identität und DNS-Records, die Mailserver prüfen können. SPF, DKIM und DMARC müssen zur Domain oder Subdomain passen, von der du Kampagnen sendest.

Vor der ersten Kampagne

  1. Wähle Sender-Domain oder Subdomain und From-Namen.
  2. Füge Verifikations-DNS, SPF, DKIM selector und DMARC hinzu.
  3. Teste Zustellung, Bounce oder Return-Path und Links in der Nachricht.
  4. Prüfe Abmeldung und List-Unsubscribe vor dem echten Versand.

Mailzugänge gehören nicht ins Ticket

Sende bei Diagnose Domain, Record-Typ, öffentlich sichtbaren DNS-Wert und Fehlermeldung. Sende keine SMTP-Passwörter, keinen privaten DKIM key und keine Empfängerexporte mit personenbezogenen Daten.

> Runtime-Einstellungen für Classic Hosting

Classic Hosting kann in Auto- oder manuellem Runtime laufen; CPU, RAM, Speicher, Backup-Aufbewahrung, Offsite Archive, Uploads, Cache und Logs beeinflussen Preis und Stabilität.
faq/classic-hosting-runtime-settings

Auto-Modus ist nicht immer die richtige Wahl

Auto Runtime hilft bei erkannten Projekten, der manuelle Modus passt, wenn du Nginx, Apache, FrankenPHP oder ein konkretes Sprach-Runtime genau wählen willst. PHP selector nur verwenden, wo das gewählte Runtime ihn unterstützt.

Einstellungen vor dem Deployment

  1. Wähle Auto oder manuelles Runtime nach Framework und Build-Art.
  2. Wähle PHP 8.2, 8.3 oder 8.4 nur für unterstützte PHP-Szenarien.
  3. Setze CPU, RAM, Speicher, Backup-Aufbewahrung und Offsite Archive nach Datenmenge und Traffic.
  4. Teste nach dem Deploy Uploads, Cache, Logs und sichtbare Anwendungsfehler.

Wenn die Anwendung nicht startet

Sende Runtime-Modus, Sprache oder PHP-Version, sichtbaren Fehler, Änderung und ungefähre Deploy-Zeit. Sende keine .env-Dateien, Passwörter oder vollständigen Logs mit sensiblen Werten.

> Welche Informationen du sicher an den Support senden kannst

Am meisten helfen Bestellnummern, Servicenamen, Domains, Zeiten, öffentliche Hosts, Ports, Hosting-Einstellungen und sichtbare Fehler ohne sensible Werte.
faq/support-safe-information-to-share

Ein gutes Ticket hat Kontext, keine sensiblen Werte

Der Support reagiert schneller mit Bestellnummer, Servicename, Domain, öffentlichem Host oder Port, Problemzeit, Änderungen und genauer sichtbarer Fehlermeldung.

Sicherer Nachrichteninhalt

  1. Nenne Bestellung, Service, Domain, Zeit und den Schritt, bei dem das Problem auftrat.
  2. Bei Hosting ergänze Runtime, PHP oder Sprache, CPU, RAM, Speicher, Uploads, Cache und Logs ohne sensible Werte.
  3. Schneide oder schwärze Screenshots vor dem Senden.
  4. Wenn du unsicher bist, frage zuerst ohne die fragliche Information zu senden.

Niemals mitsenden

Sende keine Passwörter, privaten Schlüssel, Recovery-Seeds, Session-Cookies, Datenbankexporte, kompletten .env-Dateien, vollständigen Logs mit sensiblen Werten oder internen Infrastrukturdetails.