Häufig gestellte Fragen

Häufig gestellte Fragen

Praktische, kurze Anleitungen für die Einrichtung von Diensten, Zugriffsrechten und gängigen Kundenabläufen.

> Wie funktioniert das Cli>_ Guthabensystem?

Ein gemeinsames Prepaid-Guthaben finanziert alle berechtigten Services und wird nur während ihres aktiven Betriebs verbraucht.
faq/prepaid-credit-how-it-works

Dein Cli>_ Konto hat ein gemeinsames Prepaid-Guthaben. Berechtigte Neukunden können Starter Credit erst beanspruchen, nachdem sie die erforderliche Konto- und Missbrauchsschutzprüfung abgeschlossen haben. Aktive berechtigte Services verbrauchen das Guthaben mit der Zeit. Monatliche Schätzungen rechnen mit 31 Tagen; ein neuer Service kann nur starten, wenn das Guthaben mindestens 7 Tage abdeckt. Fällt die geschätzte Laufzeit unter 7 Tage, erscheint eine rote Warnung; andernfalls erscheint unter 14 Tagen eine orange.

Nach Verbrauch des Guthabens wird der Service nach 7 Tagen gesperrt, verbraucht kein Guthaben mehr, und die 7-tägige Aufbewahrungs- und Löschfrist beginnt. Vor der angezeigten Frist kannst du ihn mit genug Guthaben neu starten. Die Kündigung eines bereitgestellten Services sperrt ihn ebenfalls und startet dieselbe Frist. Ein ausstehender, noch nicht bereitgestellter Service kann sofort deaktiviert werden. Nach der Frist beginnen Deaktivierung und Entfernung des bereitgestellten Services. Force delete deaktiviert den Service sofort, überspringt die Aufbewahrung und startet die Entfernung aus der aktiven Runtime; der Abschluss folgt nach der Deployment- und GitOps-Verarbeitung. Backups und Offsite Archive haben eigene Aufbewahrungsregeln.

Beispiel OpenCode für 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR pro Tag. Nach 10 vollen Tagen sind etwa 3,19 EUR verbraucht. Bei genau 9,90 EUR Anfangsguthaben und ohne weitere Services bleiben etwa 6,71 EUR. Nach der Deaktivierung stoppt der weitere Verbrauch.

Das Beispiel dient nur zur Veranschaulichung. Maßgeblich sind immer die aktuell in Cli>_ angezeigten Preise.

> Wie generiere ich einen öffentlichen SSH-Schlüssel über die Kommandozeile?

Erstellen Sie einen öffentlichen SSH-Schlüssel für den sicheren Zugriff auf Ihren VPS. Teilen Sie nur den öffentlichen Schlüssel mit Cli>_; behalten Sie den privaten Schlüssel auf Ihrem Gerät.
faq/oeffentlichen-ssh-schluessel-erstellen

Der öffentliche Schlüssel wird geteilt, der private Schlüssel bleibt bei Ihnen

Fügen Sie nur den öffentlichen SSH-Schlüssel im Bestellprozess oder bei der Servicekonfiguration ein. Der private Schlüssel verbleibt auf Ihrem Computer und wird nicht an den Support gesendet oder in ein Webformular eingegeben.

Vorgehensweise

  1. Öffnen Sie ein Terminal auf Ihrem Computer.
  2. Führen Sie den Befehl aus: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Bestätigen Sie den Speicherort der Datei oder wählen Sie einen benutzerdefinierten Pfad. Geben Sie Ihren privaten Schlüssel niemals an Dritte weiter.
  4. Zeigen Sie den öffentlichen Schlüssel mit dem Befehl: `cat ~/.ssh/id_ed25519.pub` an.
  5. Kopieren Sie die gesamte Zeile, die mit `ssh-ed25519` beginnt, und fügen Sie sie in das Feld für den SSH-Öffentlichen Schlüssel während des Bestellvorgangs oder bei der Servicekonfiguration ein.
  6. Kopieren Sie die gesamte Zeile mit `ssh-ed25519` und fügen Sie sie in das Feld "SSH Public Key" ein.

Vor dem Einfuegen pruefen

  1. Öffnen Sie PowerShell oder Windows Terminal.
  2. Führen Sie den Befehl aus: ssh-keygen -t ed25519 -C "ihre-email@example.com".
  3. Drücken Sie die Eingabetaste, um den Schlüssel in C:\Users\Ihr-Benutzername\.ssh\id_ed25519 zu speichern, oder geben Sie einen benutzerdefinierten Pfad an.
  4. Wenn Windows nach einer Passphrase fragt, verwenden Sie eine sichere Passphrase oder drücken Sie die Eingabetaste, um diese für eine einfache Einrichtung zu überspringen.
  5. Der öffentliche Schlüssel kann mit folgendem Befehl angezeigt werden: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Kopieren Sie nur die vollständige Zeile, die mit ssh-ed25519 beginnt. Kopieren oder laden Sie keine Datei mit dem privaten Schlüssel hoch.
> Wie man unter Windows einen SSH-Schlüssel grafisch erstellt

Eine grafische Anleitung zur Erstellung eines SSH-Schlüsselpaars unter Windows, ohne die Kommandozeile zu verwenden.
faq/ssh-schluessel-grafisch-in-windows-erstellen

Verwenden Sie ein Windows-Tool und fügen Sie nur den öffentlichen Schlüssel ein

Sie können ein SSH-Schlüsselpaar mit einem Windows-SSH-Client wie PuTTYgen grafisch erstellen. Cli>_ benötigt lediglich den öffentlichen Schlüssel. Bewahren Sie die private Schlüsseldatei auf Ihrem Computer auf und laden Sie sie nicht über ein Webformular hoch.

Vorgehensweise

  1. Installieren Sie PuTTY oder öffnen Sie PuTTYgen, falls es bereits installiert ist.
  2. Wählen Sie EdDSA/Ed25519, wenn verfügbar, andernfalls wählen Sie RSA 4096.
  3. Klicken Sie auf "Generieren" und bewegen Sie die Maus über den leeren Bereich, bis der Schlüssel generiert wurde.
  4. Fügen Sie eine Passphrase hinzu, wenn Sie Ihren privaten Schlüssel zusätzlich lokal schützen möchten.
  5. Speichern Sie den privaten Schlüssel auf Ihrem Gerät und behandeln Sie ihn vertraulich.
  6. Kopieren Sie den öffentlichen Schlüsseltext und fügen Sie ihn in das Feld für SSH-Öffentliche Schlüssel in Cli>_ ein.

Geben Sie keine geheimen Daten weiter

Senden Sie keine .ppk-Dateien, privaten Schlüssel, Passphrasen, Passwörter oder Token an den Support oder in Formulare.

> Verwenden Sie Ihre eigene Domain

So leiten Sie Ihre eigene Domain oder Subdomain zu einem CLIopen-Dienst weiter, bevor Sie die Funktion 'Bring Your Own Domain' aktivieren.
faq/eigene-domain-verbinden

Was diese Einstellung bewirkt

Mit der Funktion "Eigene Domain" können Sie Ihren Dienst unter Ihrem eigenen Hostnamen bereitstellen, z. B. app.example.com, anstatt nur den generischen Hostnamen *.co.cliopen.cloud zu verwenden. Ihre DNS-Einstellungen müssen zuerst auf CLIopen verweisen, bevor der Hostname sicher in Ihrem Dienst verwendet werden kann.

Vor Beginn

  1. Wählen Sie den genauen Hostnamen, den Sie verwenden möchten, z. B. app.example.com. Die Verwendung einer Subdomain ist die einfachste Option.
  2. Melden Sie sich im DNS-Verwaltungsbereich Ihres Domainregistrators oder Ihres DNS-Providers an.
  3. Löschen Sie alle widersprüchlichen A-, AAAA-, CNAME-, ALIAS- oder Redirect-Einträge für diesen Hostnamen.
  4. Behalten Sie den generierten CLIopen-Hostnamen aktiv, bis Ihr benutzerdefinierter Hostname verifiziert und funktionsfähig ist.

Empfohlene DNS-Einstellungen für eine Subdomain

Erstellen Sie DNS-Einträge für den exakten Hostnamen, den Sie in CLIopen eingeben. Für app.example.com lautet der DNS-Name app. Verweisen Sie ihn auf die CLIopen-Ingress-Adressen, die Sie vom CLIopen-Support oder in der Service-Dokumentation erhalten. Wenn Ihr Provider einen Eintragstyp benötigt, verwenden Sie einen A-Eintrag für IPv4 und einen AAAA-Eintrag für IPv6, wenn diese Adressen bereitgestellt werden.

Beispiel:

app.example.com.  A     <CLIopen-IPv4-Adresse>
app.example.com.  AAAA  <CLIopen-IPv6-Adresse, falls verfügbar>

Wenn CLIopen ein CNAME-Ziel bereitstellt

Einige Dienste stellen Ihnen einen generierten Hostnamen zur Verfügung, z. B. service.customer.co.cliopen.cloud. Wenn die Anweisungen für Ihren Dienst ausdrücklich eine Verwendung von CNAME erfordern, erstellen Sie einen Eintrag wie app.example.com CNAME service.customer.co.cliopen.cloud. Verwenden Sie CNAME nur für Subdomains und nicht für die Apex-/Root-Domain, es sei denn, Ihr DNS-Provider unterstützt ALIAS oder ANAME Flattening.

Verwendung der Root-Domain

Für eine reine Domain wie example.com erlauben die meisten DNS-Provider keinen Standard-CNAME-Eintrag. Verwenden Sie A/AAAA-Einträge, die auf die CLIopen-Ingress-Adressen verweisen, oder verwenden Sie die ALIAS-/ANAME-Funktion Ihres Providers, falls CLIopen einen Hostnamen bereitgestellt hat.

Delegierung einer gesamten Subzone

Wenn Sie möchten, dass CLIopen Einträge für eine Subzone wie apps.example.com verwaltet, erstellen Sie NS-Einträge für diese Subzone und verweisen Sie auf die von CLIopen bereitgestellten Nameserver. Ändern Sie nicht die Nameserver der gesamten Domain, es sei denn, Sie möchten bewusst, dass CLIopen (oder ein anderer DNS-Dienst) alle Einträge verwaltet.

Checkliste

  1. Warten Sie, bis die DNS-Änderungen wirksam sind. Kleine Änderungen werden oft innerhalb weniger Minuten sichtbar, aber einige Provider speichern länger zwischen.
  2. Überprüfen Sie, ob der Hostname auf das CLIopen-Ziel und nicht auf einen vorherigen Anbieter verweist.
  3. Geben Sie im Feld 'Bring your own domain' den genauen Hostnamen ein, ohne `https://` und ohne Pfad.
  4. Testen Sie nach der Aktualisierung `https://app.example.com` in Ihrem Browser.
  5. Behalten Sie alte DNS-Einträge nur dann, wenn sie nicht mit dem neuen Hostnamen in Konflikt stehen.
> So übertragen Sie eine DNS-Zone zu CLIopen

Delegieren Sie eine Domain an ns1.cliopen.com und ns2.cliopen.com, damit CLIopen die Datensätze für die gesamte Zone veröffentlichen kann.
faq/dns-zone-uebergeben

Was bedeutet Zonenübertragung hier?

Bei einer DNS-Übertragung für Kunden bedeutet dies die Änderung der autoritativen Nameserver beim Domain-Registrar. Nachdem die Delegation auf CLIopen erfolgt ist, werden die in CLIopen hinzugefügten DNS-Einträge von unseren autoritativen Nameservern veröffentlicht.

Vor dem Ändern der Nameserver

  1. Kopieren Sie die vorhandenen DNS-Einträge, die Sie weiterhin benötigen, wie z. B. Website-, E-Mail-, Verifizierungs-, SPF-, DKIM-, DMARC- und Service-Einträge.
  2. Fügen Sie die Zone in CLIopen DNS hinzu. Wenn die Delegation noch nicht bereit ist, speichert CLIopen sie, aktiviert sie aber erst für Kunden, wenn die Validierung erfolgreich war.
  3. Erstellen Sie nach Möglichkeit die erforderlichen Einträge in CLIopen DNS, bevor Sie die Nameserver ändern.
  4. Achten Sie darauf, den CAA-Eintrag korrekt zu konfigurieren, da falsche Werte die Ausstellung von Zertifikaten verhindern können.

Delegieren Sie die Zone

  1. Öffnen Sie die Domänen-Einstellungen bei Ihrem Registrar, z.B. example.com.
  2. Suchen Sie nach den Nameservern, der DNS-Delegierung oder den autoritativen DNS-Einstellungen.
  3. Ersetzen Sie die aktuellen Nameserver durch ns1.cliopen.com und ns2.cliopen.com.
  4. Speichern Sie die Änderung und warten Sie auf die Aktualisierung in den Registern und Resolvern.

Validierung

Gehen Sie zurück zu CLIopen DNS und klicken Sie auf "Delegierung erneut überprüfen". Wenn die öffentlichen NS-Einträge ns1.cliopen.com und ns2.cliopen.com anzeigen, wird die Zone zur Synchronisierung hinzugefügt und die Einträge werden von CLIopen aktiv.

> Kontoerstellung und erste Anmeldung

Erstellen Sie ein Kundenkonto für Bestellungen, geben Sie Rechnungsdaten an und nutzen Sie eine E-Mail-Adresse, auf die Ihr Team Zugriff hat.
faq/account-registration-and-login

Ein Konto für Bestellungen und Verwaltung

Verwenden Sie ein Konto als zentrale Anlaufstelle für Bestellungen, Rechnungsdetails, Services, Domains und die Kommunikation mit dem Support. Verwenden Sie am besten eine geschäftliche E-Mail-Adresse, auf die Ihr Team auch nach Personalwechsel Zugriff hat.

Vor Ihrer ersten Bestellung

  1. Registrieren Sie sich mit Ihrer beruflichen E-Mail-Adresse.
  2. Bestätigen Sie die E-Mail, falls dies von der Seite verlangt wird.
  3. Bitte vervollständigen Sie Ihre Rechnungsdaten, bevor Sie eine kostenpflichtige Bestellung aufgeben.
  4. Aktivieren Sie die Zwei-Faktor-Authentifizierung, sobald diese für Ihr Konto verfügbar ist.

Teamzugriff

Geben Sie Passwörter nicht per Chat oder E-Mail an Kollegen weiter. Verwenden Sie einen internen Passwortmanager oder fragen Sie nach einem geeigneten Teamprozess; der Support benötigt Ihr Passwort nicht.

> Geschätzter Monatsverbrauch, geschätzter Jahresverbrauch und tatsächlicher Tagesverbrauch

Die monatlichen und jährlichen Preise dienen nur zum Vergleich; bei Vorauszahldiensten ist der tägliche Verbrauch nach Bestätigung einer Änderung maßgeblich.
faq/billing-periods-and-credit-burn

Der Vergleich ist kein Abrechnungsplan

Verwenden Sie die monatliche Schätzung als Vergleich für 31 Tage, und die jährliche Schätzung als Vergleich für 372 Tage. Der tatsächliche Verbrauch des Guthabens erfolgt bei Vorauszahlungsdiensten entsprechend der aktiven Nutzungsdauer und der bestätigten Konfiguration.

Was Sie bei einer Preisänderung überprüfen sollten

  1. Vergleichen Sie den täglichen Verbrauch vor und nach der Änderung.
  2. Bei mehr CPU, RAM, Speicher oder kostenpflichtigen Optionen ist mit einem höheren täglichen Verbrauch zu rechnen.
  3. Die Änderung wird erst wirksam, nachdem sie bestätigt, gegebenenfalls bezahlt und angewendet wurde.
  4. Für Ihre Buchhaltung speichern Sie bitte die Bestellbestätigung und den Kreditverlauf.

Berücksichtigen Sie bei Problemen den jeweiligen Zeitraum.

Für die Prüfung benötigen wir die Bestellnummer, den Namen des Dienstes und die Daten, für die Sie eine Überprüfung wünschen. Bitte senden Sie keine Bankdaten, vollständigen Zahlungsbelege oder Screenshots mit ungewollten persönlichen Informationen.

> Bestellstatus nach Zahlung

Nachdem Sie bezahlt haben, kann es sein, dass Ihre Bestellung noch auf die Bestätigung des Zahlungsanbieters wartet. Erstellen Sie keine Duplikate, bevor die erste Bestellung eindeutig storniert oder abgelaufen ist.
faq/order-status-and-payment-confirmation

"Pending" bedeutet nicht automatisch einen Fehler

Nachdem Sie die Zahlseite verlassen haben, kann die Bestellung noch auf eine Bestätigung des Zahlungsanbieters warten. Solange der Status nicht eindeutig als fehlgeschlagen oder abgelaufen angezeigt wird, kann eine doppelte Bestellung unnötig Probleme verursachen.

Was tun nach der Zahlung

  1. Nach Abschluss der Zahlung kehren Sie zu Cli>_ zurück.
  2. Überprüfen Sie im Konto den Bestellstatus und eventuelle Nachrichten bezüglich der Zahlung.
  3. Wenn die Bestellung noch bearbeitet wird, geben Sie dem Anbieter Zeit zur Bestätigung.
  4. Bei Problemen senden Sie dem Support bitte die Bestellnummer und den Zahlungsbeleg (falls vorhanden).

Was nicht versendet werden soll

Der Support benötigt keine Kartendaten, kein Login-Passwort oder einen vollständigen Bankauszug. Es reichen Bestellnummer, Zeitpunkt der Zahlung, sichtbarer Status und ein ggf. geschwärzter Screenshot, falls eine Fehlermeldung angezeigt wird.

> Informationen, die die Einrichtung des Dienstes beschleunigen

Bitte bereiten Sie den Namen des Dienstes, die Domain, die Speicherkapazität, die E-Mail-Adresse für den Zugriff und den öffentlichen SSH-Schlüssel vor. Sensible Daten gehören nicht in Formulare.
faq/service-setup-information-needed

Genaue Angaben sparen Zeit

Verwenden Sie Bestellformulare für öffentliche oder unkritische Werte: Dienstname, Domain, DNS-Plan, Speichergröße, CPU, RAM, Admin-E-Mail oder öffentlicher SSH-Schlüssel. Passwörter und private Schlüssel gehören nicht in die Formulare.

Bereiten Sie sich vor dem Absenden der Bestellung vor

  1. Wählen Sie einen eindeutigen Servicenamen für Ihr Team.
  2. Entscheiden Sie, ob Sie eine eigene Domain oder einen temporären System-Hostnamen verwenden möchten.
  3. Bereiten Sie einen öffentlichen SSH-Schlüssel vor, falls der Dienst ihn benötigt.
  4. Überprüfen Sie den Speicherplatz und die Ressourcen entsprechend der Anwendung, die Sie ausführen möchten.

Wichtige Hinweise: Keine Geheimnisse preisgeben

Wenn Sie sich nicht sicher sind, ob ein Datensatz vertraulich ist, fragen Sie lieber, bevor Sie ihn senden. Senden Sie keine privaten Schlüssel, Passwörter, Token, Datenbank-Dumps oder vollständigen Konfigurationsdateien in den Chat oder die Bestellung.

> Änderung von CPU, RAM, Festplatte oder Speicherdauer nach der Bestellung

Ändern Sie den bestehenden Dienst über dessen Details, nicht durch eine neue, doppelte Bestellung. Bei Änderungen der Ressourcen können sich Preis, Servicepreis, täglicher Kreditverbrauch, Neustarts und das Risiko eines Ausfalls ändern.
faq/change-service-resources-after-order

Sie ändern einen bestehenden Dienst, Sie erstellen keinen neuen.

Wenn ein Dienst bereits läuft, ändern Sie die Ressourcen über die Detailansicht des Dienstes. Eine neue Bestellung würde einen weiteren Dienst erstellen anstatt den bestehenden zu ändern und kann Preis, täglichen Kreditverbrauch und Betriebsverhalten nach Bestätigung, Bezahlung und Anwendung der Änderung verändern.

Vor der Bestätigung

  1. Überprüfen Sie die aktuellen Informationen zu CPU, RAM, Speicherplatz, Backups und der Aufbewahrungsdauer des Offsite-Archivs.
  2. Prüfen Sie den neuen Tagespreis und dessen Auswirkungen auf Ihr Guthaben.
  3. Lesen Sie die Hinweise zu Neustarts, Wartungen oder Ausfällen.
  4. Exportieren Sie vor einer risikoreichen Änderung Ihre eigenen wichtigen Daten.

Was passiert, wenn die Änderung nicht wie erwartet verläuft

Bitte senden Sie den Namen des Dienstes, den Zeitpunkt der Änderung, den sichtbaren Status und die Fehlermeldung. Senden Sie keine privaten Schlüssel, Passwörter oder Token; für die Diagnose reichen öffentlicher Kontext und ein unkenntlich gemachter Screenshot.

> Stornierung des Dienstes und Löschfrist für Daten

Der bereitgestellte Dienst wird zuerst angehalten. Ein konfigurierbarer, sichtbarer Zeitraum wird angezeigt, bevor die endgültige Löschung erfolgt.
faq/cancel-service-and-data-retention

Die Kündigung führt nicht immer zur sofortigen Löschung aller Dienste

Bei einem bereits bereitgestellten Dienst wird dieser zuerst pausiert und es wird ein konfigurierbarer, sichtbarer Zeitraum angezeigt, innerhalb dessen eine Wiederherstellung oder ein Export möglich ist. Ausstehende, unbezahlte Bestellungen ohne laufende Daten können anders behandelt werden, und die endgültige Löschung erfolgt erst nach Ablauf der Lebenszyklusdauer.

Vor der Löschung prüfen

  1. Erstellen Sie einen eigenen Datenexport für Informationen, die Sie langfristig speichern möchten.
  2. Lesen Sie das Datum und die Uhrzeit der geplanten Löschung bei einer gesperrten Dienstleistung.
  3. Verwechseln Sie Backups und Offsite-Archive nicht mit der Löschung im Service-Lebenszyklus.
  4. Wenn Sie sich unsicher sind, kontaktieren Sie den Support vor dem Löschtermin.

Eine Wiederherstellung nach Ablauf der Frist ist möglicherweise nicht möglich.

Nach Ablauf des sichtbaren Zeitraums sollten Sie nicht mehr davon ausgehen, dass die Daten verfügbar sind. Geben Sie bei Fragen bitte die Bestellnummer und den Namen des Dienstes an, keine Datenbankexporte oder Zugangsdaten.

> Backups und Wiederherstellungsanfragen

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

Backup ist keine Archivierung oder ein Export

Die Aufbewahrungsdauer von Backups hängt vom Produkt und den gewählten Optionen ab. Ein Backup dient zur Wiederherstellung nach Fehlern, ersetzt aber nicht einen eigenen Export, ein Audit-Archiv oder eine Offsite-Archivierung. Eine Wiederherstellung kann neuere Änderungen überschreiben.

Wie bereiten Sie eine Wiederherstellungsanfrage vor?

  1. Geben Sie den Namen des Dienstes und die Bestellnummer an.
  2. Beschreiben Sie ungefähr den Zeitpunkt, zu dem Sie zurückkehren möchten.
  3. Bitte geben Sie an, ob der gesamte Dienst oder nur ein bestimmter Teil wiederhergestellt werden soll, falls dies unterstützt wird.
  4. Fügen Sie sichtbare Fehler oder Kontext hinzu, ohne Passwörter, Token oder private Schlüssel anzugeben.

Berücksichtigen Sie die Auswirkungen vor der Wiederherstellung.

Wenn der Dienst inzwischen neue Daten erhalten hat, kann die Wiederherstellung diese durch einen älteren Stand ersetzen. Informieren Sie das Team und exportieren Sie alle Daten, die Sie nicht verlieren möchten.

> Wofür ist Offsite Archive gedacht?

Offsite Archive speichert entfernte Archivkopien, die getrennt von kurzfristigen Betriebssicherungen und dem Service-Lebenszyklus gehalten werden.
faq/offsite-archive-purpose

Archiv außerhalb des normalen Betriebs

Offsite Archive dient zur Erstellung von Remote-Archivkopien und zur langfristigen Datenspeicherung. Es ist kein Live-Datenträger für Anwendungen, kein Ersatz für lokale Exporte oder dasselbe wie kurze operative Backups.

Wann aktivieren?

  1. Nutzen Sie es für Daten, die außerhalb des normalen Servicebetriebs gespeichert werden sollen.
  2. Wählen Sie die Aufbewahrungsdauer entsprechend Ihren Compliance-Anforderungen, Geschäftsanforderungen oder Ihren Wiederherstellungszielen aus.
  3. Beachten Sie, dass die Kosten in Abhängigkeit von der gespeicherten Datenmenge und der Aufbewahrungsdauer steigen.
  4. Bei großen Datenmengen planen Sie das Archiv in Verbindung mit einem eigenen Exportprozess.

Wie man über den Preis nachdenkt

Die Grundlage sind MB-Tage: die gespeicherte Datenmenge multipliziert mit der Anzahl der Aufbewahrungsdauer. Der Preis wird dem Kunden als EUR/GB/Monat angezeigt und auf ganze Cent gerundet.

> Auswahl von CPU, RAM und Festplatte für einen VPS

Wählen Sie die Größe Ihres VPS basierend auf der Anwendung, Datenbank, dem Cache, den Protokollen und dem erwarteten Wachstum. OOM-Fehler oder Swapping deuten darauf hin, dass mehr Arbeitsspeicher benötigt wird.
faq/vps-cpu-ram-and-disk-sizing

Planen Sie anhand der tatsächlichen Auslastung, nicht nach Gefühl

Eine kleine statische Website hat andere Anforderungen als eine Datenbank, eine Java-Anwendung, eine Suchmaschine oder ein Container mit Builds. Berücksichtigen Sie bei der Planung den Anwendungsspeicher, den Cache, die Datenbank, die Protokolle, die Uploads und einen Puffer für das Wachstum.

Anzeichen dafür, dass der Plan zu klein ist

  1. Erhöhen Sie den RAM-Speicher bei OOM-Fehlern (Out of Memory), wenn Prozesse beendet werden oder es zu ständigem Auslagern kommt.
  2. Erhöhen Sie die CPU-Leistung bei anhaltend hoher Rechenlast, Komprimierungsprozessen, Build-Vorgängen oder stark ausgelasteten Worker-Prozessen.
  3. Erweitern Sie den Speicherplatz, bevor das Dateisystem, die Protokolldateien oder die Datenbank voll sind.
  4. Überprüfen Sie nach jeder Änderung, ob die Anwendung nicht mehr an die ursprüngliche Grenze stößt.

Was sollte ich bei einer Größenanfrage mitteilen?

Nützlich sind der Name des Dienstes, der Anwendungstyp, ein sichtbarer Fehler, die ungefähre Zeit und die aktuell ausgewählten CPU-, RAM- und Speicherwerte. Senden Sie keine Passwörter, privaten Schlüssel oder interne Konfigurationsdateien.

> Wann ist eine öffentliche IP-Adresse für einen VPS sinnvoll?

Eine dedizierte öffentliche IP-Adresse kann bei Allowlisten, eingehendem Zugriff, einer stabilen Ausgangsquelle oder Diensten hilfreich sein, die an eine Adresse gebunden sind.
faq/vps-public-ip-options

Zuerst die Kommunikationsrichtung ermitteln

Eine öffentliche IP-Adresse ist nicht für jeden Dienst unbedingt erforderlich. Sie wird häufig benötigt, wenn externe Partner, Anbieter oder Firewalls eine stabile Adresse für die Allowlist benötigen, eine zuverlässige Ausgangsquelle bereitstellen sollen oder ein eingehender Zugriff auf bestimmte Ports ermöglicht werden muss.

Fragen vor der Bestellung einer IP-Adresse

  1. Fragen Sie den Partner, ob eingehende Verbindungen, ausgehende Verbindungen oder beide Richtungen in der Allowlist stehen sollen.
  2. Verwenden Sie DNS-Namen anstelle von numerischen IP-Adressen, wo immer das externe System dies unterstützt.
  3. Öffnen Sie nur die Ports, die die Anwendung tatsächlich benötigt.
  4. Senden Sie die Allowlist-Anforderung an den Support, bevor Sie Zugriffsberechtigungen für Produktionsumgebungen ändern.

Was man geschlossen lassen sollte

Eine öffentliche IP-Adresse bedeutet nicht, dass alle Ports geöffnet werden müssen. Planen Sie den Zugriff auf die minimal erforderlichen Dienste und senden Sie keine Passwörter, privaten Schlüssel oder interne Firewall-Regeln als Screenshots mit vertraulichen Informationen.

> Gemeinsamer SSH-Zugriff für VPS

Ohne eine zusätzliche öffentliche IP-Adresse verbindet sich der VPS über einen gemeinsamen SSH-Endpunkt mit einem hohen Port. Bei einer öffentlichen IP-Adresse wird zusätzlich ein direkter SSH-Zugang zu dieser Adresse bereitgestellt.
faq/shared-ssh-access-for-vps

Warum Shared SSH hohe Ports verwendet

Mehrere VPS-Dienste können denselben öffentlichen SSH-Endpunkt nutzen, daher erhält jeder Dienst einen eigenen hohen Port. Dieser Port ist Teil der Weiterleitung zu Ihrem Dienst; ohne ihn könnte die Verbindung nicht eindeutig an den richtigen VPS zugestellt werden.

Wie Sie sich je nach Verbindungstyp verbinden

  1. Beim gemeinsamen SSH kopieren Sie den Benutzernamen, den öffentlichen Host und den Port aus dem Service.
  2. Verwenden Sie das Format `ssh -p <port> <username>@<public-host>`.
  3. Wenn der Dienst eine öffentliche IP-Adresse hat, kann es einen zweiten SSH-Endpunkt direkt auf dieser IP-Adresse oder ihrem DNS-Namen geben.
  4. Verwenden Sie den privaten Schlüssel nur lokal über Ihren SSH-Client oder Agent; geben Sie dem Support nur den öffentlichen Host, Port, Benutzernamen und einen sichtbaren Fehler an.

Wenn Sie eine öffentliche IP-Adresse haben

Eine öffentliche IP ersetzt nicht rückwirkend den gemeinsamen SSH-Endpunkt; sie bietet eine separate Zugriffsmöglichkeit für Allowlists, Monitoring oder direkte Verbindungen. In der Praxis können Sie daher zwei Arten von SSH-Zugriffen sehen: einen geteilten Host mit einem hohen Port und einen direkten Host oder eine IP-Adresse für einen Dienst mit einer öffentlichen IP.

> Überprüfung vor der Verbindung Ihrer benutzerdefinierten Domain

Überprüfen Sie vor dem Umschalten auf eine neue Domain die korrekte DNS-Konfiguration, den genauen Hostnamen, den Record-Typ (A, CNAME usw.), ob es sich um eine Hauptdomain oder Subdomain handelt und prüfen Sie auf Konflikte mit alten Einträgen.
faq/custom-domain-readiness-checklist

Der genaue Hostname ist entscheidend

Klären Sie zunächst, ob Sie eine Apex-Domain wie example.com oder eine Subdomain wie app.example.com verwenden möchten. Jede Variante kann unterschiedliche DNS-Record-Typen und Einschränkungen des DNS-Anbieters erfordern.

Vor Änderungen an den DNS-Einstellungen

  1. Überprüfen Sie, wo die autoritativen DNS-Einträge für die Domain geändert werden.
  2. Entfernen oder ändern Sie widersprüchliche A/AAAA-, CNAME-, ALIAS-, ANAME- oder Redirect-Einträge.
  3. Verwenden Sie den für den jeweiligen Dienst und Hostnamen empfohlenen Eintragstyp.
  4. Warten Sie nach der Änderung auf die DNS-Propagation und testen Sie dann das endgültige HTTPS.

Sichere Wiederherstellung

Deaktivieren Sie den ursprünglichen Hosting-Dienst erst, wenn der neue Hostname korrekt antwortet. Bei Problemen senden Sie bitte die Domain, das erwartete Ziel und das öffentlich sichtbare DNS-Ergebnis, aber keine Zugangsdaten zum Registrar.

> Arten von DNS-Einträgen für Dienste

A/AAAA-Einträge verweisen auf Adressen, CNAME-Einträge auf Aliase, MX-Einträge auf E-Mail und TXT-Einträge auf Verifikationen, SPF, DKIM oder DMARC.
faq/dns-record-types-for-services

Vermeiden Sie es, Datensätze willkürlich zu kombinieren

Jeder DNS-Eintrag erfüllt eine andere Aufgabe. A- und AAAA-Einträge verweisen auf IP-Adressen, CNAME erstellt einen Alias für Subdomains, MX leitet E-Mails weiter, TXT enthält Verifizierungen und E-Mail-Richtlinien, CAA schränkt Zertifizierungsstellen ein.

Beim Kopieren von Einträgen

  1. Kopieren Sie den Namen, den Typ und den Wert genau gemäß den Anweisungen des Dienstes.
  2. Verwenden Sie A/AAAA für Adressen, CNAME für zulässige Subdomain-Aliase, MX für E-Mails und TXT für SPF, DKIM, DMARC oder Verifizierungen.
  3. Fügen Sie DKIM unter dem vom Anbieter bereitgestellten Selektor ein und DMARC typischerweise unter _dmarc hinzu.
  4. Achten Sie beim Konfigurieren von CAA-Einträgen auf Genauigkeit, da falsche Werte die Ausstellung von Zertifikaten blockieren können.

Wenn DNS nicht funktioniert

Bitte senden Sie dem Support den Hostnamen, den Record-Typ, den erwarteten Wert und das öffentlich sichtbare Ergebnis. Senden Sie keine Login-Daten für die DNS-Verwaltung oder Screenshots mit API-Schlüsseln.

> DNS-Propagation und TTL – Keine Garantie für Minuten

Die TTL (Time To Live) bestimmt, wie lange Resolver eine alte Antwort speichern dürfen. Während des Übergangs können daher sowohl alte als auch neue Ergebnisse gleichzeitig existieren.
faq/dns-propagation-and-ttl

Propagation ist ein Caching-Prozess, keine Magie

Bei DNS gibt es keine feste Zusage bezüglich der genauen Ausbreitungszeit. Nach einer Änderung des autoritativen DNS können verschiedene Resolver weiterhin alte und neue Antworten liefern, bis ihre Cache-Einträge gemäß TTL ablaufen.

Bei geplanter Änderung

  1. Verringern Sie den TTL-Wert (Time To Live), falls Ihr DNS-Anbieter dies zulässt, bevor Sie eine Änderung vornehmen.
  2. Nehmen Sie die DNS-Änderung einmal vor und vermeiden Sie wiederholte Änderungen, solange der Cache noch aktiv ist.
  3. Testen Sie von mehreren Resolvern oder Netzwerken aus, wenn unterschiedliche Ergebnisse angezeigt werden.
  4. Notieren Sie sich den Zeitpunkt der Änderung, den alten Wert, den neuen Wert und die TTL.

Was sollte bei der Diagnose übermittelt werden

Geben Sie Hostname, erwartetes Ziel, sichtbare alte Antwort, sichtbare neue Antwort, TTL und Änderungszeit an. Senden Sie keine Zugangsdaten für DNS-Konten oder interne Notizen des Anbieters.

> Speicherplanung für Workspace Suite

Bei der Kapazitätsplanung berücksichtigen Sie Benutzerdateien, freigegebene Ordner, Versionen, den Papierkorb, Vorschaubilder, den Synchronisierungs-Overhead und das Wachstum des Teams.
faq/nextcloud-storage-planning

Workspace Suite benötigt auch Speicherplatz für unsichtbare Daten

Der benötigte Speicherplatz wird durch Benutzerdateien, freigegebene Ordner, gelöschte Dateien, Versionshistorie, Vorschaubilder, Miniaturansichten, Synchronisationsclients und Importe verbraucht. Wenn der Speicher fast voll ist, können Uploads oder die Synchronisierung fehlschlagen.

Vor der Bestellung von Ressourcen

  1. Zählen Sie aktuelle Benutzerdaten und freigeteilte Ordner.
  2. Planen Sie Puffer für gelöschte Dateien, Versionsverlauf, Vorschaubilder und Synchronisierungsaktivitäten ein.
  3. Berücksichtigen Sie bei großen Imports große Teams und erwartetes Wachstum.
  4. Erhöhen Sie die Kapazität, bevor Benutzer an ihre Grenzen stoßen.

Bei Problemen mit der Synchronisation

Bitte senden Sie Informationen wie Servicegröße, ungefähre Nutzung, Zeitpunkt des Problems und sichtbare Fehlermeldungen des Clients. Senden Sie keine persönlichen Dateien, Passwörter oder Exportdateien von Kundendaten, es sei denn, der Support fordert diese ausdrücklich über einen sicheren Kanal an.

> Migration von Repositories zu Gitea

Planen Sie den Umzug von Git-Repositories unter Berücksichtigung von LFS, Submodulen, Berechtigungen, Deploy Keys, Webhooks und CI/CD.
faq/gitea-repository-migration

Die Migration ist mehr als nur ein `git clone`

Neben der Repository-Historie müssen Eigentümer, Teams, geschützte Branches, geschützte Tags, Git LFS, Submodule, Deploy Keys, Webhooks und CI/CD-Verbindungen übertragen oder neu eingerichtet werden.

Prüfung vor dem Cutover

  1. Listen Sie Repositories, Eigentümer, Zugriffsgruppen und Automatisierungskonten auf.
  2. Überprüfen Sie Git LFS-Objekte, Submodule, Branch-Schutz und Tag-Schutz.
  3. Testen Sie nach dem Umzug die Funktionen Clone, Push, Git LFS, Submodule und CI-Lauf.
  4. Entfernen oder ersetzen Sie alte Token nach der Migration, ohne deren Werte weiterzugeben.

Sensible Daten beim Migration

Senden Sie an den Support keine Token, privaten Schlüssel, private Deploy-Key-Abschnitte oder CI-Geheimnisse. Geben Sie stattdessen die Namen der Repositories, den Integrationstyp, sichtbare Fehlermeldungen und Informationen darüber an, was vor der Migration funktionierte.

> Absenderdomain für Listmonk

Bereiten Sie für Ihre Kampagnen eine Absenderdomäne oder -subdomäne vor. Konfigurieren Sie außerdem die From-Identität, SPF, DKIM, DMARC, Bounce-Verarbeitung und Abmeldungen.
faq/listmonk-sender-domain-basics

Die Zustellbarkeit beginnt bei der Domain

Listmonk benötigt eine eindeutige Absender-Identität und DNS-Einträge, die von E-Mail-Systemen überprüft werden können. SPF, DKIM und DMARC müssen mit der Domain oder Subdomain übereinstimmen, von der Sie Kampagnen versenden möchten.

Vor der ersten Kampagne

  1. Wählen Sie eine Senderdomäne oder Subdomain und geben Sie einen Absender-Namen an.
  2. Fügen Sie die erforderlichen DNS-Einträge für die Verifizierung hinzu, einschließlich SPF, DKIM-Selektor und DMARC.
  3. Testen Sie den Versand, das Verhalten bei Fehlermeldungen (Bounces) sowie die Return-Path-Adresse und Links in der E-Mail.
  4. Überprüfen Sie die Abmeldung und den List-Unsubscribe-Mechanismus vor dem Versand an echte Empfänger.

E-Mail-Zugangsdaten gehören nicht in den Support-Ticket.

Bei Problemen geben Sie bitte die Domain, den Record-Typ, den öffentlich sichtbaren DNS-Wert und die Fehlermeldung an. Senden Sie keine SMTP-Passwörter, API-Token, privaten DKIM-Schlüssel oder Exportdateien mit personenbezogenen Daten.

> Runtime-Einstellungen für Classic Hosting

Classic Hosting kann im automatischen oder manuellen Modus ausgeführt werden. CPU, RAM, Speicherplatz, Datenspeicherung, Backup-Aufbewahrungszeit, Offsite Archive-Aufbewahrungszeit, Uploads, Cache und Logs beeinflussen den Preis und die Stabilität.
faq/classic-hosting-runtime-settings

Der Automatikmodus ist nicht immer die richtige Wahl

Auto Runtime hilft bei erkannten Projekten, aber der manuelle Modus ist geeignet, wenn Sie Nginx, Apache, FrankenPHP oder eine bestimmte Programmiersprache genau auswählen möchten. Verwenden Sie den PHP-Auswahlschalter nur dort, wo das ausgewählte Laufzeitumfeld ihn unterstützt.

Einstellungen vor dem Deployment

  1. Wählen Sie den automatischen Modus für erkannte Builds oder den manuellen Modus zur Steuerung der Nginx-, Apache- oder FrankenPHP-Runtime aus.
  2. Wählen Sie PHP 8.2, 8.3 oder 8.4 nur dann, wenn die gewählte Runtime dies unterstützt.
  3. Passen Sie CPU, RAM, Speicherplatz, Backup-Aufbewahrungszeit und Offsite Archive-Aufbewahrungszeit basierend auf Datenmenge und Traffic an.
  4. Testen Sie nach der Bereitstellung Uploads, Cache, Protokolle und sichtbare Anwendungfehler.

Wenn die Anwendung nicht startet

Geben Sie den Runtime-Modus, die Sprache oder die PHP-Version, sichtbare Fehler, Änderungen und die ungefähre Bereitstellungszeit an. Senden Sie keine .env-Dateien, Passwörter, Token oder vollständige Protokolldateien mit sensiblen Informationen.

> Welche Informationen können Sie sicher an den Support senden?

Folgende Informationen sind hilfreich für den Support: Bestellnummern, Servicebezeichnungen, Domains, Zeitangaben, öffentliche Hosts, Ports, Backup-Aufbewahrungsfristen, Offsite Archive-Aufbewahrungsfristen, Uploads, Caches, Protokolle, Screenshots und sichtbare Fehlermeldungen (ohne sensible Informationen).
faq/support-safe-information-to-share

Eine gute Supportanfrage enthält relevante Informationen, keine vertraulichen Daten.

Der Support kann schneller reagieren, wenn er Bestellnummern, Servicebezeichnungen, Domains, öffentliche Hosts oder Ports, den Zeitpunkt des Problems, Änderungen und genaue Fehlermeldungen erhält.

Sicherer Nachrichteninhalt

  1. Bitte geben Sie die Bestellnummer, den Dienst, die Domain, den Zeitpunkt und den Schritt an, bei dem das Problem aufgetreten ist.
  2. Bei Hosting-Problemen geben Sie bitte die Runtime-Umgebung, die Programmiersprache oder PHP-Version, CPU, RAM, Speicherplatz, Uploads, Cache und Protokolle (ohne sensible Daten) an.
  3. Schneiden Sie Screenshots vor dem Senden zu oder schwärzen Sie vertrauliche Informationen.
  4. Wenn Sie sich nicht sicher sind, ob eine Information für den Ticket relevant ist, fragen Sie zuerst, bevor Sie diese senden.

Was Sie niemals senden sollten

Senden Sie keine Passwörter, privaten Schlüssel, Wiederherstellungsphrasen, API-Token, Session-Cookies, Datenbankexporte, vollständigen .env-Dateien, vollständigen Protokolldateien mit sensiblen Werten oder interne Infrastrukturdetails.